Let Your Theme Song be Your Password

An anonymous reader writes "The latest proposed solution to the fact humans suck at using passwords properly is to let people use digital objects, like mp3s, photos or videos instead. A file is hashed into a unique, secure string that acts as the real password. A paper on the idea was put forward in a recent Usenix conference on hot topics in security, and a Firefox extension that implements the idea is available too."

Comments

Stupid?

[EdIII]

Maybe I am just way off here, but it sounds like what they want to do is to create a unique hash ("secure string") from a file on your computer.

Well that would seem to mean that you have to possess the file first. So how does that not reduce password complexity down several orders at minimum? I know I probably have 3 million files at least on my system right now, but that is far less permutations than a 20 character password with "unprintable" characters (above 128 in ascii).

I just don't see how this is not easier to defeat than a strongly created password. Easier for the user, but not an increase in security.

Re:Stupid?

[Swizec]

The problem is people DON'T use secure passwords at all. Not even geeks have the discipline to use good passwords for anything but servers.

The idea with mp3s is, I think, that instead of typing in a password you point to an mp3 on your USB key. Now since practically no two mp3s are exactly the same it'd be very difficult for an attacker to first know what song you used and second to have the exact same (bitwise) version of the song. This is probably as safe as you can get without SSL certificates.

Re:Stupid?

[EdIII]

The problem is people DON'T use secure passwords at all. Not even geeks have the discipline to use good passwords for anything but servers.

I'll certainly agree to that. However, I must be a super geek since ALL of my passwords are a minimum of 20 characters, a mix of lower/upper case, contains numbers as well as letters, and quite often contains characters from the extended ascii keyset (i.e ALT+163). Something like YankeeBravo3293834CharlieVectorFive with the "unprintable" character between the numbers and Charlie. Yeah, I know, maybe a little overboard.

The idea with mp3s is, I think, that instead of typing in a password you point to an mp3 on your USB key.

That will probably never happen since the file is most likely to be "popular" with the user. I would think that would also mean the file resides on the system itself and maybe even on shared network space. I see that as a potential security vulnerability.

If you were going to go so far as to create super secure strings that were to only reside on a USB stick, than why base them on a real file at all? Why not random 50 character strings? Secondly, that would make all USB sticks in that person's possession as good as a key. Unless the USB stick contained multiple secure strings, which would only raise the complexity to be the number of secure strings.

Now if you had a little box that had 10-20 16MB USB Sticks in it, that each contained 30,000 randomly created secure strings with an interface that allowed you to easily navigate and choose from them, THAT WOULD BE SECURE.

Generating the secure string from a file would probably never generate the needed secure string and the attacker would have to choose the right stick and the right file to gain access to the system. That would be overly complex and such systems like that already exist. Similar to Smart Cards combined with biometrics.

I just don't see the real world implementation that would occur with most people providing more security. I see less security more than likely, and to be fair, mostly at the fault of the user.

Re:Stupid?

[Urkki]

If this unique hash were like a MD5 hash than the complexity of the hash is simply the range of characters raised to the power of 32, the length of a MD5 hash. MD5 is hexadecimal I think (off the top of my head here), so that would be 16 unique characters. So a MD5 hash has 16^32 permutations.

Just to clarify, MD5 itself is not "hexadecimal" or anything like that. MD5 sum is a string of 128 bits, not any string of characters (well, unless you call a bit a character). MD5 sum can be and usually is interpreted as a number between 0 and 340282366920938463463374607431768211455, and can be represented in any numeral system. In non-ASCII contexts it usually is in raw binary, and hexadecimal or base64 is often used when using printable characters.

But really, it's a number, and can be represented in any way a number can be represnted, like in Roman numerals... ;-)

Re:Stupid and Redundant

[Anonymous Coward]

But no one knows what song out of my thousands I'm using, and I can remember it easily because it goes doo-dee-dah-dit-da like I like. Sure it's only security through obscurity but it's still an interesting idea.

Re:Done this for a while.

[blueg3]

Encrypting twice with different keys is like encrypting once with a key that's twice as long (assuming your cryptosystem is good). It makes the result "much harder" to brute-force.

But, to be honest, nobody is going to be brute-forcing AES-256 anyway -- the weakness in modern security systems is not that the encryption can be brute-forced, it's everything else in the system.

