Amazon Flaw Lets Password Variants Through 159
Wired reports that it has confirmed a password flaw affecting some Amazon accounts. If your password hasn't been changed in a while ("the past several years"), it may be less secure than you'd like. As Wired explains, for these older accounts, "[...] if your password is “Password,” Amazon.com will also let you log in with 'PASSWORD,' 'password,' 'passwordpassword,' and 'password1234.'" The article suggests that Amazon's use of the Unix crypt() tool may be at fault. (Hat tip to E. Maureen Foley for pointing this out.)
Re:Uhm... (Score:2, Informative)
[Cthon98] hey, if you type in your pw, it will show as stars
[Cthon98] ********* see!
[AzureDiamond] hunter2
[AzureDiamond] doesnt look like stars to me
[Cthon98] [AzureDiamond] *******
[Cthon98] thats what I see
[AzureDiamond] oh, really?
[Cthon98] Absolutely
[AzureDiamond] you can go hunter2 my hunter2-ing hunter2
[AzureDiamond] haha, does that look funny to you?
[Cthon98] lol, yes. See, when YOU type hunter2, it shows to us as *******
[AzureDiamond] thats neat, I didnt know IRC did that
[Cthon98] yep, no matter how many times you type hunter2, it will show to us as *******
[AzureDiamond] awesome!
[AzureDiamond] wait, how do you know my pw?
[Cthon98] er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
[AzureDiamond] oh, ok.
Re:So, despite knowing it was a problem... (Score:5, Informative)
Can someone get down off their high horse long enough to explain just how this was a poor security practice on Amazon's part?
Read the article... this isn't a huge flaw, just one that reduces the complexity of cracking an existing password.
If someone manages to break into Amazon (or do an inside job), they could theoretically steal a LOT of passwords (mine was impacted prior to changing it just now) by downloading the database and running a simple rainbow table [wikipedia.org] against it.... given that crypt limited the length to 8 and they case-insensitized the passwords, that's quite easy to crack even at 8 characters.
Cracked password means likely 1 or more credit card numbers per account compromised, which is a decent pay-off.
Furthermore there is the security issue of password re-use wherein an Amazon account would give an email address, and the attacker could try the email address of the account with the same password.
Re:Why exactly is this a problem? (Score:5, Informative)
Any time a system will accept multiple entries for one password, the number of guesses an intruder has to make goes down.
This is generally considered bad.
You should never allow bad logins just to make it easier for people to log in when they can't recall their password, that's the wrong way to do it. You should provide an easy way for them to reset their password, not reduce your security across the board (which means password reset mechanisms must be carefully designed as well).
But this is bad for the same reason that simple passwords is bad. If you increase an attacker's chances of getting in by 0.01%, but you have 10,000,000 users, you've now put 1000 more people at risk.
Simply put, you want passwords to be as secure as you can, limited by your users ability to remember their password. And don't cater to the users who haven't logged in in 3 years, cater to the users who log in every day - keep things secure for them.
Just imagine how many people might use their last name as a password, or their last name plus their birthday. Then if you know a user John Smith was born in 1967, you can guess "smith67", and if he uses: smith, Smith, SMITH, smith67, Smith67, or SMITH67, your single guess of smith67 will work for ALL SIX cases. Increasing an attacker's chances SIX fold is terrible.
And for what its worth, I'm blown away that this isn't perfectly clear to every single Slashdot reader.
-Taylor
Re:The UNIX crypt tool is not at fault (Score:3, Informative)
what about users with 8-character passwords who log in right after your proposed change with caps lock accidently down
Unix crypt() is NOT case-insensitive. If the Amazon passwords are case-insensitive due to crypt, then it is due to them converting the field to all lowercase or all uppercase before passing the input to crypt(). They could continue to do so; although, case-insensitive was inadvisable in the first place, they would have painted them into a corner -- however, they can still prompt the user to change their password after a successful login, and make the pw change mandatory.