Best practice for password hashing
in [Cryptography]
|
From: Paul Rubin on 13 Jun 2010 03:03 Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> writes: >> The idea is you send the password and hash to the coprocessor, and the >> coprocessor tells you whether the password is valid. > Mallory seems to always say "valid", I wonder why that is? If Mallory has intercepted the PCI bus interconnect between the coprocessor and the main processor, you are in worse trouble than any hash function can help you with.
From: Phil Carmody on 13 Jun 2010 07:32 Paul Rubin <no.email(a)nospam.invalid> writes: > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> writes: > >> The idea is you send the password and hash to the coprocessor, and the > >> coprocessor tells you whether the password is valid. > > Mallory seems to always say "valid", I wonder why that is? > > If Mallory has intercepted the PCI bus interconnect between the > coprocessor and the main processor, you are in worse trouble than any > hash function can help you with. There is no PCI bus between the processor and the parallel port dongle; there's that nice scanner that you bought from Mallory, though. All we were given was that the additional secret key would be somewhere external, and so modifying that design by moving the verification to that same location would imply that it's not just sitting on a local PCI bus. But we're having to read between lines and extrapolate here. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Paul Rubin on 13 Jun 2010 08:00 Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> writes: > There is no PCI bus between the processor and the parallel port > dongle; there's that nice scanner that you bought from Mallory, > though. All we were given was that the additional secret key would > be somewhere external, and so modifying that design by moving the > verification to that same location would imply that it's not just > sitting on a local PCI bus. But we're having to read between lines > and extrapolate here. Well, the idea was to use stuff designed for the purpose by people who knew what they were doing: http://www-03.ibm.com/security/cryptocards/pcixcc/overview.shtml As usual though, if any of the host hardware is compromised, then trouble is unpreventable.
From: Bryan on 14 Jun 2010 16:03 Paul Rubin wrote: > Carsten Krueger writes: > > Than you coprocessor need to store secret key material. > > Well yes, that's the whole idea. Maybe this is just an issue of > terminology. Maybe, but I worry about confusing the concepts. The salt serves a clear purpose in password hashing: using salt, an attacker who knows many password digests cannot amortize the cost of trial-hashing a candidate password across multiple digests. The salt need not be encrypted or in any way secret to serve that purpose. The salt *could* be secret, to serve as a kind of share of the stored password info, but is the salt particularly good for that? Is encrypting the salt better than encrypting the digest? I don't see it. Should checking a candidate password require multiple keys? Do we keep the keys on hardware tokens? Those are good questions in a thread titled "Best practice for password hashing", and we can engineer solutions, but mixing them up with the concept of salt tends to muddy the issues. -- --Bryan Olson
From: Paul Rubin on 14 Jun 2010 19:02
Bryan <bryanjugglercryptographer(a)yahoo.com> writes: > Maybe, but I worry about confusing the concepts. The salt serves a > clear purpose in password hashing: using salt, an attacker who knows > many password digests cannot amortize the cost of trial-hashing a > candidate password across multiple digests. The salt need not be > encrypted or in any way secret to serve that purpose. OK. That's what I get for posting in a thread that I didn't follow that closely. > The salt *could* be secret, to serve as a kind of share of the stored > password info, but is the salt particularly good for that? Is > encrypting the salt better than encrypting the digest? I don't see it. Right, I've somewhat abstrated away the difference. > Should checking a candidate password require multiple keys? Do we keep > the keys on hardware tokens? Those are good questions in a thread > titled "Best practice for password hashing", and we can engineer > solutions, but mixing them up with the concept of salt tends to muddy > the issues. I agree, keys should be called keys, not salts, even if I goofed up on this. An obvious approach is to store (IV, HMAC(K, IV + password)) in the database, where IV is a random salt (not secret) and K is a secret key, encapsulated in a hardware token if possible. If your token is programmable, you could arrange things so that getting the HMAC out is possible only on password change, and requires knowing both the old and new passwords. You'd pass the old HMAC and both passwords to the token, and you'd get a new HMAC only if the old password was correct. Password verification would involve sending the HMAC and password to the token, and getting a yes/no answer. I have a distant memory of implementing something like this in a way that allowed key migration, but I don't any specifics. I have an idea for an improvement, that I"ll try to work out and write up later. |