Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: Secure Password Policy? |
|---|---|
| Date: | Fri, 20 Jan 2006 06:57:31 -0500 |
As with most things, hardware and software changes make old policies obsolete rather quickly. If you're cracking passwords that have a good salt (Linux, Novell, some Cisco, the latest windows), you have to brute force every password. With older windows or current windows with legacy support, there is no salt so that lends itself well to pre-computed tables. In that case, the password can be cracked in minutes. One other thing to throw into the mix is that in a Windows environment the NTLM hashes (the older ones) are stored in 2 7-carachter groups if the password is less than 15 characters in length. Because of that, a 14 character password can normally be cracked in under a half-hour. -----Original Message----- From: Stephen J. Smoogen [mailto:smooge@gmail.com] Sent: Thursday, January 19, 2006 1:22 PM To: Sulaiman, Wilmar Cc: pen-test@securityfocus.com Subject: Re: Secure Password Policy? On 1/19/06, Sulaiman, Wilmar <wsulaiman@siddharta.co.id> wrote:
Dear all, I noticed that "best practice" for Minimum password length policy is either 6 or 8 characters. I guess SANS institute considered a weak password if it is less than 8 characters. I would like to know where they derived the number (6 and 8
characters).
Is there any documentation to backup it up why the best practice for minimum password length is set to 6?
It was explained to me a long time ago that the numbers came from how long it takes to do a bruteforce attack against either a remote Unix server using DES hash (or doing the bruteforce against the hash without precompiled tables.) Each extra character increases the time for cracking exponentially. You would then have a forced password change time less than that would limit your risk . If the attacker has the password (and the password has to have a special character some amount of uppercase and lowercase) you can use the charts here http://www.mcgill.ca/ncs/products/security/understandpass/#time 68 character space (8E+06 hashes/sec) (1E+00 hashes/sec) letters seconds seconds 01 8.5E-06 6.8E+01 [ 1.0 m.] 02 5.8E-04 4.6E+03 [ 77.0 m.] 03 3.9E-01 3.1E+05 [ 3.6 d.] 04 2.7E+00 2.1E+07 [247.5 d.] 05 1.8E+02 1.4E+09 [ 46.1 y.] 06 1.2E+04 9.9E+10 [3.1E+03 y.] 07 8.4E+05 6.7E+12 [2.1E+05 y.] 08 5.7E+07 4.5E+14 [1.4E+07 y.] 09 3.9E+09 3.1E+16 [9.9E+08 y.] 10 2.6E+11 2.1E+18 [6.7E+10 y.] 11 1.8E+13 1.4E+20 [4.6E+12 y.] 12 1.2E+15 9.8E+21 [3.1E+14 y.] for a nondistributed attack. A distributed attack would be a power of 2 less time. per appropriate number of machines in the distribution. While it would seem that the time factor for a remote attack is significantly large at 5 letter password.. one needs to take into account to items. Number of hosts that can do the attack [ power of 2 attack] Number of hosts that the password can be tested against [power of 2 attack] In a network with large number of hosts running some sort of service that the password can be tested against you're time for finding a match is smaller and you can evade very stupid IDS because you can go slowly. The brute force attack can be made much more efficient by building a dictionary of common words, phrases, and adding various common additions (number 1 at the end, or for l, etc) I do not have numbers for how much more effective it is.. but I do know it can cut down a search-time tremendously -- Stephen J Smoogen. CSIRT/Linux System Administrator ------------------------------------------------------------------------ ------ Audit your website security with Acunetix Web Vulnerability Scanner: Hackers are concentrating their efforts on attacking applications on your website. Up to 75% of cyber attacks are launched on shopping carts, forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web application hacking. Check your website for vulnerabilities to SQL injection, Cross site scripting and other web attacks before hackers do! Download Trial at: http://www.securityfocus.com/sponsor/pen-test_050831 ------------------------------------------------------------------------ ------- **DISCLAIMER This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business. ------------------------------------------------------------------------------ Audit your website security with Acunetix Web Vulnerability Scanner: Hackers are concentrating their efforts on attacking applications on your website. Up to 75% of cyber attacks are launched on shopping carts, forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web application hacking. Check your website for vulnerabilities to SQL injection, Cross site scripting and other web attacks before hackers do! Download Trial at: http://www.securityfocus.com/sponsor/pen-test_050831 -------------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Secure Password Policy?, Anders Thulin |
|---|---|
| Next by Date: | Re: common cookie db?, Javier Fernandez-Sanguino |
| Previous by Thread: | RE: Secure Password Policy?, Anders Thulin |
| Next by Thread: | RE: Secure Password Policy?, Todd Towles |
| Indexes: | [Date] [Thread] [Top] [All Lists] |