Password Resets Worse Than Reusing Old password 420
narramissic writes "We all know well the perils of password reuse. But what about the information used to reset passwords? Many sites use a standard set of questions — your mother's maiden name, the name of your best friend, what city you grew up in, or what brand your first car was. And you probably have a standard set of responses, making them easy to remember but not very secure. 'The city you grew up in and your mother's maiden name can be derived from public records. Facebook might unwittingly tell the name of your best friend. And, until quite recently, Ford with its 25% market share had a pretty good chance of being the brand of your first car,' says security researcher Markus Jakobsson. But 'password reset does not have to be a weak link,' says Jakobsson. 'Psychologists know that people's preferences are stable — often more so than long term memory. And very few preferences are recorded in public databases.'"
No duh (Score:1, Informative)
No duh. Who in their right mind thought having simple secret questions, to reset passwords, as a good idea? Especially when MySpace and the like contain a bunch of information people willingly put up online.
Birthdates aren't secure for password resets since people aren't afraid of letting others know when their birthday is. Like, "Hey, it's my 21st birthday today!" on their social networking blog.
Zip codes aren't secure for password resets either. It's not too hard to find out where someone lives, with a bit of investigating.
Secret question answers might be listed on one's social networking profile.
Re:I NEVER use these fields (Score:3, Informative)
How do you keep track of all the different passwords of all the different websites which you sign into?
Use keypass [keepass.info] or another key storage system.
Now, if it had an automagical firefox plugin that would let me create a strong password for a site and store it in my key database, that would rock.
American Express... (Score:5, Informative)
Yeah, that's what I want to use for a card with no spending limit, a datum easily discovered through public records.
I finally got hold of a real person, and he insisted I use my mother's birthday. I insisted that I would not. He finally had to get permission from a supervisor for me to use a random four digit string.
I understand, insisting on an easily remembered string probably reduces the number of support calls to reset pins, but at what cost?
Lie (Score:5, Informative)
> The city you grew up in and your mother's maiden name can be derived from public records.
I grew up in Wei9Iequ. My mother's maiden name was ga4EeliY.
Or, if you insist on something easier to remember, make it Tanelorn and Gloriana.
Alastair Rankine posted an excellent analysis (Score:4, Informative)
Yes, my preferences are stable (Score:2, Informative)
And they're set to disable scripting.
The company's statement and original article (Score:2, Informative)
http://www.ravenwhite.com/iforgotmypassword.html [ravenwhite.com]
hashapass.com (Score:3, Informative)
Roll Your Own Questions (Score:2, Informative)
It really helps if you're not being a 'clever' smartass-- references to the cultural canon like 'What is the Answer to Life, the Universe, and Everything' or 'To Be, or Not to Be' are going to be guessed by a passing hacker faster than 'Who was the last person to sleep with my mom?' (Answer: me).
password resets aren't the problem (Score:1, Informative)
What a stupid summary. There's absolutely nothing wrong with password resetting. The problem is password security questions or password "hints" or whatever they're called. Whenever I encounter those, I pound on my keyboard until the text field's maximum length is reached, hoping that's sufficiently random and long enough to thwart any brute force or crib-based attacks. It's so bad sometimes that not only do sites require you enter this information, but they also have ridiculously asinine limits on maximum password length and question/answer length. It doesn't matter whether you choose a strong password, if that can be broken by something as insanely weak as an honest answer to one of the 'security questions' that you're provided with on most sites (though some sites let you specify a custom question). Whoever thought up that one was not the brightest crayon in the box, and has no business doing anything with security applications. They may have had the best of intentions, but took a lot of the ideas they've heard from the security field and applied them poorly, which is why you only let EXPERTS design security applications. This is a lot of theater and nothing more, and poor implementation is the classic amateur mistake.
These are the same people who put plain-text passwords in a database or text file and let you "retrieve" your password which they've conveniently stored, unaltered. Sometimes, if they want to feel really clever about themselves, they might upgrade to un-salted MD5. Yay. There needs to be an industry standard system for web applications, or whatever else, designed by someone who knows what they're doing. Don't roll your own security suite. You're most likely not smart enough, even if you think you are. I use Solar Designer's phpass [openwall.com] for cryptographic hashing in my web applications, and he has several other good pieces of software that are relevant to the topic.
The process I use for password resets goes like this (starting from the very beginning):
1. user goes to the registration page for my website
2. the user is given guidelines on password strength, but these aren't enforced, because it's their own ass if their account gets compromised (though, if there were any risk to said compromisation, then I would impose strengthening measures)
3. the user provides an e-mail address which must be legitimate (I'm not too keen on this myself, since it's none of my business what anyone's e-mail is, and sites requiring e-mail for registration are annoying, but, if you want any semblance of security, this is probably the way to go)
4. in the back end, the user's plain-text password is converted to salted MD5 or bcrypt (bcrypt for Linux [openwall.com]; bcrypt is native to OpenBSD and Openwall Linux) through UNIX crypt()
5. the account is not activated until the user visits a link sent to their inbox, based on a cryptographically secure random confirmation ID (20 bits SHA1)
6. the user forgets his password
7. the user visits the password reset page on my website, inputs their e-mail, and clicks reset
8. a confirmation e-mail is sent to the address on file, complete with a link to a web page on my site with a secure cryptographically generated IP as a GET variable (20 bits SHA1); no password is generated until the link is clicked (or typed in, which I would prefer to clicking, and I don't render e-mail in HTML anyway)
9. once the link is visited, an alternate password is creating using a secure, properly designed and developed cryptographically strong password generation library
10. upon logging in with the new, cryptographically strong password, the old password is deactivated and can no longer be used for logging in
That system is not infallible, but it doesn't require weakening the concept of a password-based system (when such a system is already, inherently, an absurdly flawed and very primitive idea).