Hotmail: Your password was too long, so we fixed it for you(securelist.com)
securelist.com
Hotmail: Your password was too long, so we fixed it for you
http://www.securelist.com/en/blog/208193844/Hotmail_Your_password_was_too_long_so_we_fixed_it_for_you
52 comments
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.
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.
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.
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...
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...
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.
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)
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)
Hotmail doesn't store any passwords, it is all centralized as part of Windows Live ID (Passport).
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.
^ Yes, this is exactly how I've solved this problem in the past. A slow user driven migration.
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.
It just seems they are being more explicit about it now. It is quite an odd decision to make though.
> 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
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
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.
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.
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);
Actually, if this is the case, then it seems reasonable as a transitional step towards actually allowing longer than 16 character passwords. This way users will start entering the 16 characters of the password that is hashed (hopefully) and stored, then users won't enter their longer truncated password when longer passwords are allowed.
However, this transitional step could be skipped with a truncated password flag that is set for all old passwords, and cleared for new passwords. Although, this would mark easier targets if the table is dumped through an SQL injection.
However, this transitional step could be skipped with a truncated password flag that is set for all old passwords, and cleared for new passwords. Although, this would mark easier targets if the table is dumped through an SQL injection.
This sounds suspiciously similar to the LM (of NTLM) password limits, http://en.wikipedia.org/wiki/NTLM#cite_ref-v1_13-0
Might make sense. Microsoft Accounts are also user accounts in Windows 8.
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.
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.
"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.
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.
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/
The 16 character limit really helps though :)
Obligatory XKCD: http://xkcd.com/936/
The 16 character limit really helps though :)
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.
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.
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.
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.
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-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.
1) UI is hard to use 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.
Oh cool, I wasn't aware of this. SSL client side certificates are not quite the same as the public key authentication done using SSH, but it seems like it could still be workable if the UI weren't so awful.
The only real concern seems to be the UI. Issue number 2 (being stolen by malware), could also easily occur with current authentication schemes (malware could steal the cookies on your machine, which would give it indefinite access to all sites you use until you change your passwords on them). All the other issues you mention are really just UI and UX problems.
Another problem is the lack of a real name. "SSL Client Side Certificates" isn't short and catchy, like OpenID or Persona.
The only real concern seems to be the UI. Issue number 2 (being stolen by malware), could also easily occur with current authentication schemes (malware could steal the cookies on your machine, which would give it indefinite access to all sites you use until you change your passwords on them). All the other issues you mention are really just UI and UX problems.
Another problem is the lack of a real name. "SSL Client Side Certificates" isn't short and catchy, like OpenID or Persona.
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?
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.
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.
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-ac...
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-ac...
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.
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.
Why does hotmail has this 16-letter limit in the first place?
I would get it 7 years ago, but now?
I would get it 7 years ago, but now?
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.
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.
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.
1. salt
2. don't allow unlimited password attempts[deleted]
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.
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.
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.
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.
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.
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.
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.)
And if it affects them financially you can count on that being forwarded their customers...
Even if they assume 100% of the liability, it's still a PAIN to deal with stuff like that.
Airlines, too. I recently had to enter an alphanumeric password at or below around 12 characters, I think.
Some companies also add so many requirements to the password that I think it does more harm than good to the entropy of it.
Some companies also add so many requirements to the password that I think it does more harm than good to the entropy of it.
I recently was forced to enter a password of not more than 8 characters as part of college applications. I was somewhat flummoxed, because the disposable password I use for applications I want to be able to forget about is nine characters. That is the lowest I have ever seen: I hope that there is noone worse.
Have you try to enter some quote in your password?
http://xkcd.com/327/
http://xkcd.com/327/
For many web services entropy isn't a big deal because they use computationally hard hashing functions and have sensible server-side limits that outright foil brute force attempts.
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.