Hotmail: Your password was too long, so we fixed it for you
securelist.com
securelist.com
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.
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 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...
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.
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)
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
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.
struct user_auth
{
char username[64];
char pw[16]; // TODO: Allow longer passwords
//...
};
bool authenticate_user(user_auth* ua);
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.
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.
Obligatory XKCD: http://xkcd.com/936/
The 16 character limit really helps though :)
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.
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.
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.
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.
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.
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...
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.
I would get it 7 years ago, but now?
Now as to why someone chose 16 characters 10+ years ago... who knows. But having such a limitation roll forward isn't that mysterious.
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.
1. salt
2. don't allow unlimited password attemptsThen 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.
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.
Some companies also add so many requirements to the password that I think it does more harm than good to the entropy of it.