Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server!

Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without stealing the device itself it'd be impossible to properly salt the passwords for hashing.

If you have a dedicated cryptography module, you would be better off storing encrypted hashes, and asking the cryptography module to decrypt the hash and verify the password against it. Salting the hash (and using an expensive hash) would still provide a second layer of defence in case the module is compromised (and provide a physical rate limit to online attacks even if the server is compromised).

Hm. I suppose a hacky-ugly-cheapo way to do this would be to run a daemon under root which accesses a local sqlite db or whatnot (and that file is only reachable by root). When a web/whatever app needs to check a hash, it asks the daemon whether this user + this hash are valid. This could be done e.g. using unix sockets, and the daemon could do rate limiting (one attempt per two seconds for a specific user, etc). The exchange could also be encrypted using a pre-defined key, so having access to the socket wouldn't even let you sniff the exchange.

If a cracker gets access to the web app, they'll be able to monitor the exchange, but they'll need actual privilege escalation to be able to read/dump the whole hash database.

If the contents of the device can be dumped, the problem remains. If not, you have no copies of your database, so when (not if) the device or the server it's connected to fails, your site is down, and once you've brought it back up, all of your users must go through a password reset process.

That one server/device is now a single point of failure and a bottleneck in processing logins.

You're also still relying on the security of a computer, just a special-purpose one.

I didn't say anything about reliability or single points of failure. I merely pointed out that it was possible to separate the salt from the hashes and gain security that way. Whether this is practical or not depends on how important security is to you.

And yes, it would not be possible to dump the contents of the devices.

The proposal is fundamentally impractical, and thus not a "security gain" in any meaningful sense. It's the equivalent of preventing cipher algorithm breaks by using nothing but one-time pads.

It's also theoretically impure in any case, as you've done nothing but add an additional peripheral to the computer. You're seeking obfuscation, not real cryptographic integrity.

No, using an HSM to store a secret is done widely (in banking, for PINs), and it's entirely possible to implement them in a way where individual device failures can be mitigated.

The only issue is cost of HSMs; they're about $20k/ea right now, since there are only two significant vendors, and they're not widely used.

If someone wanted to do "HSM for general purpose web login, to eliminate the DoS potential of scrypt, and the brute force hash db problem of anything else, and the idiocy of plaintext", the price could probably drop down to $500 or less.

>It's also theoretically impure in any case, as you've done nothing but add an additional peripheral to the computer. You're seeking obfuscation, not real cryptographic integrity.

It's not obfuscation. The peripheral has a far smaller attack surface than a server. This is real security, even if it comes at a cost of reliability (though one can envision ways of fixing this, too).

It's operational/system security. That's not the same thing as cryptographic security.

Stop trying to patch a hole that isn't there. Salt is not secret data. If you want to protect the hash with secret data, take A1kmm's advice and use the smart card to encrypt it. But don't call that a salt, because it fundamentally is not one.