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

Hmmm..

The latest RIAA claim...

"Your honor, the defendant has a musical password which was not authorized by us! By using it on more than one computer, he has distributed it illegally. We demand $700,000 in damages."

Re:Hmmm..

On a similar note: This futz about "the password problem" is getting really, really old.

Firefox Password Hasher [mozilla.org] exists.
And for everything else you can just drop a similar program onto your cellphone, PDA or whatever gadget you carry around with you.
Yes, it's not "perfect" security but it's probably the best tradeoff between convenience and security that we'll see in a long while. It won't get much better as long as human brains are involved.

Re:Hmmm..

Ah I see what you mean, mozilla is behind the times again.
The Firefox3 compatible version can be installed from the Password Hasher Homepage [wijjo.com].

Re:Hmmm..

You think that's scarry ?

Imagine being the idiot that used their full 20:23 length digitally remastered copy of "Yes, The Revealing Science of God", who's on dialup, and has to enter their password in order to change it.

Re:Hmmm..

You think that's scarry ?

No, but using one of the Busytown books as a password would be pretty scarry [wikipedia.org].

Stupid and Redundant

If you can use an MP3 as a "password" you may as well just go the whole nine yards and use a damn key file.
This is stupid and redundant.

Re:Stupid and Redundant

Who needs last.fm? A dictionary attack involving every song released by the RIAA in the last decade would run into (at a wild guess) a few million. Hashing those into a dictionary would take a few days or perhaps weeks, and once done, would not have to be done again. My bet would be on about a month before the first distributions of song hash tables by a bunch of bored kids who know how to use md5sum and bash scripting.

So dictionary attacks with a few million possibilities? This "security" development is worse than the use of real, un-obfuscated dictionary words.

Re:Stupid and Redundant

Except that you'd have to do that for all realistic bitrates and encoders, values of the id3 tags, etc - basically anything that would alter the hash of the file. I wouldn't be too concerned about that.

What I would be concerned about however would be targeted attacks, with malware being distributed that scans the PC for suitable media files, produces the hashes, and sends them home along with some identifier for the user...

Re:Stupid and Redundant

Who needs last.fm? A dictionary attack involving every song released by the RIAA in the last decade would run into (at a wild guess) a few million. Hashing those into a dictionary would take a few days or perhaps weeks, and once done, would not have to be done again. My bet would be on about a month before the first distributions of song hash tables by a bunch of bored kids who know how to use md5sum and bash scripting.

So dictionary attacks with a few million possibilities? This "security" development is worse than the use of real, un-obfuscated dictionary words.

A few MILLION???? Havent you heard all the music lately, it all sounds the same... take a hash of one Britney Spears song and you just got them all... and NO, I will _not_ leave Britney alone.

Stupid?

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?

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?

Much more secure, and easier, is just to remember a few words from the theme song, and craft them into a password, substituting numbers as appropriate. There are many more variants this way, and you don't have to modify the password programs.

Then you work through the song, verse by verse.

As an example, I change my Slashdot password once a month to keep it secure. I'm in the middle of "Money ain't for nuthin", and my current password is based on "Custom Kitchens": two days ago, I modified it to be "ku5t0mK". In about another three weeks, I'll modify it to something based on "refrigerators". Each time I update my password, I have no problem remembering it; and there's almost zero chance that anyone will hack my Slashdot account.

Re:Stupid?

It increases security because it potentially increase the password complexity and render it immune from dictionnary attack.

It actually does neither. Where you are mistaken is thinking the complexity lies with the created "secure string". It does not. 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.

The problem however, is that the complexity of this new password IS NOT 16^32, or whatever the permutations of the "secure string" really is. It's complexity is the number of unique files on your computer. Create a "secure string" from every file on the system and you now have your dictionary that you referred to. The difference between this dictionary and a traditional dictionary attack is that there is a GUARANTEE that at least ONE of the entries in the dictionary is the right one.

Your observation about the tags though, is spot-on. Any changes to that file at all will render it useless as a password.

Re:Stupid?

I have a fingerprint scanner on my computer which uses libpam-thinkfinger (IIRC) to log me into my desktop session. You'd think the complexity was all the possible permutations of the lines and ridges on my finger, but really, it's just 1 in 10.

Well, it used to be 1 in 11, but I had that fixed. :-)

Re:Stupid?

Really? I used to use the tip of my penis, but MAN you should have heard the other people in the building COMPLAIN. Bitch, Bitch, Bitch.

They should disencourage songs as much as possible

There's no cure for user stupidity, so if users are encouraged to use songs as passwords there'll be lots of users that'll use their favorite song as their password even though they downloaded it from iTunes or an specific pirate group (i.e. lots of people can have the exact the same song with the exact same encoding) and announce to the world what is their favorite song in the social networking profile.

Instead, users should be encouraged to record whatever rubbish with their microphones and use it instead. Stuff like ambient noise and voice tone would make such signature unique even if the user puts very little effort in it. Heck, it could be a record of a fart.

Done this for a while.

TrueCrypt had an option like this. The best thing, in my opinion is to use a password and files. (Yes, multiple files).

