7 ms·

Hotmail: Your password was too long, so we fixed it for you

84 points by timf 14y ago

0x0 14y ago
This sounds suspiciously similar to the LM (of NTLM) password limits, http://en.wikipedia.org/wiki/NTLM#cite_ref-v1_13-0 http://en.wikipedia.org/wiki/NTLM#cite_ref-v1_13-0
- TazeTSchnitzel 14y ago
  Might make sense. Microsoft Accounts are also user accounts in Windows 8.
runn1ng 14y ago
Why does hotmail has this 16-letter limit in the first place? I would get it 7 years ago, but now?
- MichaelGG 14y ago
  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.
  - ams6110 14y ago
    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.
    - city41 14y ago
      If you are properly hashing a password, then the hash is always of a known length, regardless of length of password.
  - pwg 14y ago
    > 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.
- msderosa 14y ago
  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.
  - stouset 14y ago
    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.
deleted 14y ago
[deleted]
lucian303 14y ago
The problem isn't just hotmail. Most major banks (amex, chase, etc.) forbid special characters, limit the password length as well, or a combination of both. Then again, banks are not exactly on the cutting edge of security, though they like to seem like they are. This isn't a surprise considering how shoddily their web apps are built.
- vectorbunny 14y ago
  I was recently setting up an online account with Charter because my wife and were having issues with the irregular nature of their paper billing. After securing the PIN number that was only on the paper bill that they weren't sending us, I created the account with a 30 character password string that was generated and stored within Password Gorilla. Charter's webapp took the password, which was to long for them, and instead of throwing an error and telling me to choose a shorter password, it truncated it at some arbitrary position to fit their policy. Locked out! Ten minutes get to a human on the phone, another five to explain why someone would use a 30 character password and how they might go about doing it... eventually the password was reset. Good times.
- jrockway 14y ago
  Then again, banks are not exactly on the cutting edge of security, though they like to seem like they are. Every bank I've ever dealt with has assumed 100% liability for unauthorized transactions, so a bad password affects them financially, not you. Therefore, I don't understand all the complaining about password length.
  - meritt 14y ago
    That's a pretty damn naive statement. Yes, in the end, customers are financially protected. But that doesn't make up for the hours, days or even weeks of phone calls, emails, letters, in-person visits, credit-reporting agency fixes, etc which are necessary to rectify fraud in the banking/finance industry.
  - chc 14y ago
    A friend of a friend recently had $500 stolen and Chase didn't reimburse him for that, so this doesn't seem to be universal. (On the other hand, Bank of America did issue me a temporary credit for my money that got stolen in the same compromise, so I know it happens sometimes.)
bradbeattie 14y ago
"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.
- systematical 14y ago
  ^ Yes, this is exactly how I've solved this problem in the past. A slow user driven migration.
- macrael 14y ago
  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.
  - lucastx 14y ago
    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.
    - krishnakv 14y ago
