The 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.
Cracking 14 Character Complex Passwords in 5 Seconds
31–40 of 64 posts
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#32What 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"?
Yes, 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
"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."
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#33Apparently "cracking" now means "looking up in a big list".
I 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?
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#34Earlier quoted context omitted.
A salt is a salt, not username or any other user information.
What 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.
Storing 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.
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#35Apparently "cracking" now means "looking up in a big list".
And? You can always trade (CPU-)time for space. Nothing new here.
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#36Earlier quoted context omitted.
What 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.
Storing 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 has…
This is silly. The purpose of a salt (what real cryptographers call a nonce) is simply to make it infeasible to precompute tables. Store it in the open, in the most convenient place possible; don't jump through hoops so you can pretend you're getting more security than you are.
If you really cared about the security of your passwords, you'd use scrypt, bcrypt, or PBKDF2, all of which are markedly more secure than "salted" anything.
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#37Earlier quoted context omitted.
Your best bet to protecting from rainbow tables [..] is using a salt. No need to use uncommon characters.
You 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 t…
You say "definitely the best crypto flavor" as if you knew. But you don't, because no serious system designer cares about rainbow tables. Unix solved this problem in the nineteen seventies. Real system designers care about incremental crackers, of the sort used since the 1980's to harvest thousands of passwords from compromised Unix boxes, of the sort that forced Unix systems in the 1990's to adopt "shadowed" password files.
The solution to that threat, the real threat, is scrypt, bcrypt, or PBKDF2 --- the "adaptive" hashes that can be tuned to trade a marginal increase in defender cost for an untenable increase in attacker cost.
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#38The 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 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…
Your best bet to protecting from rainbow tables [..] is using a salt. No need to use uncommon characters.
Also, using a hash (such as bcrypt) that can be made arbitrarily expensive. With a cost of 14, it takes this computer four seconds of CPU time per attempt to hash each password. While merely annoying for one user, that would really slow down rainbow table creation.
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#39I 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.
Re: Cracking 14 Character Complex Passwords in 5 Seconds
#40Always use a suitably random suitably lengthy per-account salt when hashing passwords. Always.
Can 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).