8 ms·
Cracking 14 Character Complex Passwords in 5 Seconds
- acqq 16y agoI believe it's not accidental that all passwords that they crack in the demo are 14 characters or less, that can mean that they attack the hashes which are always possible to crack, the speedup they claim is 100 (they simply increased tables from 8 GB to 80 GB and put them on SSD) but e.g. 1000 seconds before was also very fast for somebody who just needed to gain access to one target.
- StavrosK 16y agoIt's not accidental, because LM only supports passwords up to 14 chars. What's worse, is that they are two 7-character passwords, which you can crack separately, basically making cracking the entire LM keyspace trivial. I think there are rainbow tables that cover all of it (I have a few but they don't contain symbols, I don't think).
- Jach 16y agoHmm, I guess I'll just go out to 15 (or 60, safe for a few years) digits of Pi instead of 14...
- j1o1h1n 16y agoDon't forget to make a couple of mistakes ;-)
- jackowayed 16y agoIf they're really just using 80GB on the SSD (as the linked-to article suggests), why not just use a server with 128GB of RAM and avoid writing to disk altogether?
- potatolicious 16y agoTrue, but I suspect a 80GB SSD is a lot easier to afford for your common basement hacker than a box with 128GB of RAM.
- jmtulloss 16y ago23GB of ram on EC2 is 1.60 an hour. Spin up 10 for $16.00. I think most hackers can afford that and it gives them enough computing power to match an 80GB SSD, I would say.
- ma2rten 16y agoI guess most hackers would rather do it at home ...
- InclinedPlane 16y agoBy roughly a factor of 10, not including the motherboard costs (since most boards don't support 128gb of ram).
- WA 16y agoI'm not entirely sure which algorithm is used in WinXP for password hashing, but it might still be an LM hash, which has some security flaws. All lower-case characters are converted into upper case characters and the 14-byte password (cannot be longer) is divided into two 7-byte passwords, which can be cracked alone (sort of). So, 300 billion passwords per second is still a very impressive load, but the keyspace for WinXP passwords is somewhat limited, which would also explain why 80 GB of rainbow tables are sufficient. But correct me if I'm wrong.
- StavrosK 16y agoMicrosoft developed NTLM because LM sucked and made it the default in Windows XP. However, for backwards compatibility, it also hashed the passwords to LM, so, well, you can crack them just as easily. From Vista onwards, I think, LM is no longer used.
- hyuen 16y agoThis is a perfect example of what can you do with RAM that is one order of magnitude bigger than what you can normally afford in regular computers. It would be interesting to see if the effort that is spent writing programs to load stuff from disk and avoiding seeks gets redirected to solve other problems.
- iuguy 16y agoBecause Rainbow Tables only need to be written once, so you could mount the drive read only and get the benefits without the drawbacks.
- nikcub 16y agoWith a separate salt for each password the rainbow table becomes useless. If an attacker has both the salt and the hash, they are back to computing the table (brute force)
- SriniK 16y agoYup. Right on - +5 I am not familiar with windows password scheme but it would be crazy if windows just relied on the hash. Few *nix machines that I deal with have 128 bit salt + password. Even wifi-wpa, blackberry and iphones are doing password strengthening to make brute force method more challenging. As most of us are familiar with, most vulnerable part of the security is us human beings picking the passwords. Underneath algorithms(hashing) are pretty well devised and solid when used properly.
- InclinedPlane 16y agoIf the salt is short (username, email address, phone number, user id, etc.) then this becomes much more of a serious attack, specifically if the salt+password combination is less than 14 characters.
- dchest 16y agoA salt is a salt, not username or any other user information.
- ryanwaggoner 16y agoWhat difference does it make? With a different salt for each password, that info is going to have to be stored in the database anyway, so does it matter much if its a random string or a piece of user info? They still have to precompute tables for each possible salt, unless you're using email as the salt and all your users happen to have the same email address.
- hackermom 16y agoStoring the dynamic salt in the same database together with the user's password hash still doesn't tell you HOW the salt is applied or HOW the product has been digested. This requires insight into the login procedure of the application, and this is where the strength of the salt lies. Adding on this security can be done by storing users' salts somewhere else instead of keeping them in the same table and db as the hashes. My personal method is to work with two salts; one static half (just for the added entropy) kept with the login code, and one dynamic half (always random - not computed from user input) kept in a separate database, away from the hashes. This forces the attacker to acquire not just the database with the hashes, but also the database with the salts, AND the application's login code, in order to get anywhere.
- Smrchy 16y agoConsidering that most password are shorter than 14 characters, everyone implementing hashed passwords without a random salt could just store them as plain text. The rainbow table for the most common passwords (names, cities, pet names etc.) would fit in less than 1GB and would probably yield a very high success rate. There's no need to use complex passwords to prove that hashes without proper salting are bound to fail.
- peterwwillis 16y agoPeople, NTLM hashes have been dead for years. Stop using them. http://support.microsoft.com/kb/299656 http://support.microsoft.com/kb/299656
- mrb 16y agoYou are confusing NTLM hashes with LM hashes. The article you point to is about LM hashes, not NTLM hashes. There is no way to stop using NTLM hashes on Windows.
- peterwwillis 16y agoYes, the article I point to is concerning LM hashes, but NTLM hashes are almost as bad - and you can stop using them. This URL shows you how to force NTLMv2: http://windows-secure.net/O.Reilly-Securing.Windows.Serv/0596006853/securews-CHP-7-SECT-1.html http://windows-secure.net/O.Reilly-Securing.Windows.Serv/059... The idea is to try to force Kerberos authentication only. I can't find any tips on forcing it explicitly (even through group policies) but perhaps there's a firewall method to disable any [NT]LM auth and only allow Kerberos auth. I think some specific services may only allow NTLM (such as Telnet) and some services (such as IIS) may have to explicitly be configured to use Kerberos. (edit) I should mention that I am not an expert on configuring Windows domains or their authentication (obviously) but according to some random guy I asked in IRC, if the SPN is set on a calling ID for a given service, Kerberos will always be used (or attempted anyway) and enabling TCP instead of UDP for the communication may help it get through firewalls etc (and solve some other login-related problems with UDP attempts). However, I think NTLM is the only one that can get through all manner of proxies, firewalls, etc (for IIS for example).
- yuhong 16y agoBTW, don't confuse hashes with authentication protocols. There is no such thing as an "NTLMv2 hash". NTLMv2 is an authentication protocol, and NTLM and LM are authentication protocos too. There is the LM hash and the LM authentication protocol dependent on it, of which both is insecure, but are two different things.
- InclinedPlane 16y agoAlways use a suitably random suitably lengthy per-account salt when hashing passwords. Always.
- d0m 16y agoCan you give an example of what you meant? I understand variable length and random characters for each different accounts? (Sorry, I'm not a native English speaker).
- toni 16y agoCheck out Wikipedia page about Rainbow table, more specifically the section about how to defeat the effectiveness of these kind of attacks ( http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_r... ) There are 2 examples there which should give you a clear idea what your parent post was referring to.
- InclinedPlane 16y agoStart with the assumption that the "bad guys" will have access to your entire database, and source code. From there, how do you protect the security of your users' passwords? As computers get faster in every aspect the ability to crack naively implemented hashes grows greatly, to the point where, as we've seen, 14 character random passwords protected by a one way hash can be cracked in very little time. Using a static salt across all accounts saves you a little, because it means that in order to crack those hashed passwords it will be necessary to re-do all the pre-computed hashes. That takes a lot of time and resources, but once done every vulnerable password (which today means any password less than 14 characters, no matter how secure) can be cracked. By using a good per-account salt it then requires a brute force attack for every account. Which makes any requirements you've instated on minimum password "strength" all the more effective. If, however, you use too short of a salt, or a silly "salt" such as phone number or userid or first name or some such then your salt becomes much less worthwhile. As pre-computed rainbow tables grow, as hardware gets faster eventually you get to the point where you can crack passwords along with naive salts quite readily. Phone number + 8 character password is just 18 characters, it's really only a matter of time before rainbow tables are capable of cracking 18 characters directly, and then using phone numbers as a "salt" is meaningless, because attackers can crack the password+salt directly. What's better is to use a very long and random salt for each and every password (random length doesn't help that much). In this way any pre-computed hashes are worthless, because it's extraordinarily unlikely that any significant subset of all of the possible salt + password combinations have been covered.
- Groxx 16y agoApparently "cracking" now means "looking up in a big list".
- blaix 16y agoI thought the same thing. "With a big dictionary we can lookup easy passwords. With a bigger dictionary and a faster hard drive we can lookup complex passwords!" Is that all that's happening here or am I missing something?
- nikster 16y agoI find it a little boring. It's like a thief got into my house and is now able to open the front door. So what?
- WA 16y agoAnd? You can always trade (CPU-)time for space. Nothing new here.
- Groxx 16y agoBecause saying something is "cracked" because it's in data-set A is worthless. The answer to your question is encoded in the technique of your choice in Pi. It's also because this "crack" is so ridiculously easily negated - salt your hashes. It's an amateur thing that everyone should be doing. There's no cracking going on here, just short-cutted brute-force attacks.
- iuguy 16y agoThe rainbow tables are an implementation of a form of time-memory tradeoff attack using a refined hash reduction algorithm based on the work of Martin Hellman (of Diffie-Hellman fame) - http://en.wikipedia.org/wiki/Rainbow_table http://en.wikipedia.org/wiki/Rainbow_table Basically Ophcrack uses optimised hash chains to speed things up. The precomputed hashes are generated with a specific character set. This works particularly well for unsalted algorithms that support limited character sets such as LM. LM splits the password into two on the 7 character boundary, capitalises it and only supports a subset of printable characters. Also it's unsalted, so while more computationally expensive than NTLM it's actually easier to crack. Rainbow tables for LM can be downloaded from freerainbowtables.net and are about 30-40Gb. NTLM on the other hand supports unicode and very long password lengths. Most rainbow tables are mixalpha, or alphanumeric but short length. Our mixalphanum with symbols rainbow table set goes up to 14 characters and is about just under a terabyte. This is more difficult to put on SSDs cheaply. Your best bet to protecting from rainbow tables is to use a character not referenced in commonly available sets in your password as you inevitably otherwise reach the limits of security vs usability with exceptionally long characters. As I use british keyboards, I generally recommend the £ symbol (British pound) or accent over a vowel. The Euro symbol is also good if you're staying in Europe.
- Confusion 16y agoYour best bet to protecting from rainbow tables [..] is using a salt. No need to use uncommon characters.
- iuguy 16y agoYou are correct. However, pursuant to the use of NTLM or LM, neither of which are salted non-US ASCII characters are about as good as you can get without ridiculously long passwords. For anything else, ready salted is definitely the best crypto flavour. Having said that, a few years ago I co-ordinated a distributed effort to create rainbow tables for standard Oracle database accounts. Oracle's crypto mechanism uses the username as a salt. It meant that we had to generate different (but small as the algorithm was crap) tables for DBSNMP,SYSTEM etc. The same applies to WPA-PSK - don't use a common SSID in the Church of Wifi tables. I guess the moral of the story is that salting alone won't get you out of the woods. You need to think very carefully when it comes to crypto, and get as many second opinions as you can.
- jfager 16y agoWhat stupid linkbait. Cracking LM-hashed passwords is about as interesting as .1 + .2 != .3 in ieee754. Can we at least change the headline to something like "Newsflash: SSDs faster than spinning platters"?
- nixy 16y agoFor some posts the value might be the HN discussion following them, and not the post itself. And as usual when people whine about stuff they don't find interesting, all I have to say is: you < all HN users
- acqq 16y agoYes, the main problem with the article is that they never mention LM. The page they link to too. Only from the "14 characters" we get the idea that they crack LM hashes: http://en.wikipedia.org/wiki/LM_hash http://en.wikipedia.org/wiki/LM_hash "To address the security weaknesses inherent in LM encryption, Microsoft introduced the NTLM algorithm with Windows NT 3.1." That's 17 years old news, that LM is weak. Still what most people unfamiliar with the topic don't know is that LM hashes of your passwords can still be present on your Windows machine, default "for compatibility reason."
- Dylan16807 16y agoAnd beyond that there's not even a hint that it's actually adjacent 7 character passwords.
- hackermom 16y agoThe details are interesting (although completely obvious), but the article is really stupid, as it assumes everyone uses unsalted passwords and MD5 to create hashes. Duh.
- olegkikin 16y agoI call bullshit. Let's say we want to have a rainbow table for all passwords 14 characters long. Let's say we only work with upper and lowercase English characters (26+26) and digits (10), so 62 possible characters. To just store all the possible passwords would take 14 * 62^14 bytes = 1.617 × 10^17 gigabytes.
- nkurz 16y agoI think you're not understanding rainbow tables correctly: http://en.wikipedia.org/wiki/Rainbow_table http://en.wikipedia.org/wiki/Rainbow_table You need to process all the passwords (once) but only 1/N of them (for some large N) are stored on the disk.
- olegkikin 16y agoPardon my ignorance. You're correct.
- cperciva 16y agoThis is what happens when you don't use scrypt.
- drivebyacct2 16y agoThis submission and frankly most of the comments on this HN thread are disturbing. There is a severe lack of understanding of NTLM and the purpose of even hashing, let alone salting, a password... strange.