dhughes 14y ago
Add to that every time someone tries to log into my account I get an e-mail asking me to confirm or deny the attempt; instead of the option to ignore it. And multiple attempts by other people to log in to my account by other people locks me out. It's a good thing I only use it for Xbox.
sitharus 14y ago
An interesting article, but still promoting that old password advice that creates crackable but not memorable passwords. If you have a hash that can do ~2 billion keys/sec then you can simply brute force the keyspace including symbols. Obligatory XKCD: http://xkcd.com/936/ http://xkcd.com/936/ The 16 character limit really helps though :)
MetallicCloud 14y ago
I'm fairly certain that they always truncated to the first 16 characters. About a year ago I had a 20 char password for my hotmail, and would happily enter it, but one day I was using some other input method (I think it was on my phone) and it stopped entering chars from 16 onwards. I was confused when it accepted my password, but then after some testing I realised what was happening. It just seems they are being more explicit about it now. It is quite an odd decision to make though.
- dpark 14y ago
  > It just seems they are being more explicit about it now. It is quite an odd decision to make though. Given a choice between hidden limitations and explicit limitations, I'd much rather have the explicit ones. At least then it's clear what you're getting. I'd prefer they eliminate the artificial restrictions entirely, of course. Disclosure: Microsoft employee
  - olivier1664 14y ago
    What is freaking is that it may not be an "artificial restriction", but a VARCHAR(16) restriction caused by a plain-text storing. We certainly all have done this error: you create a database with the table "User" with the password in plain text. So VARCHAR, and humm, a max size... my password is 6 character long, but some user may go to 8, ok to be sure nobody will never complains, let's go for 16 characters. With some luck, your database truncate VARCHAR that are too long into VARCHAR(16) without notifying you. In this case, chance are nobody will notices there is a problem. I do not thing this is the current explanation for hotmail. But it is funny to see that it looks like a very basic error.
    - dpark 14y ago
      I seriously doubt that this is the case (though I have no visibility into Microsoft account auth). Most likely, there was some poor design choice years ago (such as the one you described) that has been corrected, but the effects its caused haven't been fixed through the codebase. e.g. I would not be surprised if the code contains something like this: struct user_auth { char username[64]; char pw[16]; // TODO: Allow longer passwords //... }; bool authenticate_user(user_auth* ua); This kind of code would limit passwords to 16 characters, but would be irrelevant to how passwords are currently hashed or stored.
mediocregopher 14y ago
yahoo is even worse. I went to change my password from a very easily guessable one to a not as guessable one. Once I figured out a password which fit their stupid requirements (if my password is >20 chars I don't think it having an upper or lower case is going to be the kicker) the site told me I had successfully changed my password. When I went to log in however it would not let me log in. Turns out yahoo had silently truncated my password down to 24 letters. No indication that this had been done, it was really only through trial and error (I had a feeling something was up, and my password isn't too much more then 24) that I figured it out.
ams6110 14y ago
Passwords/phrases have really got to go. They are a relic, and every year they offer less and less security. Plus even reasonably smart programmers and administrators continually make the same mistakes over and over in handling them; no real reason to think that will suddenly change. I'm not sure what the answer is, but the vast majority of people are not going to be content with typing a 30 character or more passphrase even if it's something memorable, never mind the 6 - 12 character ones that look like line noise. Password managers are just a band-aid, and again most people would find them annoying. People just want to get to their email, do their banking, shopping, pay their bills, whatever. There's got to be something better than passwords. Maybe someone can really put some consumer-oriented thinking behind something like PKI and make it EASY for the average person.
- jib 14y ago
  Square? If it's not something you know it needs to be something you own. Cc's seem like a possible thing a lot of people own. Square-like thing for authing by swiping seems like it could be done. Or maybe mobile as a remote would be enough on it's own for most cases. Visit on web, unlock by pressing separate mobile button.
  - jarrett 14y ago
    "If it's not something you know it needs to be something you own" -- Agreed, and I much prefer to authenticate with something I know. I'd rather not have all my accounts bound to some tangible object that can be lost, broken, or revoked by a central authority. I absolutely do not want my credit card company or anyone else to be the middleman every time I authenticate to any service. If that happens, they pretty much own me. Imagine what would happen if, for whatever reason, they stopped authenticating me. Granted, if I authenticate with something I know, there's a small chance I'll lose it due to memory loss. (Car accident, etc.) But that seems much less likely than me losing something I own.
