6 ms·

Amazon.com Security Flaw Accepts Passwords That Are Close, But Not Exact

68 points by gaiusparx 16y ago

joshfraser 16y ago
My guess is the average Amazon user isn't going over 8 characters and aren't using multi-case passwords to begin with. While stronger passwords would be ideal, most non-savy people are still going with "password", "letmein" and "123456" which aren't secure under any hashing schema.
flawawa2 16y ago
I had trouble with this some months ago. It took me a while to realise the issue at hand and ultimately I had to call Amazon customer support. They reset passwords to "amazon" if you do so... I do not remember the full details but judging from log files I was trying to set a long password (20 alphanumeric varied case characters) and it never let me login again. This happened multiple times.
goombastic 16y ago
This sounds like a feature to me. :)
deleted 16y ago
[deleted]
earl 16y ago
I couldn't replicate the article's results for the 8 character cutoff, but I did verify my password is case insensitive. For the record, I registered in 1996 or so, and probably haven't changed my password since.
- dkarl 16y ago
  I changed my password between two and five years ago, and I wasn't able to replicate it using my account.
- corin_ 16y ago
  I replicated the 8 character issue on one of my accounts (presumably the older of the two).
tel 16y ago
Is there a good way to update passwords to a new encryption scheme? the article tries to ding amazon for failing to do this, but I can't think of a way to reinforce the passwords without announcing that there's a flaw in the implementation. Is there a standard way around this?
- nbpoole 16y ago
  Yes. Sort of. ;-) The standard way I've seen is to do this when the user logs in: if in checking their password you notice they're using the old hashing scheme, you use the plaintext password provided by the login process to generate a hash using the new scheme. For example, lets say you're a PHP function that takes in $username and $password (both plaintext). You're "upgrading" from unsalted MD5 to unsalted SHA1 (NOTE: DO NOT DO THIS IN REAL LIFE. READ http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ AND UNDERSTAND WHY UNSALTED MD5 / SHA1 SHOULD NOT BE USED FOR PASSWORD SECURITY). Your code to upgrade the hashes would look something like this: if (md5($password) === $cur_user['password']) $cur_user['password'] = sha1($password); Now, you may have realized that there's a flaw here. Since the server uses the hash for verification, it can't be 100% sure that the plaintext password is actually correct. If there's a collision (two plaintexts hashing to the same value), you could inadvertently store the wrong password in your new hash. In this case, the problem is that passwords longer than eight characters are silently truncated. So, if my password is something like supersecretpassword, I could also enter supersec and have it accepted (since they hash to the same value). That would be a problem for Amazon, since someone could make a typo in their password and have the wrong value stored in the new hash.
  - Groxx 16y ago
    >Now, you may have realized that there's a flaw here. ... Not really. It's more of a fundamental property of hashing functions, and it's technically true of any hashing function, and collisions are nearly just a technical possibility unless you're using an incredibly-small hash output. Though that would likely be preferable to truncating before hashing - fewer practical collisions and safer, as reversing the hash is less useful due to more collisions actually existing in breakably-short password lengths.
