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.)
The UNIX crypt tool is not at fault (Score:4, Insightful)
It's the cheap ass developers fault.
Re: (Score:2)
It's the cheap ass developers fault.
And it continues to be their fault. They can fix this easily.
Whenever a user logs in... check if their password is stored using crypt(). If it IS, then take the password they just used to login, and compute a stronger blowfish/salted md5 hash. Replace the crypted password with the strong hash.
No reason they couldn't have done that when they first introduced stronger password hashing.
Re: (Score:3, Interesting)
But if the problem with the system is that mixed-case and extra characters are allowed in the case of older passwords, what about users with 8-character passwords who log in right after your proposed change with caps lock accidently down? Or accidently hit another character-generating key while fumbling for the enter key?
They'll be logged in. But not next time, because their password is not what they think it is. And even if they'd been entering it w
Re: (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 us
Re: (Score:1)
Re: (Score:2)
No - this is a basic testcase for any login scenario - the person who is at fault is the tester
Re: (Score:2)
And the person that did write the specification of how it should be done.
Assuming that there are specifications.
Re: (Score:3)
They might also be using single-DES. http://en.wikipedia.org/wiki/Crypt_(Unix)#Traditional_DES-based_scheme [wikipedia.org]
Re: (Score:2)
What's more likely is that they were running a very old system, and have passwords from those times still in the database; these are usually upgraded when the user logs in again, but some people never logged in again.
Re: (Score:2)
If they have stored truncated case insensitive passwords or hashes, how do they know what users' correct passwords are? Should they reset users' passwords to the first password they type that matches the hash? No, because then a typo (accidental case mismatch or extra/missing/wrong characters
Re: (Score:2)
I remember that crypt used to only care about the first 8 characters, but I don't remember anything about it being case insensitive... Where did that come from?
Uhm... (Score:5, Funny)
Is it supposed to show all of my passwords in the article? Or do you just see stars?
Re: (Score:1)
we just see star. The same thing with credit card numbers and SSN. go on, give it a try.
Oh, important tip: it will only put stars there if the number is preceded with the security number on the back.
Re: (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
Re:Uhm... (Score:4, Funny)
I see Hunter2
Re: (Score:2)
Re: (Score:2)
What's this thread about I only see *-s?
Re: (Score:2)
http://bash.org/?244321 [bash.org]
While you're there, check out the top few hundred quotes. You will laugh, you will cry.
Re: (Score:2)
Well I'll be damned.... (Score:5, Insightful)
Just went to Amazon, typed in my passwords using all caps, and sure enough it logged me right in. I "changed" my password to the same thing it already was, and now the issue is fixed.
Re:Well I'll be damned.... (Score:4, Insightful)
Re:Well I'll be damned.... (Score:4, Insightful)
Or at the very least, update to a semi-modern hash on the next login, when the unhashed version will be known. Since they, like most web pages, don't use a challenge-response scheme but transmit the password as-is (at least over SSL, unlike Facebook's default), this is a trivial thing to do.
Forcing a password change would bring some security, but they're too afraid to spook mrs May type users for that.
Re: (Score:1)
You don't know the unhashed version for sure. What if there was a difference in capitalization, or a stray character appended to the end of a password?
On first login you generate the strong hash and store it in an auxillary database field.
You store both the strong hash and the weak crypt() hash side by side; and on the second login you replace the old crypt() hash. Alternatively... you prompt them to enter a new password twice on the first login (which can be the same or different from the old one).
Re: (Score:2)
Re: (Score:2)
This. There are still a lot of UNIX boxes out which are still using crypt(3), so they are using 8 characters max. There are only two fixes that can be done on this:
1: Force a password change to 8+ characters.
2: Ask a challenge question, such as an address stored on the account, or credit card used.
Re: (Score:2)
Ditto. But on the plus side, it did give me a reason to change my password to something much stronger than it used to be.
Re: (Score:1)
Ditto. But on the plus side, it did give me a reason to change my password to something much stronger than it used to be.
Agreed. Did so here too.
Re: (Score:2)
Be damned. Same here. Exactly.
Re: (Score:2)
This is the solution Amazon will give you if you contact them about it. (The reasons this situation arose are, of course, historical. It's the sort of thing that can happen if you want to improve the way you store passwords, but don't want to prevent existing customers from logging in.)
This issue only affects people who have not changed their account password for something like five years.
Re: (Score:2)
When Microsoft did essentially the same thing [wikipedia.org] it was touted (and is still being touted) as being an example of why Microsoft doesn't get security.... Somehow it was inexcusable to make this mistake in 1987 (when the LM hash was invented) but it's "ok" to do it in 2011?
Just sayin'
Re: (Score:2)
I didn't say it's ok to do ;) Besides, they fixed it. If you reset your password, the issue goes away. I don't really see what more you want.
Re: (Score:2)
I'm not commenting on Amazon's actions - they need to do more (proactively warning customers with really old passwords would be a good start) but it's good that the fix is easy.
I was making a comment about the double standard implicit in the thread - there are a lot of "it's ok that Amazon screwed up here because it's easy to make such a mistake" attitude. On the other hand, 20+ years ago MSFT made essentially the same mistake (and fixed it 15+ years ago) and it's still being used as an example of why "Mic
Re: (Score:2)
MS still don't get it, google for "pass the hash"... It doesn't matter how strong your password or encryption is if you can authenticate using the hash.
Re: (Score:2)
Pass the hash - you mean the attack technique that Microsoft fixed in Windows 2000 with the addition of Kerberos? You're right that Microsoft didn't stop using the weak NTLM hashes until Windows Vista, but it's not like Microsoft hasn't offered a solution for over 10 years.
If you want to pick on Microsoft for stupid security decisions, instead of pass the hash, why not pick on credential reflection [technet.com] attacks. They're a much better example of Microsoft being clueless (or more accurately, people who depende
Re: (Score:2)
They still use NTLM, that is their strongest hash type... Lanman is the even weaker one that was disabled by default in vista.
Kerberos is only used in an active directory setup, and only seems to be used when a user logs in on a workstation to initially authenticate to the domain, it still seems to use ntlm for virtually everything else and i've never seen it configured differently.
Re: (Score:2)
Pass the hash is only relevant in single sign-on environments (because the hash is password equivilant). For Microsoft that means domain joined, and if you're domain joined you use Kerberos (unless you have legacy NT4 machines on your network, in which case you have bigger issues than pass-the-hash attacks).
In non domain environments, each machine has its own account database. Since the pass-the-hash attacks all appear to require that you have full access to the account database, all you're doing is gettin
Re: (Score:2)
Then how do you configure systems which are part of a domain to only support kerberos? I've _NEVER_ seen a setup where hash passing didn't work..
Also in 99% of cases, if you take the local hash from one workstation it works on all the others (built from the same image) anyway, tho this is admittedly due to poor configuration.
There really is no excuse for a hash to be usable as a password equivalent under any circumstances, this completely defeats the point of storing it hashed in the first place.
Re: (Score:2)
Your question stumped me, so I asked the experts. It turns out that it *is* possible to disable NTLM in Windows 7/Server 2008 R2 with the "Restrict NTLM [microsoft.com]" option. But my expert pointed out that enabling this option isn't sufficient to fix pass-the-hash attacks. It turns out that pass-the-hash attacks (or rather pass-the-tgt attacks) also can work against Kerberos [infoworld.com], it's just that there aren't any tools available to mount them. But the attack works.
Digging in deeper, the only reason Windows is considered v
Re: (Score:2)
Re: (Score:2)
Yeah, I'm not sure how I can try that if my password is 12345678 I mean, I can't make it go caps...
Re: (Score:2)
Just tried it, and they're right (Score:2)
My password was generated using the built-in OS X password tool, so I don't have my Amazon password memorized. I looked it up in the Keychain, then changed all the lower-case letters to upper-case - Amazon let me log in.
Guess I'd better change my password!
Not concerned at all. (Score:1)
Luckily I am not affected. My password is 'p31men$!' and so even if there are capital variants, the use of numbers and symbols makes it very hard to crack. I am completely safe.
Re: (Score:2)
So, despite knowing it was a problem... (Score:1)
Re: (Score:3)
I have an account and I don't care. Seriously the threat here is only in the most technical case. IN practicality it's not really a big deal.
I don't think they should care about case anyways.
Re: (Score:2)
The practice of stupid security questions is far worse, and seems to be about as common if not more.
Those reduce the security for "normal" users more than passwords being case insensitive and truncated to 8 characters.
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: (Score:2)
Cracked password means likely 1 or more credit card numbers per account compromised, which is a decent pay-off.
I don't see how a hacked account leads to a compromised credit card number. My full credit card number is not visible to me on Amazon, and if I try to ship an order to a new address, it asks for CC number again (or maybe just the card verification code).
So the worst that could happen would be that someone would order 100 copies of Sarah Palin's book and have them shipped to my home address.
Re: (Score:2)
When what you usually order is 100 vibrating butt plugs?
Amazon sells the vibrating ones?! Wish I'd know that before my last order!
Re: (Score:2)
Mod parent up - grabbing the whole encrypted password list is often surprisingly easy with SQL injection attacks, unfortunately. This is also how some spammers get email addresses from any site that records them and has a suitable SQL injection vulnerability.
Re: (Score:2)
A rainbow table wouldn't be feasible against crypt() because the passwords are salted... Rainbow tables are typically used against hashes which do not use salts, like plain md5 (commonly used in webapps, modern unixes can use bsd-md5 which is salted), lanman/ntlm (as used by windows, lanman is deprecated) etc..
Thankfully... (Score:5, Funny)
My password of hunter2 was not compromised.
Re: (Score:2)
Hey that's my password, you insensitive clod!
Re:Thankfully... (Score:4, Funny)
What?
Why exactly is this a problem? (Score:5, Insightful)
Sure, it would make a dictionary attack easier, but it's not as if you can launch a dictionary attack against amazon.com without being shut down after the first n wrong guesses.
It strikes me as a clever way to save the inevitable calls/emails to tech support ("Uh, I haven't logged in for like, 3 years, and now I can't remember my password.")
What's the threat, exactly?
Re: (Score:2)
I discovered this years ago. I assumed it was deliberate to make logging in on phones easier...
And I agree, I can't really see a situation where this matters.
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:Why exactly is this a problem? (Score:5, Funny)
Just this morning my wife said she had gone to the bank to open an account for our son and they told her this bank has accounts for five people with the same name. We thought his name was less common than that. I asked her why she thought that was a big deal and she said "you know, when you use your name as your password" and I said what?.
Re: (Score:1)
What do you mean, is it common for people to know your name?
- Rumplestiltskin
Re: (Score:2)
Just this morning my wife said she had gone to the bank to open an account for our son and they told her this bank has accounts for five people with the same name. We thought his name was less common than that. I asked her why she thought that was a big deal and she said "you know, when you use your name as your password" and I said what?.
Well at least your wife is not known under five names.
Re: (Score:2)
Statistics does not work that way. As long as we're making up numbers, I'll guess that 0.0001% of those 1000 users will ever have a "guess the password" attack launched against their account.
This is an easy trap to fall into, admittedly. It usually comes up in pharmaceutical trials, where if you actually r
Re: (Score:1)
I get your point, but you're exaggerating.
Let's say the attacker could access 100% of accounts, If he can now access 100.01% of accounts, you've put 1000 more accounts at risk. Except those accounts don't exist. That's pretty preposterous, so try the math with 50% of accounts. Pretty sure it comes to less than 1000 people.
Also Smith will not be the same as Smith67. Smithers would have been a better example. As per the article it's only after 8 characters that the passwords truncate
Re: (Score:2)
Yea, system compromises can and do happen, and a weak password hash is going to cause trouble in case of such a compromise.
5f4dcc3b5aa765d61d8327deb882cf99 (Score:4, Funny)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Don't you know that md5 isn't safe? You should use sha256 instead:
Bah, amateurs! ROT13 is the most secure! (This is a joke of course. I'm stating this because I just know someone is going to take this post seriously, lol.)
Re: (Score:2)
Sha256 is sissy. They have sha512 now.
Re: (Score:2)
it is like this for other sites too... (Score:1)
same with wellsfargo.com and its been like that for ages.
Re: (Score:2)
Wow, I cannot believe that a bank would allow such lax passwords. I have a password with almost equal number of small caps and capital caps characters (typing it involves a lot of 'shift' key press and release). I guess I must have been a moron for creating a complicated password and remembering it!
hat tip? (Score:3)
Am I too old for knowing immediately what the root cause for this was?
Shouldn't this even be considered basic knowledge for any advanced UNIX user?
That was refreshing. Now get off my lawn.
Re: (Score:2)
It should be considered basic knowledge for any UNIX programmer.
It's pretty inexcusable.
Re: (Score:3)
> Am I too old for knowing immediately what the root cause for this was?
Yes.
(Me too.)
Re: (Score:1)
Shouldn't this even be considered basic knowledge for any advanced UNIX user?
Let's assume for the moment that I'm not - what is the flaw involved?
Re: (Score:2)
No, I'm pretty sure it was going through everyone's head. Something like, "What, are they using crypt()?!" followed by, "wait.. they actually are using crypt()? wtf?"
It's much worse than that (Score:5, Interesting)
Re: (Score:2)
I think that was covered by the admission that Unix "crypt" was used. Unless it's just us old fogeys that remember that Unix passwords had an 8 character limit.
Man, I feel old. I'm going to go home and yell at the kids playing in my yard.
Thanks. (Score:2)
Thanks for pointing that out. Based on the summary I would have ignored this issue as my password is strong enough even without case sensitivity.
Re: (Score:3)
Re: (Score:1)
Uh oh. (Score:2)
My amazon.com password is a dictionary word I set in, like, 1997?
Maybe it's time to change it.
passwordpassword (Score:4, Funny)
I hear the site also accepts minor misspellings, anagrams, close synonyms and Cockney rhyming slang.
Password hashes are one-way (Score:4)
A password hash is a one-way function, which means that it is impossible to re-encode passwords stored using one hash using another hash. This means that the old password hash function must still be supported until all passwords are changed.
Re: (Score:2)
As someone else points out, though, it is trivial to create a new hash for a password on the next successful login. To the extent that this should be an issue at all, it should only be affecting people who haven't logged in in the past several years, not all those who haven't changed their password.
Re: (Score:2)
Amazon receives a new copy of my password every time I log in. It's over SSL but unhashed.
Re: (Score:2)
But what if the user mistyped their password that login? Then the next time they try to log in they might not be able to, then they might give up and go away and not place an order.
Briefly store the user-supplied until the authentication using the old method is successful, then use it to generate the new hashed password.
Re: (Score:2)
Er...that was supposed to be quoting the AC's text on the first line, but I borked it. Sorry.
Re: (Score:2)
The problem is that the old method is too lenient, and could accept the "wrong" password. For example suppose the user logged in with caps lock on, and didn't realize it because it was successful (compared using the old hashing algorithm). The new hash would be generated using all caps, then when the user tried to log in latter with caps lock off, it would fail even though he was using the same password as always. You would need to run both systems in parallel for some time and only eliminate the old hash
Entropy loss: 5bit (Score:2)
I dont care if you can append sth to a password. Mathematically accepting some additional input to a password is not bad - you can also type additional text.
The only loss in entropy is that you dont have to guess where the user cut of something from known words. The worst case scenario would be if you make a dictionary attack, and the password is in the dictionary in a longer form you dont have to send the right length. assuming that the chosen pw must be longer than 8 characters and probably is shorter th
Re: (Score:2)
Not enough that it matters anyway...
Unix crypt (Score:2)
The old unix crypt function (using DES encryption) has always been case sensitive, although it is limited to 8 characters... If the password is case insensitive that sounds more like LANMAN, an old password hashing function used by older versions of windows (still enabled by default in 2003 and earlier).
Password change page not secure? (Score:2)
In any case, the captcha image has been "loading" for about 5 minutes now - guess everyone's trying to change their passwords?
eBay has this problem too (Score:1)
Charles Schwab has the same issue (Score:2)
I just recalled that Charles Schwab (a US stockbroker company) has an 8-character password limit.
Guess what? They're also affected by the same issue.
Crap.
Re: (Score:2)
Yeah a couple of years ago an accountant where I work was helping me deal with a purchasing system we have. He asked me for my password so he could log on to my account. Apparently thats how things are done in his working environment. In my team we all have root access so we can su to any account, but nobody shares their password. su only gets you in the account once. root could be changed tomorrow. The same password could be used all over the place.
Re: (Score:1)
Re: (Score:2)
I just checked. Still happens there. I invest with Schwab, so this is a big deal to me.
I changed my Amazon password (hooray for 32-character random strings generated by and stored with LastPass) and that seems to have resolved it, but Schwab won't let me do anything yet. Amazingly insecure.