University of Cambridge Develops Potentially More Secure Password Storage System 70
An anonymous reader writes "University of Cambridge's S-CRIB Scrambler resides in a Raspberry Pi and performs a hash-based message authentication code (HMAC). 'The secret 10-character key used to generate the HMAC resides solely on the dongle. Because it's not included in password tables that are stored on servers, the key could remain secret even in the event of a major security breach.' There are pros and cons associated with this method, of course, ranging from scalability to loss of access due to device hardware failure. As with all current options for password security, there's no guarantee that even this system remains secure."
Usefulness is reduces if a single account is known (Score:5, Interesting)
As was pointed out by someone on Ars [arstechnica.com], even if the secret key used by this device isn't stolen it can be bruteforced by having a single known account on the system. This is not a trivial problem, because it seems that they are using SHA1 (on the basis that the key can never be stolen, so the hashes don't need to be so strong). As such, there is a mountain of good gear out there for running lots and lots of hashes fast.
Basically:
1. Create account/password with online retailer
2. Steal user database for online retailer
3. Find you own account, for which you know the username and password (and salt, because it is in the database) and associated hash
4. Bruteforce the HMAC key required to get the stored hash using your username, password and salt
5. Use that same universal HMAC key for attacking all the other accounts
6. profit?
This assumes that there is a single key used for the HMAC and stored on the dongle, but it seems that is actually the case.
It does make getting all the passwords a bit harder, but it isn't a miracle cure.
Makes sense (Score:5, Interesting)
This isn't by any means a new concept; systems that care deeply about security have been using host security module (HSM)-based keyed hashing for decades. But doing it in an inexpensive, readily-available device is a really good idea for systems that don't need the physical security features offered by HSMs -- and that's nearly all systems. The key is to make sure that the communications channel between host and dongle cannot be used to compromise the dongle. Ideally, you should just ensure that the dongle system will not -- under any circumstances -- respond to anything other than hashing requests, and that codepath should be carefully validated for security bugs.
Next please. (Score:4, Interesting)
All that has been done is the HMAC key is being stored on an external device. A device that can only handle 5.6 transactions per second.
They talk about clustering them, but that means the private key must be the same for each node in the cluster, unless you tied nodes to users. Your tied user accounts get locked when the hardware fails.
If the private keys are the same, that key needs to be stored somewhere else. Once you find that key, you find the passwords.
They explicitly say you can clone dongles. They say there is protection - you can only overwrite the private key before you make real requests. Great, but pointless. You can always read the key from the dongle you're cloning. Otherwise hardware replacement and cluster expansion is impossible.