Hacker News Reader

Comment by bradbeattie | Hacker News Reader

"store full plaintext passwords in their db; compare the first 16 chars only [or] calculate the hash only on the first 16; ignore the rest"

Not entirely true. They could have stored the full passwords. Upon successful authentication, overwrite the saved hash with the hash of the first 16. Otherwise, retry authentication with just the first 16 characters. The password database would slowly adjust.

Doesn't begin to explain _why_ they'd put this limitation in after the fact, but it's not impossible.

View on HN

But that definitely is not what happened here, right? Because they are letting you sign in with the first 16 characters of your password, it means that they must have access to plaintext of your old password. OP was unable to login with the long version of his password, the two options he outlines are the only possible way this did happen, not options for how one might implement this change.

What I think he is trying to say is that (the dates are examples):

The Hotmail team decided to truncate all passwords to 16 chars last month, but they only store the hashes of the passwords. So the plan is:

For each user, when it submits the login form with his username and password, do the following:

1. Compare the username and the hash of the password to the ones stored on the database

2. If they match, replace the current password hash with the hash of the first 16 chars of the password that the user just sent -- because at this moment, the plain text password is available in the login form

---

So, the hypothesis is that the OP logged in successfully yesterday, then had its password replace, and today when he tried to login again he couldn't, because the hash was changed.

Just one issue with that. If Microsoft is storing the hash, how does it know what the original password was and whether it was greater than 16 chars? If the algorithm is as above, then I just have to enter a password greater than 16 chars against ANYONE's username to be prompted for a password change and compromise their account.

Two arguments. The first is Microsoft doesn't need to know that the hash belongs to a password > 16 chars, it just needs to detect that the user is entering in 17+ characters and has not updated their password since the Hotmail update, and assume that they are submitting a password that is 17+ characters which should now be invalid, validate the old hash upon submission, fail authentication and prompt an "error" and ask for the truncated password, and then calculate a new hash and authenticate against that. Theres absolutely no reason for them to be doing that though, and it doesn't make a lick of sense either.

The second argument is that they have been silently truncating passwords to 16 characters forever, which they admit to. http://windows.microsoft.com/en-US/windows-live/microsoft-ac...

Occams Razor suggests it's much more likely that back in the dawn of time some programmer thought a varchar(16) was more than big enough for a password column, it's even possible that's a consequence of how Solaris stored email/user passwords back in '96 before Microsoft bought Hotmail...

I _strongly_ suspect this means Hotmail has been storing cleartext passwords forever - people postulating strange workarounds whereby they might be able to detect password lengths in spite of storing hashes instead of passwords seem to me to be spectacularly unlikely compared to the much simpler alternative that they've been storing plaintext passwords truncated to 16 chars.

> it's even possible that's a consequence of how Solaris stored email/user passwords back in '96 before Microsoft bought Hotmail...

From what I remember, Hotmail was a FreeBSD shop before Microsoft bought them, and ended up spending a boatload of money switching all the servers to NT.

But to the main point, I agree the 16 char limit smells strongly of plaintext passwords. However, there might be an argument that at one point those were all hashed for a massive security update. That would maintain the 16 char limit of the plaintext password since that would have been what the hash was generated from, but solve the issue of actually storing plaintext. I'd like to give Hotmail/Microsoft/Windows Live ID the benefit of the doubt and not immediately assume that they are _currently_ storing plaintext. (yeah, I know I shouldn't give anyone the benefit of a doubt in regards to security procedure)

Hotmail doesn't store any passwords, it is all centralized as part of Windows Live ID (Passport).

They don't need to know the original password, they first check if your supplied password (which can be greater than 16 characters) when hashed matches the hash they have in the database currently, then if it does and it's greater than 16 characters truncate the length of the password you supplied to 16 and then hash that and update the database with it.

I'm not sure that would work. If that were the case, then anyone who did not login between when the decision to go 16 characters was made and today would have to login one time with their full password so that they could confirm that you know the true password and compute the new hash. Then all subsequent logins would be 16 characters long. But I don't think that this dialog is only being presented to people who have magically logged in in that time interval, it is being offered to everyone. So, unless there is some evidence that they are right now performing password swaps for people who haven't logged in in a while, the two hypotheses in the article and the only two that are possible.

^ Yes, this is exactly how I've solved this problem in the past. A slow user driven migration.

Reply on news.ycombinator.com