[krishnakv]

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.

[uxp]

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

[bigiain]

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.

[uxp]

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

[papercruncher]

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

[ignignokt]

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.