Ask HN: Is Apple not hashing passwords? | Hacker News Reader

Ask HN: Is Apple not hashing passwords?

12 pointssjtgraham16 comments

Image: http://i.imgur.com/uSlW2.png

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

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.

View on HN

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. :(

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?

not to say you should preclude a user from choosing long passwords but hex != string...

ruby -rdigest/sha2 -e "puts Digest::SHA512.digest('foo').length" = 64

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

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.

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.

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.

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.

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.

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.

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

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

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?

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

It actually does make sense. If passwords were not hashed they would check the length before inserting in to the database because strings longer than the column size will be silently truncated. There is nothing to suggest passwords ARE hashed.

Clickable: http://i.imgur.com/uSlW2.png

That's what the spec said.

Reply on news.ycombinator.com