

Ask HN: Is Apple not hashing passwords? - sjtgraham

Image: http://i.imgur.com/uSlW2.png<p>After the recent iCloud debacle, I methodically went about setting passwords of everything I care about to use very secure passwords, i.e. very long strings composed of random alphanumeric and non-alphanumeric chars. When it came time to change my AppleID password I noticed forgot.apple.com had max length set to 32 in the password form, after removing with web inspector and submitting I was presented with this http://i.imgur.com/uSlW2.png<p>When a website imposes a maximum length on passwords what other reasonable conclusions can be drawn other than the passwords are not hashed before being persisted? For example a SHA512 is always 128 chars long regardless of input, so why is there a need to put a limit on the maximum amount of chars in a password? Just set the column length to 128 and be done with it.
======
saurik
One of the most popular password hashing algorithms, bcrypt, enforces a
maximum password length: it's algorithm is unable to use extra bits of input
and has to throw them out. That said (as you specifically mention SHA512, an
algorithm that might be used in a password hash but is not appropriate by
itself anyway), a SHA512 is actually 64 bytes long: by an argument as simple
as pigeon hole principal, you can then demonstrate that passwords longer than
64 bytes are totally useless (as there will almost certainly be a second
password, shorter than 64 bytes, which will be equivalent after being run
through the hash); for SHA256, which you will see in use more often, that
limit would be 32 bytes. Please do not make such negative assumptions or state
such strong implementation assertions based on such little knowledge of
hashes. :(

~~~
sjtgraham
What's with the asshole response? Why so condescending? Did you have a bad
day? I'm sorry about that. Yes, SHA512's output is 512 bits (the clue is in
the name), but paste this into your shell `ruby -rdigest/sha2 -e "puts
Digest::SHA512.hexdigest('foo').length"`. You'll see 128. I'm talking about
the length of the string in characters and that's quite obvious. Feel free to
bog yourself in semantics and pedantry. Also none of your comment proves
anything, and you make more assumptions than I do. Is anything you said a sane
reason to go to the trouble of precluding a user from choosing a password > 32
chars?

~~~
zaroth
I'm sorry, what? saurik's response was concise, to the point, technically
sound, and backed up with relevant details. Why in the world would you attack
someone taking the time to answer your question?

Maybe you didn't quite understand saurik's response. There was nothing asshole
about it. S/He conveyed three basic points:

    
    
      1) There are well-regarded hashing algorithm that impose a limit on the input (bcrypt)
      2) In any case, the length-limit does not imply that passwords are stored in clear text
      3) An argument for why the length-limit might actually be a good thing (protecting the user from a false sense of security)
    

Now, I happen to absolutely agree on points #1 and #2, but disagree with #3.

It is not true that passwords longer than the hash output are 'totally
useless'. To find an arbitrary input which produces a specific hash requires
2^(bit-1) guesses on average. 'Attacking the hash' is simply not possible for
a 256-bit hash. The only possible attack vector is to 'attack the password'.
Therefore passwords longer than 32 chars are still useful.

A 12-character truly random password taken from the full character set would
take the #2 super-computer on the planet approximately 8000 days to crack in
2011. [http://www.youtube.com/watch?v=CKNW5AUo-
dM&t=43m50s](http://www.youtube.com/watch?v=CKNW5AUo-dM&t=43m50s)

Add a couple more characters and you're into 'galactic years' to measure how
long it would take. So clearly we don't need anywhere near 32 chars if the
alphabet is large and symbols are picked at RANDOM.

But if you want any hope of being able to REMEMBER the password, then a better
option may be trying to get equivalent entropy using a long pass-phrase; it
could possibly require more than 32 characters to make it long and fun enough
to be memorable.

------
buddhamagnet
But isn't that just the length of the password prior to hashing/comparison? If
so I agree password length is redundant, but that doesn't mean they're not
hashing. At least I HOPE IT DOESN'T.

~~~
codegeek
I agree with you. Even though they are checking the length, it does not
necessarily mean that they are not hashing. On a side note, who will actually
type in a 32 character password and remember it ? I know thats not the point
of this post but still.

------
jasomill
AppleID is a single sign-on used across a wide variety of systems (iTunes,
iCloud, AppleCare, the Apple Online Store, the Mac App Store,
developer.apple.com, bugreport.apple.com, Apple's CA services for code signing
and push notification services, to name just the ones that come immediately to
mind) developed by different groups, at different times, using different
technologies, over a period of many years. Even ignoring hashes and
authentication protocols entirely, the set of fully-functional AppleID
passwords is still the intersection of the sets of valid passwords for all
supported clients of all these systems.

In other words, you're most likely looking at the feature of iForgot that
prevents you from selecting a password that one of the other systems isn't
prepared to handle, or at least _might not_ have been prepared to handle
_reliably_ last time requirements were frozen for a major system-wide upgrade
of the (internal) AppleID protocol.

------
undecisive
tl;dr Probably unhashed or project manager.

There is a very unlikely security scenario, where the hash of the password
actually forms a dictionary word (or combination of dictionary words).

I did say it was very unlikely (astronomically so). And this only mitigates
against this if the login form restricts your password to 32 chars.

I'll vote with "inept project manager" or unhashed password. Not sure which
worries me more.

I would love to be an optimist, but the internet keeps proving me wrong.

------
amccloud
If anything, this proves they are hashing to something like MD5 because the
max length on the password column is 32. They're likely using some sort of
ORM/declarative model that you define validation rules on. It makes sense to
set the max length of your password column to the hashes length. It just
happens that their forms using the same validation rules as their
models/database.

------
vinhboy
Nah... It's probably because of a project manager...

------
cypherpunks01
What? This doesn't make any sense at all. They just check the length
restriction server-side _before_ hashing it.

~~~
wlll
Why do they need to check the length of a password before hashing when the
resulting password hash will be a fixed length regardless of the length of the
original password?

~~~
frou_dh
I can imagine a thought process along the lines of: "Most people don't use
password managers, so it's asking for trouble to allow extremely long
passwords. 32 should be plenty, even for the security conscious minority."

------
joshu
Clickable: <http://i.imgur.com/uSlW2.png>

------
smparkes
That's what the spec said.

