3 ms·

First of all, only the initial release day, and the EC2 GPU killer app has been discovered. Second, store passwords as a salted hmac, not just a shaXsum. It is

First of all, only the initial release day, and the EC2 GPU killer app has been discovered. Second, store passwords as a salted hmac, not just a shaXsum. It is still usually a singel command, and WAY more secure than simple shaX or mdX, as it eliminates the risk of prefix/postfix attacks. Adding the salt makes dictionaries pretty irrelevant (as long as each install has a unique salt). I mean GEEZ; even php does it now: http://us2.php.net/manual/en/function.hash-hmac.php http://us2.php.net/manual/en/function.hash-hmac.php

sedachv 16y ago
This is something I've been wondering about - how can you use pre/postfix attacks on passwords? I can't see any obvious ways it would help, and googling hasn't produced any information.
jrockway 16y ago
An HMAC is a message authentication code, not a salted hash. It allows you to send a message over an insecure link and verify, by providing the secret key, that the message (and hash) was not tampered with. Also, a salted hash is not a particularly good storage mechanism, ranking only above cleartext and naively-hashed storage. Once someone discovers the salt, then it's fairly easy to attack the password database in the same way that you'd attack an unsalted hash -- make a list of all possible passwords, hash them, and see what matches. Machines like the one mentioned in the article can make trillions of these in a second. The problem with hashes for protecting passwords is that they can be calculated very quickly; good for ensuring that every packet on your VPN arrived without errors, bad for ensuring that a bad guy can't make a list of passwords, hash them, and check the hashes against your database. The best password storage mechanism is via the use of a "slow" hash function like bcrypt or scrypt. You set these up so that it takes a full second of CPU time to generate the hash from the message. Then instead of trying trillions of passwords a second, the attacker can only try one! If you're using Perl, use Authen::Passphrase. It's a module that lets you easily use bcrypt for new passwords but your old method for older passwords. With an API like that, there's no excuse for endangering your users by using salted hashes!
TomasSedovic 16y ago
Shouldn't the nonce be different for each password rather than for each install (I take it that by "install" you mean a server or an application installation)? Nonce-per-password is used in BCrypt and while I don't know much about security, that's the vibe I'm getting from the folks who do.
tptacek 16y ago
HMAC does nothing to prevent iterated brute force cracking, the kind of cracking that most benefits from GPU acceleration. There is virtually no security benefit to using an HMAC construction over the bare hash function itself. Listen to 'jrockway.

sedachv 16y ago

This is something I've been wondering about - how can you use pre/postfix attacks on passwords? I can't see any obvious ways it would help, and googling hasn't produced any information.

jrockway 16y ago

An HMAC is a message authentication code, not a salted hash. It allows you to send a message over an insecure link and verify, by providing the secret key, that the message (and hash) was not tampered with. Also, a salted hash is not a particularly good storage mechanism, ranking only above cleartext and naively-hashed storage. Once someone discovers the salt, then it's fairly easy to attack the password database in the same way that you'd attack an unsalted hash -- make a list of all possible passwords, hash them, and see what matches. Machines like the one mentioned in the article can make trillions of these in a second. The problem with hashes for protecting passwords is that they can be calculated very quickly; good for ensuring that every packet on your VPN arrived without errors, bad for ensuring that a bad guy can't make a list of passwords, hash them, and check the hashes against your database. The best password storage mechanism is via the use of a "slow" hash function like bcrypt or scrypt. You set these up so that it takes a full second of CPU time to generate the hash from the message. Then instead of trying trillions of passwords a second, the attacker can only try one! If you're using Perl, use Authen::Passphrase. It's a module that lets you easily use bcrypt for new passwords but your old method for older passwords. With an API like that, there's no excuse for endangering your users by using salted hashes!

TomasSedovic 16y ago

Shouldn't the nonce be different for each password rather than for each install (I take it that by "install" you mean a server or an application installation)? Nonce-per-password is used in BCrypt and while I don't know much about security, that's the vibe I'm getting from the folks who do.

tptacek 16y ago

HMAC does nothing to prevent iterated brute force cracking, the kind of cracking that most benefits from GPU acceleration. There is virtually no security benefit to using an HMAC construction over the bare hash function itself. Listen to 'jrockway.