moeffju 14y ago
How does this make sense? If they hash the passwords, they get a fixed length result anyway. Why would they truncate the plaintext before hashing?
ck2 14y ago
1. salt 2. don't allow unlimited password attempts
Joeri 14y ago
The hashing algorithm is one part of the puzzle. We need to get everyone to switch to bcrypt or pbkdf2. But more importantly, we have to improve web dev practice to make sql injection a thing of the past. Most of these password thefts are enabled by sql injection attacks used to steal the database. And finally, we need a standard solution for two factor auth. We should have a way to integrate two factor auth into our sites without being tied to a google account or something similar.
- jamoes 14y ago
  What I'd really prefer to see is to simply never send my password over the wire to a website. I don't want to have to place any trust in them. When I log into an SSH server, I am authenticated using purely my private and public keys. The SSH server has my public key, and my computer has my private key. A password is never sent over the wire, which doesn't give an adversarial SSH server the opportunity to store a password. And, if the SSH server is compromised, it doesn't even really matter - all the attacker gets is my public key. Why isn't this authentication mechanism standard for the web? And, why isn't anyone even talking about building something like this? I'd much rather see browsers implement public key authentication than things like Persona or OpenID.
  - mkup 14y ago
    SSL client side certificates are already implemented, but they have their own problems: 1) UI is hard to use http://pilif.github.com/2008/05/why-is-nobody-using-ssl-client-certificates/ http://pilif.github.com/2008/05/why-is-nobody-using-ssl-clie... 2) Can be easily stolen by malware (if client certificate is password-protected then password can be locally bruteforced on attacker's system) 3) It's not easy to switch identities (if you have multiple accounts on some website). And whenever there is no support for multiple identities, there is a ground for privacy concerns. 4) It's almost impossible to enter them from keyboard. How do I enter one on the iPhone? How do I write it on paper? What if I need to access some website from work and from home? What if my USB thumbdrive with client SSL certs fails or gets stolen? 5) They expire eventually, and when they do, users have another out-of-common-sense problem to solve. So, implementation already exists but it's impractical.
richardkeller 14y ago
Yikes. Take a look at this gem from Microsoft's knowledge-base: "This doesn't mean that your password has been shortened. Actually, Windows Live ID passwords were always limited to 16 characters—any additional password characters were ignored by the sign-in process." Translation: "Even though you typed in a 40-character password when you first signed up, we ignored most of it and only used the first 16 characters." Source: http://windows.microsoft.com/en-US/windows-live/microsoft-account-password-16-characters http://windows.microsoft.com/en-US/windows-live/microsoft-ac...

84 points by timf 14y ago

0x0 14y ago

This sounds suspiciously similar to the LM (of NTLM) password limits, http://en.wikipedia.org/wiki/NTLM#cite_ref-v1_13-0 http://en.wikipedia.org/wiki/NTLM#cite_ref-v1_13-0

TazeTSchnitzel 14y ago
Might make sense. Microsoft Accounts are also user accounts in Windows 8.

runn1ng 14y ago

Why does hotmail has this 16-letter limit in the first place? I would get it 7 years ago, but now?

MichaelGG 14y ago
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.
- ams6110 14y ago
  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.
  - city41 14y ago
    If you are properly hashing a password, then the hash is always of a known length, regardless of length of password.
- pwg 14y ago
  > 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.
msderosa 14y ago
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.
- stouset 14y ago
  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.

deleted 14y ago

[deleted]

lucian303 14y ago

The problem isn't just hotmail. Most major banks (amex, chase, etc.) forbid special characters, limit the password length as well, or a combination of both. Then again, banks are not exactly on the cutting edge of security, though they like to seem like they are. This isn't a surprise considering how shoddily their web apps are built.

vectorbunny 14y ago
I was recently setting up an online account with Charter because my wife and were having issues with the irregular nature of their paper billing. After securing the PIN number that was only on the paper bill that they weren't sending us, I created the account with a 30 character password string that was generated and stored within Password Gorilla. Charter's webapp took the password, which was to long for them, and instead of throwing an error and telling me to choose a shorter password, it truncated it at some arbitrary position to fit their policy. Locked out! Ten minutes get to a human on the phone, another five to explain why someone would use a 30 character password and how they might go about doing it... eventually the password was reset. Good times.
jrockway 14y ago
Then again, banks are not exactly on the cutting edge of security, though they like to seem like they are. Every bank I've ever dealt with has assumed 100% liability for unauthorized transactions, so a bad password affects them financially, not you. Therefore, I don't understand all the complaining about password length.
- meritt 14y ago
  That's a pretty damn naive statement. Yes, in the end, customers are financially protected. But that doesn't make up for the hours, days or even weeks of phone calls, emails, letters, in-person visits, credit-reporting agency fixes, etc which are necessary to rectify fraud in the banking/finance industry.