passwords are bad use asymmetric keys

[SaberTaylor]

The solution to authentication is something like the IronKey (a hardened USB drive for storing passwords) but with asymmetric crypto.

So you would go to Gmail, gmail would send a challenge that goes to the browser. A library on your browser would send the challenge to the USB device. The USB device would respond by signing the challenge asymmetrically, and that signature would route back through the browser to Gmail. Then you have 1 authenticated session until you destroy it. For sake of convenience imagine the implementation as using PGP -- public key, private key. Gmail has the public key, your USB device has the private key.

This is great since you could read your webmail on a friend's computer, or post Slashdot comments without leaving behind a persistent authentication token (barring a fake logout screen). Or there could be a keylogger on your home computer but it wouldn't be able to scrape persistent passwords and pass those on.

The only reason that humans don't use asymmetric security is that we're too stupid. Otherwise if we wanted high security we would be looking at screens of cyphertext and reversing the one-way function (a^b=c) in our heads. Given that we're too dumb, why not do not put our authenticator on a device that goes on a keychain with our other keys? (And you could make a backup just like with your other keys.)

I can't wait until /. posts the next stupid idea for replacing passwords (my favorite ice cream is LBtHrbjCi) so that I can copy-paste this comment again until I get early enough for +5.

Re:passwords are bad use asymmetric keys

[JesseMcDonald]

The solution to authentication is something like the IronKey (a hardened USB drive for storing passwords) but with asymmetric crypto.

That's a good start, but there are still a couple of holes to work around. For example, you can't trust the local terminal; in your example it isn't even your system, and even if it was it may be compromised in some way. The authenticated session allows the computer, not just the user, to e.g. send mail, or change settings, or access any mail in the account (not just the ones explicitly downloaded).

The e-Gold web site had a similar problem -- people would log in from compromised computers, and malware would piggyback on their authenticated sessions to transfer money out of their accounts. The means of authentication were irrelevant, and the same attack would work in principle on any online banking site.

With Gmail these issues are probably acceptable, but for sessions requiring more security -- e.g. financial transactions -- you need to authorize each individual transaction, and you also need a way to see what it is you're signing. The simplest way to do that, without relying on a potentially compromised host, is to include a small bitmap display in the key device itself. When you accept the transaction -- indicated through a button on the device -- the contents of the display are included in the signature. The bitmap would include the critical information from the transaction (e.g. the total and destination account), making it easy to prove after the fact exactly what you agreed to. Since you have to interact with the device, Bluetooth would probably be preferable to USB. Acceptance may be indicated by a PIN or biometric scanner rather than a simple button if desired.

Re:Stupid and Redundant

[Lachlan Hunt]

Sure, and it would also depend on which hashing algorithm the user used on their system to generate the password. This is not the first time something like this has been used, I've heard of various password generators hashing all sorts of things.

But I think this could be potentially confusing for some users. Consider the following scenario:

Alice uses her favourite Britney Spears song from her collection to generate her password. Alice goes to over to Bob's place and wants to use his computer to log into her account. Alice thinks that because Bob is an even bigger fan of Britney than she is, and because he also has a copy of the same song, that she can do it easily. Alice selects "Oops, I Did it Again" from Bob's collection and tries to log in. This time, it fails because the song is encoded differently. But unable to understand why, she tries again a couple more times, and ends up getting locked out of her account for too many failed attempts.

Now, not only is she totally confused by why it hasn't worked, she loses faith in the whole system and goes back to using her old password: "br1tney".

Re:Done this for a while.

[JesseMcDonald]

I'm not a cryptographer, but I think the GP has a point, provided that the attacker doesn't know that there are two keys. Assume the brute-force process is something like: for every possible AES-256 key, try to decrypt the file; if the file appears to be a meaningful plaintext, we have the decryption key. If the file was encrypted twice (without any header or other identifying characteristics) then the "plaintext" will appear just as random as decryption with the wrong key. There should be no way for the attacker to know whether the key has been found or not.

If they know about the scheme, of course, then it's just as you said: the key length is effectively doubled, since one has to try every possible pair of keys per test.

Re:Stupid and Redundant

[VagaStorm]

Um... what happens if I change the id3 tag for my song? I will never be able to access anything ever agen? Thanx, but I think I'll pass :p