My favourite system was to set up a TrueCrypt volume with a hidden volume. You have two passwords, and a set of files on a CD. The normal volume is opened with a password and all the files on the CD. The hidden is with the passoword and a selection of the files (I called them 0-9 so it ended as a 'pin' of sorts).

This means two things to know, and one to have, plus plausible deniablity, which isn't bad.

Re:Done this for a while.

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.

Re:Done this for a while.

Even if the software you use has a "tag" that would let you check the validity of the outer-layer decryption, such a thing isn't theoretically required.

The problem is that you don't need to do one layer at a time in brute-forcing. If you encrypt with two keys, A and then B, what I do to brute force is try every possible pair of keys and check the validity of the resulting decrypted text. Now if my choice for key B is wrong, key A is decrypting garbage to garbage, but that's fine.

Now, if keys A and B are each 128 bits, then I have to try every possible pair of two 128-bit keys. There are 2^128 choices for a single 128-bit key, and there are 2^128 * 2^128 possible two-key pairs. 2^128*2^128=2^256, which is the number of different 256-bit keys. Two 128-bit keys equals one 256-bit key.

This is, incidentally, exactly what TripleDES does.

Goatse password?

Hmm, I wouldn't want to be the sysadmin to recover a lost goatse "password picture"!

Re:Goatse password?

You would have no problems with me cause I would never gonna give up my password and never let it down for you to see...

Howto create good password thats easy remembered

Think about one of your favourite songs, poems (e.g. "Hey Jude" by The Beatles)
Now take the first letters of the refrain or the first verse (e.g. "Hey Jude, don't make it bad") and you get "HJdmib"
If you like, translate it a little bit into "l33t speak": HJdm1b
And you have a great password that you can remember easily.

EDUCATE your users!

Re:Howto create good password thats easy remembere

Though really, why not use "H3y Jud3, d0n't m4k3 11 b4d"? It has almost all of that, plus a good length.

Because the user doesn't control the hashing algorithm used for passwords. If you do that on a typical Unix box with good old DES crypt, the hash is only on the first eight characters, and your password is no different from "H3y Jud3". And "H3y Jud3" is easily found using a dictionary attack -- in fact, john the ripper's out-of-the-box rules has "l/ese3[:c]" as one of the single crack rules, and "Hey Jude" is most definitely in cracker lists which tend to include all popular movies and songs.

Contrary to popular belief, substituting letters with numbers in 31337 speech doesn't do much to improve password security. It takes slightly longer to crack, but not enough so that you should feel much safer.

The same catch as always exist

All security needs some way to identify a person to a computer, which should be as hard as possible to fake. Biometrics rely on unique (but not unfakeable) biological traits of a person, passwords rely on knowledge which hopefully nobody else has - they however rely on custom hardware to get this biological data (e.g. fingerprint scanners) - which makes them wholly unsuitable for the web.

One possible replacement for passwords is security keys, which now relies on not letting anybody else get access to a certain file. The fact that those, by themselves, are not secure enough (as getting a file once now opens up the whole world it's used on) is why most key-based authentication systems allow you to protect the key itself with a passphrase. It can still be more secure as you can prevent the servers from accepting passwords so they cannot be so easily brute-forced but if somebody gets the keyfile, bruteforcing the passphrase is perhaps even EASIER as he can do it on his own machine where it cannot be logged by the target.

Replacing the key with a picture or a sound file won't help much - unless you can protect access to the file... which leaves you right back where you started. Even if you just send a hash based on it (so it cannot be ripped from a server) anybody who gets the file (and knows what file to get) has all your access.
And now... there isn't even a pass phrase to protect it.

The fundamental problem of all security remains - the identifying information needs to be limited to a single person. Whether that is something in his head you try to stop others from guessing or brute-forcing, or something about his body or a file on his computer - there is still no real way to make sure it cannot be faked.

You could come up with a billion variations on the theme. KDE has the option to lock the screen if a bluetooth device is out of range, and unlock it if it comes back into range (I'm sure other desktops/OS's have similar tools) - now you rely on an object (like a cellphone) being owned by a certain user and hard to get without that person noticing - but you're back to why we don't use fingerprint scans to log onto websites. Users need trusted hardware for it to work (trusted by the service provider I mean) - the only way to prevent any old scanner with a picture of somebody's thumb (and who has never taken one of those by accident ?) - that are not common and are expensive. Even if you could make it trusted, when you cannot see the user, you cannot be sure his hardware isn't compromised. Even if you lock the hardware with a secret key (DRM style) you still cannot prevent it being fooled with a picture of somebody's thumb (and who hasn't taken a few of those by accident over the years ?)

Ultimately, we won't really have better security until we crack the problem of identifying a person who is somewhere else. Even the most draconian approaches won't work, if you require a webcam stream of the person - that won't be impossible to fake either, in fact since nobody could monitor all of them, all of the time, moving the cam or sending back a recording will be ridiculously easy.

In short this is just another attempt to come up with a better kind of keyfile - and frankly, it's not even as good as the ones we have - and nobody has really grokked a better way to solve the identity of a distant person problem yet.

passwords are bad use asymmetric keys

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.