nbpoole 16y ago
The comment thread on Reddit, which the article references, is definitely worth reading. There's some good discussion about the difficulties involved in upgrading people's hashes to use a more secure system (eg: http://www.reddit.com/r/WTF/comments/f96w7/amazon_security_flaw_wtf/c1e9750 http://www.reddit.com/r/WTF/comments/f96w7/amazon_security_f...)
deleted 16y ago
[deleted]
ronnier 16y ago
I reported the same flaw for http://utd.edu http://utd.edu. They didn't seem to care.
pieter 16y ago
Passwords on the Dutch banking site ing.nl are also case insensitive, though there hasn't been any public reaction to that.
rabidsnail 16y ago
Want to bet they didn't fix this until now because they knew it would lower purchase conversion rate?
CamperBob 16y ago
What exactly does this hurt? It cuts down on customer-support traffic, makes life easier for the user, and (as far as I can imagine at least) doesn't make anyone any more vulnerable. Under a fuzzy comparison scheme, weak passwords are still weak, and strong passwords will still be strong.
- RickHull 16y ago
  > strong passwords will still be strong. I think you meant: strong passwords will be truncated down to 8 chars, making them weak.
  - kgermino 16y ago
    To be fair almost any password is weak if it hasn't been changed in several years.
  - jemfinch 16y ago
    Strong, 8-character passwords are 1 in 5132188731375616. Is that really so weak?
    - nbpoole 16y ago
      That depends on how fast you can check for validity. See http://news.ycombinator.com/item?id=2003888 http://news.ycombinator.com/item?id=2003888 or http://news.ycombinator.com/item?id=1545576 http://news.ycombinator.com/item?id=1545576 for examples of how fast certain types of brute-force attacks have become.
- jackowayed 16y ago
  A strong password that gets a lot of its strength from length and mixed case will not still be strong under this error. For example, the password fOoBaRbAzbArBaZFoO would be a pretty strong password. foobarba is much weaker, and this error would make foobarba (and foobarbaz, etc) work.
  - CamperBob 16y ago
johnswamps 16y ago
If done deliberately, could this be a useful feature so that users can typo a password (say levenshtein distance <= 1 or 2) and still login? Obviously the major downside is that you would need a longer password to get the same level of security and it could be difficult to implement especially since the password should be hashed. Is this feasible? I'm guessing the answer is no, but was wondering what other people thought.
- epochwolf 16y ago
  Only if you want to store all the passwords in reversible encryption* or do some crazy scheme which you check every possible combination of hashes within the distance of the current password. * If I find out you've been storing passwords in plain text I will hunt you down and slap you. :)
  - Retric 16y ago
    I don't think checking every hash within one of the password is going to cost much, worst case your checking less than 1,000 passwords. However, I would much rather a system that checked 2 passwords one with and one without the caps lock on. AKA 1Password and 1pASSWORD.
    - MartinCron 16y ago
      Storing the CAPS LOCK and non caps lock hashes of a password seems utterly brilliant. I'm tempted to start doing that.
      - sparky 16y ago
        Might improve user experience a bit, but your password hashing scheme needs to take much longer if an attacker knows he can rule out lower-case letters. For example, 8-character alphanumeric passwords: ((26*2)+10)^8 / (26+10)^8 = 77.4 You have 77 times fewer passwords of length 8 (probably worse than that, most people skew more towards letters than numbers), so it should take 77 times longer to test one.
deleted 16y ago
[deleted]

68 points by gaiusparx 16y ago

My guess is the average Amazon user isn't going over 8 characters and aren't using multi-case passwords to begin with. While stronger passwords would be ideal, most non-savy people are still going with "password", "letmein" and "123456" which aren't secure under any hashing schema.

flawawa2 16y ago

I had trouble with this some months ago. It took me a while to realise the issue at hand and ultimately I had to call Amazon customer support. They reset passwords to "amazon" if you do so... I do not remember the full details but judging from log files I was trying to set a long password (20 alphanumeric varied case characters) and it never let me login again. This happened multiple times.

goombastic 16y ago

This sounds like a feature to me. :)

deleted 16y ago

[deleted]

earl 16y ago

I couldn't replicate the article's results for the 8 character cutoff, but I did verify my password is case insensitive. For the record, I registered in 1996 or so, and probably haven't changed my password since.

dkarl 16y ago
I changed my password between two and five years ago, and I wasn't able to replicate it using my account.
corin_ 16y ago
I replicated the 8 character issue on one of my accounts (presumably the older of the two).

tel 16y ago

Is there a good way to update passwords to a new encryption scheme? the article tries to ding amazon for failing to do this, but I can't think of a way to reinforce the passwords without announcing that there's a flaw in the implementation. Is there a standard way around this?

nbpoole 16y ago
Yes. Sort of. ;-) The standard way I've seen is to do this when the user logs in: if in checking their password you notice they're using the old hashing scheme, you use the plaintext password provided by the login process to generate a hash using the new scheme. For example, lets say you're a PHP function that takes in $username and $password (both plaintext). You're "upgrading" from unsalted MD5 to unsalted SHA1 (NOTE: DO NOT DO THIS IN REAL LIFE. READ http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ AND UNDERSTAND WHY UNSALTED MD5 / SHA1 SHOULD NOT BE USED FOR PASSWORD SECURITY). Your code to upgrade the hashes would look something like this: if (md5($password) === $cur_user['password']) $cur_user['password'] = sha1($password); Now, you may have realized that there's a flaw here. Since the server uses the hash for verification, it can't be 100% sure that the plaintext password is actually correct. If there's a collision (two plaintexts hashing to the same value), you could inadvertently store the wrong password in your new hash. In this case, the problem is that passwords longer than eight characters are silently truncated. So, if my password is something like supersecretpassword, I could also enter supersec and have it accepted (since they hash to the same value). That would be a problem for Amazon, since someone could make a typo in their password and have the wrong value stored in the new hash.
- Groxx 16y ago
  >Now, you may have realized that there's a flaw here. ... Not really. It's more of a fundamental property of hashing functions, and it's technically true of any hashing function, and collisions are nearly just a technical possibility unless you're using an incredibly-small hash output. Though that would likely be preferable to truncating before hashing - fewer practical collisions and safer, as reversing the hash is less useful due to more collisions actually existing in breakably-short password lengths.

nbpoole 16y ago

The comment thread on Reddit, which the article references, is definitely worth reading. There's some good discussion about the difficulties involved in upgrading people's hashes to use a more secure system (eg: http://www.reddit.com/r/WTF/comments/f96w7/amazon_security_flaw_wtf/c1e9750 http://www.reddit.com/r/WTF/comments/f96w7/amazon_security_f...)

deleted 16y ago

[deleted]

ronnier 16y ago

I reported the same flaw for http://utd.edu http://utd.edu. They didn't seem to care.

pieter 16y ago

Passwords on the Dutch banking site ing.nl are also case insensitive, though there hasn't been any public reaction to that.

rabidsnail 16y ago

Want to bet they didn't fix this until now because they knew it would lower purchase conversion rate?

CamperBob 16y ago

What exactly does this hurt? It cuts down on customer-support traffic, makes life easier for the user, and (as far as I can imagine at least) doesn't make anyone any more vulnerable. Under a fuzzy comparison scheme, weak passwords are still weak, and strong passwords will still be strong.

RickHull 16y ago
> strong passwords will still be strong. I think you meant: strong passwords will be truncated down to 8 chars, making them weak.
- kgermino 16y ago
  To be fair almost any password is weak if it hasn't been changed in several years.
- jemfinch 16y ago
  Strong, 8-character passwords are 1 in 5132188731375616. Is that really so weak?
  - nbpoole 16y ago
    That depends on how fast you can check for validity. See http://news.ycombinator.com/item?id=2003888 http://news.ycombinator.com/item?id=2003888 or http://news.ycombinator.com/item?id=1545576 http://news.ycombinator.com/item?id=1545576 for examples of how fast certain types of brute-force attacks have become.
jackowayed 16y ago
A strong password that gets a lot of its strength from length and mixed case will not still be strong under this error. For example, the password fOoBaRbAzbArBaZFoO would be a pretty strong password. foobarba is much weaker, and this error would make foobarba (and foobarbaz, etc) work.
- CamperBob 16y ago

johnswamps 16y ago

If done deliberately, could this be a useful feature so that users can typo a password (say levenshtein distance <= 1 or 2) and still login? Obviously the major downside is that you would need a longer password to get the same level of security and it could be difficult to implement especially since the password should be hashed. Is this feasible? I'm guessing the answer is no, but was wondering what other people thought.

epochwolf 16y ago
Only if you want to store all the passwords in reversible encryption* or do some crazy scheme which you check every possible combination of hashes within the distance of the current password. * If I find out you've been storing passwords in plain text I will hunt you down and slap you. :)
- Retric 16y ago
  I don't think checking every hash within one of the password is going to cost much, worst case your checking less than 1,000 passwords. However, I would much rather a system that checked 2 passwords one with and one without the caps lock on. AKA 1Password and 1pASSWORD.
  - MartinCron 16y ago
    Storing the CAPS LOCK and non caps lock hashes of a password seems utterly brilliant. I'm tempted to start doing that.
    - sparky 16y ago
      Might improve user experience a bit, but your password hashing scheme needs to take much longer if an attacker knows he can rule out lower-case letters. For example, 8-character alphanumeric passwords: ((26*2)+10)^8 / (26+10)^8 = 77.4 You have 77 times fewer passwords of length 8 (probably worse than that, most people skew more towards letters than numbers), so it should take 77 times longer to test one.

deleted 16y ago

[deleted]