81–90 of 123 posts
Earlier quoted context omitted.
What if a site uses 128-bit salts generated by a good (perhaps hardware-based) RNG?
That will remove pre-computed rainbow tables from the equation.
Earlier quoted context omitted.
Right next to the hashed passwords. The point of salting isn't to add an additional level of secrecy, it's just to prevent the reuse of hashing work for attacking other users.
But doesn't this render the process useless? If an attacker gets access to the hashes, he also gets access to the salts. If both hashes and salts were isolated, I suppose it would be much more secure, although maybe too slow.
What you're thinking of is a secret-splitting scheme; where you split a secret among multiple parties, where you need the information from both parties to reconstruct the secret. That's a valid cryptographic technique, but that's not what's meant when you say "salted password".
The problem is, for passwords, that approach isn't really workable. Whatever machine is verifying the passwords will need access to the full hash to do so, so if it's compromised, you could get access to the full hash.
I suppose you could split the verification into two parts, on two separate machines. Each one would have it's own password database, with independent salts, and the machine trying to authenticate the user would request verification from each of the other machines before allowing you in. However, that would make your password system slower and more fragile; now if either of those machines goes offline, your login functionality breaks (and yes, you could do a "two out of three" system to avoid that, but now you're talking about tripling your hardware requirements just for your password verification system).
Really the best bang for your buck will come from (a) securing your system so that it doesn't reveal your password database in the first place and (b) using bcrypt, scrypt, or PBKDF2 to make brute forcing a database that is disclosed much more difficult. It's far more likely that you will build a secure system by following basic security practices like isolating services and giving each the minimum privilege that it needs, doing code review, keeping inessential services off of important machines, using prepared statements rather than building SQL queries from user-supplied strings, and so on, as well as using off-the-shelf security components that have been well tested like the above hash algorithms, than you will by designing your own password system using some novel technique to spread the secret out among multiple machines.
Earlier quoted context omitted.
I'm in the middle of researching re-evaluating rainbow table attacks in light of Moore's law, GPUs and Crack (lookup) tables, I've also looked into countermeasures. What you're describing is partially correct. When you crack passwords (either with rainbow tables or by brute force) you generate an iterator or use a dictionary and work through this generating hashes (with rainbow tables this works via a series (or chai…
If you're targeting a single hash I was going to mention this. If your user record has a column called "IsSuperuser", then an attacker is going to concentrate on those users, since the reward for cracking them is so much higher. Individual salts or not, with multi-GPU based brute-forcing, they won't stand long.
GPUs allow us to generate much much longer chains in rainbow tables than before. This means that there's a re-evaluation of space trade-off based on chain length, so simple salting mechanisms (e.g. 4 char alphanumeric such as Cisco Type 5) become feasible. For now they're not incredibly practical for full mixalphanum 1-8 at 99.99% probability but it looks possible.
Cue a test-how-strong-your-password-is service where security conscious individuals can test how their particular password stands up against these new attacks.
The 8 char limit is very low now. The limite should be raised to 30 characters.
Earlier quoted context omitted.
If you're targeting a single hash I was going to mention this. If your user record has a column called "IsSuperuser", then an attacker is going to concentrate on those users, since the reward for cracking them is so much higher. Individual salts or not, with multi-GPU based brute-forcing, they won't stand long.
Indeed, the best resource I've found for adversely affecting brute-force password cracking comes from the *coin cryptocurrencies. GPUs allow us to generate much much longer chains in rainbow tables than before. This means that there's a re-evaluation of space trade-off based on chain length, so simple salting mechanisms (e.g. 4 char alphanumeric such as Cisco Type 5) become feasible. For now they're not incredibly pr…
Combine that with a skip + take algorithm (not just appending the salt and password together) where you interleave the salt and password, and you might have some improved defense.
Earlier quoted context omitted.
The "exponential wall" means the longer your password is the less likely it is to fall. A 10 letter password is in a 26^10 keyspace. Add one more letter and it takes 10 times longer to crack -- assuming of course your password is not part of some of some combination of short common dictionary words. What I find really interesting is that the same kind of attack vector (combinations of common words) is being used as t…
not 10x longer, 26x longer (and that's assuming lowercase a-z only)
But hey, maybe someone can prove me wrong. Anyone care to take a crack (pun intended) at 1a323a3185b1dbee3a0ba1f4c3c9f674
I'll send an entire shiny bitcoin to anyone who can get it right.
Earlier quoted context omitted.
"Pepper"s are essentially meaningless and provide no real benefit over a salt. And you should be using bcrypt anyway.
> "Pepper"s are essentially meaningless and provide no real benefit over a salt. Citation needed. There appears to be a case where it could prove to be an advantage: http://security.stackexchange.com/questions/3272/password-ha... > And you should be using bcrypt anyway. Yeah, except bcrypt isn't always an option. Eg: on Google App Engine.
If bcrypt isn't an option, you straight-up need a better platform. It's inexcusable to refuse to protect your users--if you're not using bcrypt/scrypt/PKBDF2 you're mistreating your users.