> 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

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