Slashdot Mirror
University of Cambridge Develops Potentially More Secure Password Storage System
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."
As was pointed out by someone on Ars, 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.
Sort of, but the server (rather than the client) has the device, and 'having' the device is needed (ideally) in order to check user passwords at the server end. So rather than being used to identify a user to the server, it is used by the server to generate the password hash which is stored and compared.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
How do I log in to my account from a new device? What if I'm travelling and I don't have my computer with me, how do I use an internet cafe?
Good point. The weakness is easy to fix, though: Use a longer key. The only problem here is that the key is only 10 characters, which is probably only 40-50 bits of entropy even if the characters are chosen randomly. Use a 128-bit random key instead and known plaintext will become useless.
Oh, and new systems should use SHA-256, or SHA-3, not SHA-1. But that's probably not an issue in practice.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
4. Bruteforce the HMAC key required to get the stored hash using your username, password and salt
It seems far fetched someone would go through all of the trouble to deploy such a solution and yet select a key with insufficient entropy to protect the system from any remotely feasible brute force attack.
10 random chars are good for 65bits. Log(92^10)/Log(2) = 65.24
Absolutely, but if the summary and the Ars article are to be believed then the on-device key is 10 characters long. From TFA, the output characterset appears to include 76 characters, so it seems plausible that they are using this same set for the on-device key as well. They are using HMAC-SHA1, and it seems (from Ars) that they are not using iterated SHA1 (i.e. they are using a single pass).
Not saying anyone would deploy it like that.
How do you get more secure than the iris?
By using the anus instead.
Votez ecolo : Chiez dans l'urne !
It seems far fetched someone would go through all of the trouble to deploy such a solution and yet select a key with insufficient entropy to protect the system from any remotely feasible brute force attack.
15 years ago, there were people saying the exact same thing about [other encryption technology].
Never underestimate the ability of the technically incompetent to kludge something into semi-working order, while simultaneously botching all the important steps.
[Fuck Beta]
o0t!
As you always would - with your username and password.
What these guys propose doing is server side - you enter a password, the server hashes it, it's sent to the box which signs it, then the resulting hash is spit back out and stored in the database. When you log in, you provide the password, it's hashed by the server, send to the box, and the resulting signed hash is compared with the stored hash.
The reason for this is to make breaches of websites that much less useful - if the attackers get the database, they won't have the HMAC key so they can't really run through and crack the hashes. The website can regenerate a new HMAC key and force everyone to recreate their passwords (which can be the same) and they'll end up different in the database again because they are signed with the new key.
Since the key never leaves the hardware box, it's impossible to extract it when you're grabbing the user database.
The big problem is, well, it protects the user with less benefit and more cost tot he website in question, meaning few, if any, would actually implement it because the benefits go solely to the user.
You wouldn't use an RPi in production, of course. x86 would be just as silly. A $3 hardware encryption chip attached to most any microcontroller would be several thousand times faster and an order of magnitude cheaper than x86. x86 is for general purpose computing - this is a single purpose device.
So why did they use a raspberry pi? Probably because they already had one, or several, already knew how to use it, and could put the code together in an hour or so to demonstrate the concept and have a little fun doing it.
English words average between 1-2 bits per character. 10 random characters may be good for 80 bits if you can really use 2^8 values, or maybe 65 bits if you're only choosing randomly over 92 values per character, but if you choose actual words for your password, it's a lot less. The OED has about 200K words (~18 bits), so you get maybe 20-24 bits depending on word endings, l33t-spellings, capitalization variants, combinations of short words, etc.
128 bits is theoretically sort of secure today, as long as it's used in ways that aren't susceptible to birthday attacks (probably not an issue here), and as long as there's enough real entropy used to generate those bits. Even that's a realistic problem here - are you going to remember a passphrase that has 8-10 random words from the OED? Or are you going to have to keep them written on a yellow sticky note in your office, or dogear the pages in your dictionary that have words highlighted in 7 different colors so you know what order they're in?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
RPi already comes with an ethernet port on it, and you don't have to bitbang USB like you would for the standard Arduinos (though there are libraries like V-USB that'll do that for you), and the CPU's a lot faster so you don't have to optimize crypto libraries yourself.) And you can easily attach a keyboard to it for inputting passphrases instead of using the PC, which is critical for doing the security right.
This is an application where you don't need a lot of speed - if it takes a second to cough up a password, that's fine, so you don't need a $3 hardware crypto chip to go with the $1 ARM CPU, though of course you certainly could make a much cheaper piece of ARM hardware if you wanted.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks