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."
2 factor? (Score:1)
Re: (Score:3)
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.
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.
Re: (Score:3)
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?
Re:Usefulness is reduces if a single account is kn (Score:4, Insightful)
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.
Re: (Score:2)
You've missed the boat completely.
I was replying to someone who said we should be using certificate authentication.
By the way, the key can leave the hardware box. They explicitly built that functionality so they can be cloned to make a cluster.
Re: (Score:2)
I think basically using client certificates is too hard for average joes to use, especially across devices.
Different browsers on one machine don't share certs. You need to be able to share certs across devices, which means copying them somehow while keeping them secure - and not just keeping them all in DropBox. If you're using certificates, you can't just log on from your friend's phone when you left yours at home.
Also, if you're trying to replace insecure passwords with certificates, then you have the pro
Re: (Score:2)
Even better, perhaps a standard of crypto token that works with USB? Right now, there is one for cards, but for USB tokens, I need special drivers for every maker (be it Safenet, Gemalto, or whomever.)
That way, the private ssh key can be used on the device, but never leaves it unless one is doing a backup of it to another device, or to other media where it is stored (encrypted with a passphrase) for safekeeping.
For two factor authentication, things like the Google Authenticator is good enough. The only im
Re: (Score:3)
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.
Re:Usefulness is reduces if a single account is kn (Score:5, Informative)
Re: (Score:2)
10 random chars are good for 65bits. Log(92^10)/Log(2) = 65.24
Heh. Good catch. I should have done the math, or at least thought about it for another second or two. Five bits per character assumes a character set of 32, which is obviously silly.
Words are MUCH less secure than random chars (Score:3)
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 i
Re: (Score:2)
10 random chars are good for 65bits. Log(92^10)/Log(2) = 65.24
Quick question. Where did the 92 come from? Uppercase + Lowercase + digits + special chars? I'm struggling to get to 92 here.
Re: (Score:2)
Take a look at your keyboard, and count all the keys that produce a character of some sort. Now multiply by 2 (for using the shift key). And that is your approximate number of readily-available characters for a password. Mine has 94 (47 character keys), but I'm sure there are some that are just a bad idea.
I personally just assume that Bengie [slashdot.org] is a greybeard and is used to the old keyboards, or that he is big into security and that is the exact number of characters allowed by most security tools.
Re: Usefulness is reduces if a single account is k (Score:1)
Re: (Score:1)
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:1)
Re: (Score:2)
It's a proof of concept, not a commercial product. No-one would deploy an RPi in a production environment, they would develop a low power and much faster USB dongle with secure storage. Probably some kind of ARM based micro, although you can get dedicated ICs with a USB interface.
Re: (Score:1)
Re: (Score:2)
That certainly changes things. The summary for this article and the Ars article both suggested that the key was 10 chars long, and I couldn't find a specific number in TFA to replace it with.
Re: (Score:2)
I have a bitcoin asic that does 8 billion sha256 hashes per second, and it is a cheap asic. Why not just throw each password+salt through a sha256 hash 1 million times? The requirement for brute force guessing it would be insane even with a really expensive asic, yet simple authentication if you already had the right password would be cheap. Just flat out forget about trying to do it with a regular CPU or GPU.
Re: (Score:2)
This assumes you know the salt used to compute the hash.
The arstechnica reply states this explicitly, but I don't understand this assumption.
How can the hacker be assumed to know the salt?
Re: Usefulness is reduces if a single account is k (Score:2)
The salt is generally stored as the first few chars of the hashed password. If the have a password, they almost certainly fave the salt used for it as well
Re: (Score:2)
Not if one stores a long, fixed salt in the device.
(Here fixed means fixed over all users.)
Re: (Score:2)
Not if one stores a long, fixed salt in the device.
(Here fixed means fixed over all users.)
That sort of defeats the purpose of the salt.
Re: (Score:2)
How?
You can always use two salts (one based on the username/password if you like, and one fixed one stored in the device).
Re: (Score:1)
Re: (Score:1)
Not only cheaper, also it provides no physical security and can leak the master key. Hooray!
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.
Re: (Score:1)
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.
Re: (Score:1)
Scrambled Eggs (Score:2)
Looks like all their doing is storing an encryption key on a separate hardware component and offloading all operations requiring said key to hardware. Isn't this what TPM already does? Why reinvent the wheel?
See also
http://tools.ietf.org/html/dra... [ietf.org]
API over HTTP??? (Score:1)
Re: (Score:1)
Re: (Score:1)
Smart card, secure element, HSM (Score:2)
Also, RSAs authenticator keychains. And more.
http://en.wikipedia.org/wiki/S... [wikipedia.org]
http://en.wikipedia.org/wiki/I... [wikipedia.org]
This has been invented a million times. The practicality of carrying a device specific for this purpose holds back the widespread use of stuff like this.
why a RasPi? (Score:2, Insightful)
Can someone please explain why this is attached to a RasPi?
Among other things, the poor architecture and inability to run a standard distribution makes it a remarkably bad choice when you can get low-power x86 boards that will wipe the floor with it.
because it's a cheap, easy, fun proof of concept (Score:5, Insightful)
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.
Blog cred, and easier than Arduino (Score:3)
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 pa
Re: (Score:2)
There are plenty of cheap microcontrollers with real USB ports, crypto functions and most importantly secure storage areas that could be used. Smaller, lower power, faster and cheaper.
Re: (Score:1)
Can someone please explain why this is attached to a RasPi?
Because doing anything with a Raspberry Pi gets you free Slashvertisement: Dan Cvrcek, the author of the blog post, is also the one selling the USB dongle used [s-crib.com].
Re: (Score:1)
Whatever happened to iris scans? (Score:2)
Virtually every smartphone and computer seems to come with a camera these days.
How do you get more secure than the iris?
Re:Whatever happened to iris scans? (Score:4, Funny)
How do you get more secure than the iris?
By using the anus instead.
Re: (Score:1)
The problem with an iris I suspect is taking the image of a random iris scan, and converting it to a number in such a way that it consistently gets the same number (in the sense that all data is numbers), but also introduces significant entropy.
You can't just take a picture of the eye, and use that to salt a password over the wire, and if your sending the actual scan of the eye over the wire to be compared, it begins to run into the security issues of a password in general.
Good in principle, for my wristwatch (Score:2)
Resides in a Raspberry Pi? (Score:2)
University of Cambridge's S-CRIB Scrambler resides in a Raspberry Pi...
No it doesn't. The S_CRIB Scrambler is a trusted hardware component implemented as a USB dongle that just happens to be plugged into a Raspberry Pi as a host server.
The current implementation uses Raspberry Pi as an "untrusted" host for web service. It is an inexpensive but sufficiently powerful platform for our password scrambling system.
This could just as easily be plugged into a server or any other PC. My point is that the device has nothing to do with and has no dependency on the Raspberry Pi and to imply otherwise is disingenuous.
10 Character Key? (Score:2)
From the article:
The dongle (Scrambler) uses 4 keys / passwords.
1 - 10 characters long is used to identify clusters (when more than one dongle is used to boost throughput).
2 - this is the actual key for SHA1-HMAC
3 - this is used for initialisation vectors.
4 - encryption key for remote commands ENSCRAMBLE and ENGETID. This key is shared with the client (Wordpress in our case) to provide end-to-end encryption of passwords sent for scrambling.
Here are the details from the article about key lengths, etc.
S-CRIB Scrambler Design Basics We use the same hardware as for our Password S-CRIB and only re-implemented the firmware to add required functionality. The keys / passwords now have 32 characters so they can be directly used with AES-256. Each password can give provide up to 199 bits of entropy as we use 76 different characters. The source of passwords is a combination of a "dongle key" (unique for each Scrambler) and a random SHA1 key generated using microsecond timer applied on communication between Scrambler and the host PC.
Ridiculous (Score:2)
Re: Ridiculous (Score:1)
Re: (Score:2)
University of Cambridge ... (Score:1)