Because this code was designed well over a decade ago, and someone decided 16 characters was an acceptable limit. From a guy that worked on the Live team, he said in many years of reviewing the security issues, password length never came up as a high enough priority issue to justify the changes required. There's much more important things for them to do.

Now as to why someone chose 16 characters 10+ years ago... who knows. But having such a limitation roll forward isn't that mysterious.

> Because this code was designed well over a decade ago, and someone decided 16 characters was an acceptable limit. From a guy that worked on the Live team, he said in many years of reviewing the security issues, password length never came up as a high enough priority issue to justify the changes required.

But the limit just does not make sense because the presence of the limit implies that in the authentication database there is a CHAR(16) column in some table, presumably specked that way to limit DB size consumption resulting from storing password values.

But if they were doing the correct, secure, thing, they would not be storing the user entered password, but a hash (assume "hash" to mean proper secure password hash) of the password. The result of the hash function will be to convert an arbitrary length user entered password into a fixed length quantity. And it is that fixed length quantity that is stored for use in future authentications. Meaning that the DB column that stores the hash is "length limited" by the operation of the hash function, such that there is no reason at all to length limit the user entered password string.

Therefore, presence of a user facing length limit on the password implies, but does not prove, the possibility that somewhere they are not performing proper password storage procedures.

10+ years ago, or maybe a bit more, enterprise hard drive sizes were probably still measured in MB. Things like the sizes of fields actually mattered, and the older the system, the more they mattered and the more people would have had to sweat about whether the field was 8, 16, or 32 characters or whatever.

If you are properly hashing a password, then the hash is always of a known length, regardless of length of password.

The password hash has always been computed on the first n < 16 characters of the plain text password. What I suspect is going on now though, is that Hotmail is transitioning to accepting arbitrarily sized, plain text passwords. Before Hotmail can change the code though, they need to get the current users used to entering the <= 16 characters of their 'actual' plain text password. If they just change the code, everyone who has a > 16 character password will find they cant log in. and chaos will ensue.

Doubtful. The implementation is trivial. You just try both during the authentication step. If the password isn't recognized by the full hashing algorithm, try it against the first 16.