
Amazon.com Security Flaw Accepts Passwords That Are Close, But Not Exact - gaiusparx
http://www.wired.com/threatlevel/2011/01/amazon-password-problem/
======
nbpoole
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_f...](http://www.reddit.com/r/WTF/comments/f96w7/amazon_security_flaw_wtf/c1e9750))

------
tel
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
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/> 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
> _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.

~~~
lvh
I think he was thinking of truncation by crypt, so that even passwords that
are completely different (bar the first 8 chars, bar collisions) would match.

~~~
drivebyacct2
I think the point is, the user's password could potentially be set to
something other than the original if they happen to type it "close enough".
That would cause major confusion going forward.

------
johnswamps
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
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
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.

~~~
nbpoole
"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."

If that's the case, you're doing it wrong (it being password hashing). Because
if you can hash 1000 passwords fairly quickly, that's the lower bound of what
a dedicated attacker can do. ;)

~~~
mgkimsal
If Amazon is letting someone attempt 1000 failed login attempts, even over
several hours or a day, they're doing something wrong.

~~~
nbpoole
You also have to consider the possibility of an offline attack (ie: if
Amazon's database were compromised and password hashes were leaked).

------
joshfraser
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.

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

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

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

------
goombastic
This sounds like a feature to me. :)

------
CamperBob
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
> _strong passwords will still be strong._

I think you meant: strong passwords will be truncated down to 8 chars, making
them weak.

~~~
jemfinch
Strong, 8-character passwords are 1 in 5132188731375616. Is that really so
weak?

~~~
nbpoole
That depends on how fast you can check for validity.

See <http://news.ycombinator.com/item?id=2003888> or
<http://news.ycombinator.com/item?id=1545576> for examples of how fast certain
types of brute-force attacks have become.

------
earl
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
I changed my password between two and five years ago, and I wasn't able to
replicate it using my account.

