On Fri, Feb 11, 2011 at 2:57 AM, Crawford, Scott <[email protected]> wrote: > What character set are you looking at here? Assuming the 256 ASCII chars ...
There aren't 256 ASCII characters. ASCII is a 7-bit code, some of the characters are unprintable, and the printable control characters are usually difficult to use in a password (tab, carriage return, etc.). http://wps.com/projects/codes/X3.4-1963/index.html (see page 5) If you want to talk other character sets (such as the IBM 8-bit "code page" system used in MS-DOS, or Unicode), we can do that, but it gets complicated quickly. Code pages vary in what their printable characters are. Code pages are not implemented consistently everywhere. Unicode does not have a uniform distribution. Many (if not most) systems only accept ASCII passwords. People generally only use their native language's characters. Maybe other stuff. > Regardless of all this, it appears cracking passwords is rather pointless. Given all the security attacks that have succeeded due to cracked passwords (and that's just the ones that made it to the news), I think it's safe to say reality has proved you wrong. "In theory, theory and practice are the same; in practice, theory and practice differ." > "The hash is the only secret used in challenge-response protocols today > both on Windows and on other operating systems." > http://blogs.technet.com/b/jesper_johansson/archive/2005/10/13/410470.aspx Not all password cracking attacks are about sniffing a copy of a stored password hash. The statement you quote is based entirely on the idea that someone is trying to crack NT4 style authentication against an NT4 server using LAN access. It disregards any of: A1. Kerberos authentication in Active Directory A2. People who use the same or similar passwords on other systems A3. Systems which use mechanisms to encrypt each authentication transaction A4. Systems which transmit the original password (not hashed) inside a secure channel A5. Locally protected data encrypted by a password A1 Ken addressed. A2 is obviously a bad user behavior, but there's a lot of that out there. A3 is significant to the Windows auth scenario. While Windows 2000 Active Directory added Kerberos, IIRC, authentication still also included sending the stored password hash across the wire in the clear. This meant that a valuable asset was being transmitted cleartext across the wire. I don't recall why it did this. I think it was backwards compatibility. A better approach is encrypt the entire authentication channel between server and client, using an ephemeral key. Thus, passive sniffing can't grab the asset; you need to tamper with the transaction (man-in-the-middle). IIRC, SMB has this capability, but it wasn't made a default until later (Windows 2003?). My memory is fuzzy on the details here; better informed people, please correct me. A4 describes most SSL websites. The server hashes the password and compares that to the stored hash (one hopes; there's been plenty of sites revealed to be storing cleartext passwords, but that's another issue). The password is safe inside a proper SSL tunnel, but when the server's database is stolen, attackers can then crack the password offline. If the server operators didn't know about the theft, the attacker can now impersonate. Combined with A2, and other sites are now compromised. A5 describes the mobile device situation. We're not trying to fool another system into thinking we're someone else; we're trying to crack stolen data. That generally involves a cryptographically strong key, stored locally, and protected by a passcode the user enters. The passcode is what we're trying to attack. Various techniques can be employed to make it computationally harder, but ultimately it's the strength of the passcode that will defend. Your outlook on password cracking seems to be based on the idea that the only authentication system in use is Windows LAN logon. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
