Let Your Theme Song be Your Password 275
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.. (Score:5, Funny)
"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.. (Score:4, Informative)
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: (Score:2)
Re: (Score:2)
I'm quite sure it does because I'm using it right now, in Firefox 3.0.1. ;-)
Re: (Score:2)
Re:Hmmm.. (Score:4, Informative)
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.. (Score:5, Funny)
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: (Score:3, Funny)
Re:Hmmm.. (Score:5, Funny)
You think that's scarry ?
No, but using one of the Busytown books as a password would be pretty scarry [wikipedia.org].
Re: (Score:2)
How about in the future, musical references are accessible to those of us under 45 as well?
Re: (Score:2)
Hell I don't even know whether "yes" is the band or song name. I just googled for "really long songs".
Re: (Score:2)
Haven't you ever perused through a CD store?
Yes albums are still widely available. They aren't really an obscure band.
Re: (Score:3, Insightful)
I had a similar but reverse experience. Until the age of 15 I never really listened to music. I was a musician, and really enjoyed _playing_ music, but I owned very few CDs or cassettes and the ones I did own I only bought because people told me they were "cool." I wasn't interested in popular music at the time and I didn't know anything else.
Eventually, I rediscovered Jazz and my hunger for music just exploded. I even learned to appreciate some of the popular music that I had dismissed before. Though,
Re: (Score:3, Insightful)
Stupid and Redundant (Score:5, Insightful)
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: (Score:2, Interesting)
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: (Score:3, Insightful)
But no one knows what song out of my thousands I'm using,
Maybe they would look at the access times to see what files you'd opened recently?
Re: (Score:3, Insightful)
Also, last.fm would go from being an entertaining and useful resource to a massive security hole.
(I know you wouldn't play the song every time necessarily, but it would severely limit the number of songs which it could be and give you a pretty good way to weight attempts.)
Re:Stupid and Redundant (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:3, Interesting)
Re:Stupid and Redundant (Score:5, Funny)
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.
Re: (Score:2)
And that is why God invented salts...
Oh wait, sorry, it was Chuck Norris.
Also, you can pick a non-RIAA song, or just use your cell phone recording of your friend KUI (K is for Karaoke) last night.
Re: (Score:2)
http://en.wikipedia.org/wiki/Password_salt [wikipedia.org]
Salt data complicates dictionary attacks that use pre-encryption of dictionary entries: Each bit of salt used doubles the amount of storage and computation required.
Re: (Score:2)
Two things:
1. You'd need to actually have all those mp3s
2. Each mp3 would have to have matching ID3 tags, otherwise the hash will be completely different.
Re: (Score:3, Interesting)
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 he
Re: (Score:2)
That's why I always mount my file systems with 'noatime'!
(Well ok, I do it because I have a flash disk and don't want any unnecessary writes)
Re: (Score:3, Insightful)
Amen!
It's just a keyfile without any of the cryptographic advantages.
Once one site / attacker has the "password", ie the file hash, they all have it. Unlike public key crypto, where you get to keep your private key!
Re: (Score:2)
A 30+ character password containing mixed case and symbols works for me, why can't it work for anyone?
(that was sarcasm btw, though that is my standard criteria for a password, when systems allow something that secure).
Stupid? (Score:4, Interesting)
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: (Score:2, Insightful)
It increases security because it potentially increase the password complexity and render it immune from dictionnary attack.
But using mp3 as a keyfile is, IMHO, dangerous: what if you re-tag your song ? Windows Media Player has a "feature" to update the tags automagicaly...
Re:Stupid? (Score:5, Insightful)
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? (Score:5, Funny)
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? (Score:5, Funny)
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.
Re: (Score:3, Funny)
On the plus side, no one wants to borrow your computer.
Re: (Score:3, Interesting)
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
Re:Stupid? (Score:4, Interesting)
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: (Score:3, Interesting)
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 a
Re: (Score:2)
And I wouldn't use this for websites or whatnot, only to be used with OS logins imho where the attacker doesn't have access to your files if they don't have your USB key
Re: (Score:2)
The idea here that a user should pick one file is absurd, for the security purposes everyone mentioned. But if you made them choose two files then the game becomes a little different. Throw in the ability to pick mixing/hashing algo
Re: (Score:2)
Something like YankeeBravo3293834CharlieVectorFive with the "unprintable" character between the numbers and Charlie.
Amazing, I have the same combination on my luggage.
Re: (Score:2)
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.
That's largely true... But I fail to see how picking a song is really going to help much. Instead of remembering your password is "p@ssw0rd" you now remember that your password is "Head Like a Hole, by Nine Inch Nails" How is that any harder to guess? How is that any harder for someone else to discover? How is that any easier to remember?
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.
If that's the case, why use an MP3 at all? You're basically changing the security from something you know (Head Like a Hole, by Nine Inch Nails) to something you have
Re: (Score:2)
I think the part the GP meant was actually "Happy Days", which is the favourite theme song of the geek in the music video
Re: (Score:3, Insightful)
Re:Stupid? (Score:4, Funny)
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: (Score:2)
Why would anyone want to hack your Slashdot account? Are there people out there just clamouring for the geek credibility of a mid-6-digit UID?
Re: (Score:2)
Okay, the method is actually one I use. But *not* on slashdot, honestly. I'm not going to give real information. Tongue in cheek, though, I was also pointing out another security flaw... you tell people your password, they'll be able to access your account. Publish it on the web, and ... ... anyhow, it happened to have to do with the title of the thread (Re:Stupid?). It was a little joke stuck in what might be otherwise useful comment.
Hopefully, the moderators will rate you and me down through
Re: (Score:2)
I modified it to be "ku5t0mK".
OMG HELP MY MOUSE IS MOVING BY ITSELF!
lame caps filter lame caps filter lame caps filter lame caps filter lame caps filter
Re: (Score:2)
"1234? That sounds like something that some asshole would have on his luggage"
Sorry, I could not resist :)
Re: (Score:3, Informative)
Problem is the complexity you refer to does not exist. Let's say the secure string is 256 chars. That 4-char seed value is constant. It has to be, otherwise it defeats the purpose of the system, as it would act as a password itself requiring input from the user. That would be like a 4 digit ATM pin code. The whole point of the system seems to be that the user only has to remember which file, not a password.
Regardless of the complexity of the secure string, the actual complexity of the system itself is
They should disencourage songs as much as possible (Score:5, Insightful)
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.
Re:They should disencourage songs as much as possi (Score:2)
Well if that is going to be the case, than my kung fu is strong.
Re: (Score:2)
Re: (Score:2)
Surely, I'll be the only one using "Shaft" (Score:2)
Re: (Score:2)
There's just not THAT many mp3's out there.
Done this for a while. (Score:5, Informative)
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. (Score:4, Interesting)
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: (Score:2)
No, I think he has a point. Wouldn't the output of an unsuccessful decryption attempt on encrypted plain text look much the same as the output of a successful decryption attempt on a payload that is itself encrypted? Or does every (popular) encryption scheme identify the output file in some way, thus making it obvious that you have successfully cracked stage one of the decryption process, and should now proceed to brute-force the output to get stage two?
Re:Done this for a while. (Score:4, Informative)
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.
Re:Done this for a while. (Score:4, Interesting)
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.
Goatse password? (Score:3, Funny)
Re:Goatse password? (Score:4, Funny)
Howto create good password thats easy remembered (Score:5, Insightful)
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: (Score:3, Informative)
You might give credit where credit is due:
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-500.pdf [cam.ac.uk]
Re: (Score:2)
Re: (Score:2)
Re:Howto create good password thats easy remembere (Score:5, Insightful)
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.
Re: (Score:2, Informative)
When I teach security and passwords, I recommend the same approach. I ask my students to use a catch phrase they often use on a personal level.
Then, I make them use the first letter of each of the words in that phrase.
Finally, any of the words that be substitute for a number, we do it too.
So, for example: I can't believe this works for that! Would become Icbtw4t now if you are allowed to add a non-alpha-numeric character, go for Icbtw4t@ :)
I doubt a dictionary would have that.
But then again, who knows! :)
Re: (Score:3, Informative)
I suppose by "typical" you mean "old", since typical Unix machines these days use MD5 or better.
Re: (Score:2)
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.
On the other hand, if /etc/shadow is already available to the attacker (i.e. the attacker has gained root privileges), weak user passwords is your least concern.
The same catch as always exist (Score:5, Insightful)
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.
And if you lose the file? (Score:2)
It's an interesting idea, but what happens when you lose the file? Basically you are up the proverbial creek with no way back.
Suggesting you can get the file back off some p2p network is misleading. You have no guarantee that the file is exactly the same as the copy you had. So you are limited to files that you alone have. If you are careless with backups, or unthinkingly resample your MP3 or photo, then say goodbye to your unique hash.
It's all possible, but users of it would really need to get in the
Re: (Score:2)
It's an interesting idea, but what happens when you lose the file? Basically you are up the proverbial creek with no way back.
I don't think that's necessarily a show stopper. All systems have ways of resetting the password. For companies, the corporate helpdesk can set it to a known value and have the user change it at next login. For your linux desktop, just boot up with the S kernel option.
People lose/forget passwords all the time. Helpdesks have dedicated call queues just for that occasion.
Let Your Song be Your Password (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Actually the line was "My voice is my passport." in Sneakers.
Turn in your robe and wizard hat. You have been dismissed from the geek squad.
What a stupid idea (Score:3, Informative)
In practical scenarios, this idea actually reduces key space needed to be searched in comparison to passwords. Why the users clueless enough to not handle passwords properly would handle music-based passwords better?
And you don't have to use your Facebook profile's picture to be obvious. I bet that majority of passwords will be Eminem or Rihanna [mp3.com] MP3 clips downloaded from some p2p networks (most people don't even know how to produce and compress their own sound file); there are also certain songs that are significantly more popular from others. So there will be lots of identical passwords that are easy to guess.
A good password should be as random as possible. This is far from random. You get all sorts of hints from the public information about global music market and the password data is based on publicly available audio data. In addition, if you know your victim, you can even make more correct guesses as to what songs did that person choose.
Re: (Score:3, Insightful)
I think you're right. An attacker would just keep downloading music and video files from torrents to update a database of common hash values and use it for dictionary based attacks.
If one wants to create a really secure hash he should just use a file containing random data. But isn't easier to create a random password instead?
So this proposal looked good but it shouldn't have passed the brainstorming phase.
Re: (Score:2)
A good password should be as random as possible. This is far from random. You get all sorts of hints from the public information about global music market and the password data is based on publicly available audio data. In addition, if you know your victim, you can even make more correct guesses as to what songs did that person choose.
Exactly. All someone would have to do is look at my last.fm profile to get a pretty good idea of the stuff I listen to. Or, barring that, see what CDs I've got lying around my house. Even just paying attention to what radio station somebody typically listens to would give you a pretty good hint.
My theme song? (Score:3, Funny)
Something tells me a significant portion of the people who'll ever use this will pick "White and Nerdy" by Weird Al' as their theme song... which would kind of invalidate the whole system :>
Doesn't work well for geeks (Score:2)
Every one of us would choose William Shatner's, "Lucy In The Sky With Diamonds".
Re: (Score:2)
Yours is the fourth claim of "Every one of us would choose"... ...
Rick Astley -
William Shatner - LSD
Happy Days themesong
Weird Al - White and Nerdy.
Any more obvious songs?
Paraphrasing Sting... (Score:2)
VERY stupid? (Score:2, Informative)
Consider:
1. many people access their bank accounts, their PayPal accounts, etc, using their computer.
2. only static (unchanging) files can be used for passwords. This means no
rickroll (Score:3, Funny)
Really Bad Idea (Score:3, Insightful)
There are so many reasons this is a horrible idea...
Aside from all the normal vulnerabilities to phishing and such, first and foremost, a good authentication system requires 3 things, something you know (a password), something you have (an ident card), and with today's technology, something you are (biometric scan). Since everyone doesn't have an iris scanner on their laptops yet, we typically settle for the first two (though fingerprint scanners on laptops are becoming ubiquitous).
This proposal takes away the something that you know, leaving only the something that you have. It makes it essentially the same as key based authentication for ssh. It's secure, but I don't distribute my laptop's keys for a reason. If it gets stolen, your private key is compromised and you scramble to pick up the pieces. If it was used more frequently, and from multiple physical locations, that increases the likelihood of it being compromised since it's always got to be with you
I'm really fond of some of the two way authentication systems that some banks are using now. My bank is pretty lame, it just shows me a picture with some text that I've selected beforehand. I've read online where other banks will actually send an sms to your cell phone, and you have to enter that SMS to log in. The poor man's RSA token, if you will.
Re: (Score:2)
Isn't that really just something you know and *two* things you have (an ident card and your retinas or fingers)? Someone sufficiently motivated can take them. I've seen it in the movies, so it must be true. :-)
passwords are bad use asymmetric keys (Score:5, Interesting)
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: (Score:3, Interesting)
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
Anybody else think this? (Score:3, Funny)
What was that Jiminy-Cricket??
"Let Your Theme Song be Your Password, and Always Let Your Conscience Be Your Guide"
I already kind of do this... (Score:2)
I use guitar chords, pick a phrase from a song, and make the chord name/fingering the password.
ex: E022100A*02220D**0232
*=a string you don't hit. Use any special char for it.
can be as long as you feel like typing and it's easy to remember (if you play guitar, would work for just about any other instrument I would imagine)
Re: (Score:2)
And now you have an incredibly easy to brute-force password, provided they know what kind of scheme you use.
You want to mix capitalization for sure, and you need to find a way to use more alphabet than just a-g. You definitely want to delimit things with symbols too, just enough variety to make it hard to brute force.
Only one issue I see with this (Score:2, Funny)
Diceware and dictionary words (Score:2)
Even though this method doesn't really create terribly secure passwords, I imagine this is a large step up for most users. If you have 100,000 files in your computer and one was chosen at random (at random meaning NOT by a human being), that makes your password worth about as much as a 16 bit key. This is less than a 3 character randomly generated password.
If you want a strong password jammed into a tiny space (6 to 8 characters), generating one randomly -- from /dev/random or some other reliable source o
Obligatory (Score:2)
Re: (Score:2)
Yes, your posting is somewhat unusual.
Re: (Score:2)
Re: (Score:2, Funny)
image of you doing something unlikely
No need to be coy here, you can just say "sex".
Re: (Score:2)
Did you even read the summary?
This is talking about using a keyfile (example used was an MP3).