4 ms·

Indeed, the best resource I've found for adversely affecting brute-force password cracking comes from the *coin cryptocurrencies. GPUs allow us to generate muc

by iuguy 13y ago

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 practical for full mixalphanum 1-8 at 99.99% probability but it looks possible.

chiph 13y ago
Since rainbow tables are now functionally obsolete, perhaps the best use of a salt is not to add randomness, but to enforce a minimum length. So if your salt is 40 chars, even if a user puts in a one-character-long password they're still at a length of 41 and will get some protection. 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.
- Coincoin 13y ago
  Nope, a salt is public. Its only purpose is to force you to brute force one hash at a time. It might also protect you against some attacks particular to your hashing algorithm. It does not slow down the brute force itself. A lonely salted one letter password is as weak as an unsalted one.
  - chiph 13y ago
    Given that an attacker is going to focus on high-value accounts if they can, slowing down a brute force attack on a per-hashed-value basis is pretty much your only defense. Adding complexity (like you would when defending against a rainbow table attack) adds little value when defending against a GPU-based attack that can crank out a billion hashes a minute. So what you can do is add artificial length to the password + salt combination by using a very long salt. By necessity, you'd have to use a better hashing algorithm that will have a lower chance of an attacker getting lucky with a collision, and maybe is "slower" than other hash algorithms.
    - iuguy 13y ago
      Nope. The correct way to do this is to use a password based key derivation function like scrypt[1] or pbkdf2[2]. [1] - https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html [2] - http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
- iuguy 13y ago
  As long as there are unsalted hashes or hashes that use predictable salting mechanisms in use, rainbow tables are far from obselete, functionally or otherwise.

by iuguy 13y ago

chiph 13y ago

Since rainbow tables are now functionally obsolete, perhaps the best use of a salt is not to add randomness, but to enforce a minimum length. So if your salt is 40 chars, even if a user puts in a one-character-long password they're still at a length of 41 and will get some protection. 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.

Coincoin 13y ago
Nope, a salt is public. Its only purpose is to force you to brute force one hash at a time. It might also protect you against some attacks particular to your hashing algorithm. It does not slow down the brute force itself. A lonely salted one letter password is as weak as an unsalted one.
- chiph 13y ago
  Given that an attacker is going to focus on high-value accounts if they can, slowing down a brute force attack on a per-hashed-value basis is pretty much your only defense. Adding complexity (like you would when defending against a rainbow table attack) adds little value when defending against a GPU-based attack that can crank out a billion hashes a minute. So what you can do is add artificial length to the password + salt combination by using a very long salt. By necessity, you'd have to use a better hashing algorithm that will have a lower chance of an attacker getting lucky with a collision, and maybe is "slower" than other hash algorithms.
  - iuguy 13y ago
    Nope. The correct way to do this is to use a password based key derivation function like scrypt[1] or pbkdf2[2]. [1] - https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html [2] - http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
iuguy 13y ago
As long as there are unsalted hashes or hashes that use predictable salting mechanisms in use, rainbow tables are far from obselete, functionally or otherwise.