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