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."
Isnt this the good old 2 factor authentication ?
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.
This was proven to be insecure. its does not need to be on the file system to be read.
It needs to be in plain text to be used, and It needs to be in memory.
which means DUH That it can be read OUT of memory.
Let me fucking google that for you:
https://www.google.com/search?q=reading+encryption+keys+in+memory&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
You created an HSM, congratulations?
We always hear about new cool stuff, and then someone quickly turns around and breaks the stuff.
Can someone explain why we don't just use SSH certificates, so that the server effectively only stores the user's id_rsa.pub for authentication? And before someone says "yeah, but then all someone has to do is copy your .ssh folder," keep in mind that individual certificates can be password protected, so it's both something you have -AND- something you know. Granted, there would be plenty of idiots that don't use passwords, or that use hunter2 or 12345, but those people are already screwed anyway.
We've had this technology for years. Why isn't it widespread? Storage space? Too hard for average joes to use?
Anyone have a clue?
...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.
This also assumes that any system would be able to brute-force mass ignorance. It's 2014 and people still use "password" and "password1" to secure their shit. The only miracle here is if people actually get security one day.
Hardware Security Modules (HSMs) offload crypto work to a trusted hardware device so that loss of a server doesn't mean losing all the data inside. HSMs can be had for $1000 and are very mature and secure. This looks like the beginnings of a home-brew cheaper version - or am I missing something?
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?
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...
They are encouraging folks to connect to their system to send passwords to scramble over HTTP. Does anybody else see a problem with this proposal?
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.
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 problem that the people who would normally use the crappy passwords will either not password protect their certificates or use crappy passwords on them too. Even if they do this, it does mean that the server password DB being stolen wouldn't reveal their keys but it does mean you need some way to revoke certificates and get new ones if yours are compromised.
In reality, using the same password across multiple sites is a much bigger problem (for those users) than using rubbish passwords if the site is managing passwords correctly. If the server is salting the passwords and using good hashes, as well as limiting the rate of password attempts and implementing some form of lockout then everything beyond the most abysmally bad password is reasonably safe.
However, if a user has the same password for their e-mail account, and the dodgy torrent forum they just signed up for using that e-mail address then they are screwed any which way.
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.
They're not SSH certificates, but PKI client certificates are quite common in enterprise applications. It does add to management complexity (storage, etc.) but I agree they can be more secure. At least until users start replicating their private keys to multiple devices, but at least you can revoke them.
10 random chars are good for 65bits. Log(92^10)/Log(2) = 65.24
Check out the GNUK, It's a low-power ARM microcrontroller can can keep a private key private. Sign it's public key with the private key you used to set up the account, and use gpg-agent to complete the authorization. I
Also, RSAs authenticator keychains. And more.
http://en.wikipedia.org/wiki/S...
http://en.wikipedia.org/wiki/I...
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.
http://lkml.org/lkml/2005/8/20/95
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.
Please help metamoderate.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
Virtually every smartphone and computer seems to come with a camera these days.
How do you get more secure than the iris?
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!
How about their remote API over HTTP?
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 improvement I can see with that would be going to a public/private key system or having a hardened authentication server that used Kerberos. We really do not need more hardware dongles that are not really a standard. Having standardized hardware key protection for SSH private keys would be nice, but oftentimes, the perfect is the enemy of the good... if we can go with SSH keys/certificates and/or a standardized OTP, that is 95% of the battle right there... an attacker would then have to start attacking individual endpoints.
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
The password / key used for SHA1-HMAC is actually 32 characters long - up to about 199 bits of entropy with the character set used (a-zA-Z0-9+10 special chars)
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
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?
If Pandora's box is destined to be opened, *I* want to be the one to open it.
After fixing the inevitable bugs, I want it on my wristwatch with a limited-distance, on-only-if-button-pressed communications link.
davecb@spamcop.net
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
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Not if one stores a long, fixed salt in the device.
(Here fixed means fixed over all users.)
If Pandora's box is destined to be opened, *I* want to be the one to open it.
That does not seem true. If it was, it would mean there is a known plaintext attack versus HMAC, and would be considered broken.
http://crypto.stackexchange.com/questions/8500/with-hmac-can-an-attacker-recover-the-key-given-many-known-plaintext-tag-pairs/8540#8540
Not only is the concept not new, it is already commercially available. In fact, your computer may already have this capability. It's called the TPM chip. It can store your private keys and authenticate using PKCS11. It can also seal your password database to the hash of your entire boot process, ensuring that it is accessible only if your system is booted properly. Identity theft is a real problem and can cause you a lot of grief, so use your TPM chip already!
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.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
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.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
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.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
How?
You can always use two salts (one based on the username/password if you like, and one fixed one stored in the device).
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Have they never seen a PKCS#11 device?
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 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.
Sure I'm paranoid, but am I paranoid enough?
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.
Completely futile exercise as you have the length wrong as well as the size of character set. Try 32 character l permutation of
76 characters.
Do it, publish it at crypto conferences, become famous:-) The key is 199 bits long. You can try to use collision attacks on SHA-1 but that would be again stuff securing life-long glory.
We would be interested in PHP or Python support for TPM! The TPM is a bit tricky to use in virtual machines - my guess is that 99% of online servers run in VM, am I far from truth?
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.
it should be stated for record that we have links with the security group at University of Cambridge as well as alumni but Scrambler was developed by a startup Smart Crib Ltd.