Forgot your password?
typodupeerror
Encryption Security

University of Cambridge Develops Potentially More Secure Password Storage System 70

Posted by Unknown Lamer
from the tpm-minus-bad-things dept.
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."
This discussion has been archived. No new comments can be posted.

University of Cambridge Develops Potentially More Secure Password Storage System

Comments Filter:
  • Isnt this the good old 2 factor authentication ?
    • by gnoshi (314933)

      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.

  • by gnoshi (314933) on Monday March 10, 2014 @10:17PM (#46451831)

    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.

    • by swillden (191260)

      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.

      • by Bengie (1121981) on Monday March 10, 2014 @11:02PM (#46452061)
        10 random chars are good for 65bits. Log(92^10)/Log(2) = 65.24
        • by swillden (191260)

          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.

        • 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

        • by Fnord666 (889225)

          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.

          • by mdielmann (514750)

            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.

        • Completely futile exercise as you have the length wrong as well as the size of character set. Try 32 character l permutation of
    • 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.

      • by gnoshi (314933)

        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.

      • by TubeSteak (669689)

        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.

      • by AmiMoJo (196126) *

        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.

    • 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)
      • by gnoshi (314933)

        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.

    • 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.

    • 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?

    • 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.
  • Makes sense (Score:5, Interesting)

    by swillden (191260) <shawn-ds@willden.org> on Monday March 10, 2014 @10:45PM (#46451977) Homepage Journal

    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)

    by viperidaenz (2515578) on Monday March 10, 2014 @10:45PM (#46451983)

    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.

    • You can't "always read the key from the dongle you're cloning". You can only do it at the initialisation phase = before the first scrambling command. You can print it, store in a strong box, split into components and put each into a different strong box . and only again use it when you need to create a clone of a dongle already in use.
  • 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]

  • 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?
    • I encourage to read the specs. HTTPS is your option if you have money, expertise and time to sort out proper certificates. Simply run the web service with HTTPS/SSL switched on. If you don't want to do that, the API provides end-to-end encryption of sensitive data.
      • I did a quick read and it appeared they were passing passwords from the client to the unit where the dongle was plugged in via HTTP. Is this not the case?
  • 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)

    by SuperBanana (662181)

    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.

    • by raymorris (2726007) on Tuesday March 11, 2014 @01:25AM (#46452479)

      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.

      • 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

        • by AmiMoJo (196126) *

          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.

    • by Kryczek (2500658)

      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].

    • cheap, easy to setup, runs Debian (almost) so our code (web service in Python) is likely to be portable.
  • Virtually every smartphone and computer seems to come with a camera these days.

    How do you get more secure than the iris?

    • by jalet (36114) on Tuesday March 11, 2014 @12:48AM (#46452383) Homepage

      How do you get more secure than the iris?

      By using the anus instead.

    • by AvitarX (172628)

      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.

  • After fixing the inevitable bugs, I want it on my wristwatch with a limited-distance, on-only-if-button-pressed communications link.
  • 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.

  • Where did the submitter get the quote that says this uses a 10 character key for the HMAC?
    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.

  • Have they never seen a PKCS#11 device?
  • 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.

The Universe is populated by stable things. -- Richard Dawkins

Working...