- chc 14y ago
  A friend of a friend recently had $500 stolen and Chase didn't reimburse him for that, so this doesn't seem to be universal. (On the other hand, Bank of America did issue me a temporary credit for my money that got stolen in the same compromise, so I know it happens sometimes.)

bradbeattie 14y ago

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

systematical 14y ago
^ Yes, this is exactly how I've solved this problem in the past. A slow user driven migration.
macrael 14y ago
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.
- lucastx 14y ago
  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.
  - krishnakv 14y ago

dhughes 14y ago

Add to that every time someone tries to log into my account I get an e-mail asking me to confirm or deny the attempt; instead of the option to ignore it. And multiple attempts by other people to log in to my account by other people locks me out. It's a good thing I only use it for Xbox.

sitharus 14y ago

An interesting article, but still promoting that old password advice that creates crackable but not memorable passwords. If you have a hash that can do ~2 billion keys/sec then you can simply brute force the keyspace including symbols. Obligatory XKCD: http://xkcd.com/936/ http://xkcd.com/936/ The 16 character limit really helps though :)

MetallicCloud 14y ago

I'm fairly certain that they always truncated to the first 16 characters. About a year ago I had a 20 char password for my hotmail, and would happily enter it, but one day I was using some other input method (I think it was on my phone) and it stopped entering chars from 16 onwards. I was confused when it accepted my password, but then after some testing I realised what was happening. It just seems they are being more explicit about it now. It is quite an odd decision to make though.

dpark 14y ago
> It just seems they are being more explicit about it now. It is quite an odd decision to make though. Given a choice between hidden limitations and explicit limitations, I'd much rather have the explicit ones. At least then it's clear what you're getting. I'd prefer they eliminate the artificial restrictions entirely, of course. Disclosure: Microsoft employee
- olivier1664 14y ago
  What is freaking is that it may not be an "artificial restriction", but a VARCHAR(16) restriction caused by a plain-text storing. We certainly all have done this error: you create a database with the table "User" with the password in plain text. So VARCHAR, and humm, a max size... my password is 6 character long, but some user may go to 8, ok to be sure nobody will never complains, let's go for 16 characters. With some luck, your database truncate VARCHAR that are too long into VARCHAR(16) without notifying you. In this case, chance are nobody will notices there is a problem. I do not thing this is the current explanation for hotmail. But it is funny to see that it looks like a very basic error.
  - dpark 14y ago
    I seriously doubt that this is the case (though I have no visibility into Microsoft account auth). Most likely, there was some poor design choice years ago (such as the one you described) that has been corrected, but the effects its caused haven't been fixed through the codebase. e.g. I would not be surprised if the code contains something like this: struct user_auth { char username[64]; char pw[16]; // TODO: Allow longer passwords //... }; bool authenticate_user(user_auth* ua); This kind of code would limit passwords to 16 characters, but would be irrelevant to how passwords are currently hashed or stored.

mediocregopher 14y ago

yahoo is even worse. I went to change my password from a very easily guessable one to a not as guessable one. Once I figured out a password which fit their stupid requirements (if my password is >20 chars I don't think it having an upper or lower case is going to be the kicker) the site told me I had successfully changed my password. When I went to log in however it would not let me log in. Turns out yahoo had silently truncated my password down to 24 letters. No indication that this had been done, it was really only through trial and error (I had a feeling something was up, and my password isn't too much more then 24) that I figured it out.

ams6110 14y ago

Passwords/phrases have really got to go. They are a relic, and every year they offer less and less security. Plus even reasonably smart programmers and administrators continually make the same mistakes over and over in handling them; no real reason to think that will suddenly change. I'm not sure what the answer is, but the vast majority of people are not going to be content with typing a 30 character or more passphrase even if it's something memorable, never mind the 6 - 12 character ones that look like line noise. Password managers are just a band-aid, and again most people would find them annoying. People just want to get to their email, do their banking, shopping, pay their bills, whatever. There's got to be something better than passwords. Maybe someone can really put some consumer-oriented thinking behind something like PKI and make it EASY for the average person.

jib 14y ago
Square? If it's not something you know it needs to be something you own. Cc's seem like a possible thing a lot of people own. Square-like thing for authing by swiping seems like it could be done. Or maybe mobile as a remote would be enough on it's own for most cases. Visit on web, unlock by pressing separate mobile button.
- jarrett 14y ago
  "If it's not something you know it needs to be something you own" -- Agreed, and I much prefer to authenticate with something I know. I'd rather not have all my accounts bound to some tangible object that can be lost, broken, or revoked by a central authority. I absolutely do not want my credit card company or anyone else to be the middleman every time I authenticate to any service. If that happens, they pretty much own me. Imagine what would happen if, for whatever reason, they stopped authenticating me. Granted, if I authenticate with something I know, there's a small chance I'll lose it due to memory loss. (Car accident, etc.) But that seems much less likely than me losing something I own.

moeffju 14y ago

How does this make sense? If they hash the passwords, they get a fixed length result anyway. Why would they truncate the plaintext before hashing?

ck2 14y ago

1. salt 2. don't allow unlimited password attempts

Joeri 14y ago

The hashing algorithm is one part of the puzzle. We need to get everyone to switch to bcrypt or pbkdf2. But more importantly, we have to improve web dev practice to make sql injection a thing of the past. Most of these password thefts are enabled by sql injection attacks used to steal the database. And finally, we need a standard solution for two factor auth. We should have a way to integrate two factor auth into our sites without being tied to a google account or something similar.

jamoes 14y ago
What I'd really prefer to see is to simply never send my password over the wire to a website. I don't want to have to place any trust in them. When I log into an SSH server, I am authenticated using purely my private and public keys. The SSH server has my public key, and my computer has my private key. A password is never sent over the wire, which doesn't give an adversarial SSH server the opportunity to store a password. And, if the SSH server is compromised, it doesn't even really matter - all the attacker gets is my public key. Why isn't this authentication mechanism standard for the web? And, why isn't anyone even talking about building something like this? I'd much rather see browsers implement public key authentication than things like Persona or OpenID.
- mkup 14y ago
  SSL client side certificates are already implemented, but they have their own problems: 1) UI is hard to use http://pilif.github.com/2008/05/why-is-nobody-using-ssl-client-certificates/ http://pilif.github.com/2008/05/why-is-nobody-using-ssl-clie... 2) Can be easily stolen by malware (if client certificate is password-protected then password can be locally bruteforced on attacker's system) 3) It's not easy to switch identities (if you have multiple accounts on some website). And whenever there is no support for multiple identities, there is a ground for privacy concerns. 4) It's almost impossible to enter them from keyboard. How do I enter one on the iPhone? How do I write it on paper? What if I need to access some website from work and from home? What if my USB thumbdrive with client SSL certs fails or gets stolen? 5) They expire eventually, and when they do, users have another out-of-common-sense problem to solve. So, implementation already exists but it's impractical.

richardkeller 14y ago

Yikes. Take a look at this gem from Microsoft's knowledge-base: "This doesn't mean that your password has been shortened. Actually, Windows Live ID passwords were always limited to 16 characters—any additional password characters were ignored by the sign-in process." Translation: "Even though you typed in a 40-character password when you first signed up, we ignored most of it and only used the first 16 characters." Source: http://windows.microsoft.com/en-US/windows-live/microsoft-account-password-16-characters http://windows.microsoft.com/en-US/windows-live/microsoft-ac...