

Hotmail: Your password was too long, so we fixed it for you - timf
http://www.securelist.com/en/blog/208193844/Hotmail_Your_password_was_too_long_so_we_fixed_it_for_you

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

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

~~~
uxp
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...](http://windows.microsoft.com/en-US/windows-
live/microsoft-account-password-16-characters)

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

~~~
uxp
> 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)

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

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

~~~
TazeTSchnitzel
Might make sense. Microsoft Accounts are also user accounts in Windows 8.

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

------
sitharus
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 :)

------
Joeri
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
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
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...](http://pilif.github.com/2008/05/why-is-nobody-using-ssl-client-
certificates/)

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.

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

------
moeffju
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?

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

------
richardkeller
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...](http://windows.microsoft.com/en-US/windows-live/microsoft-account-
password-16-characters)

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

------
runn1ng
Why does hotmail has this 16-letter limit in the first place?

I would get it 7 years ago, but now?

~~~
MichaelGG
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
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
If you are properly hashing a password, then the hash is always of a known
length, regardless of length of password.

------
ck2

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

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

~~~
jrockway
_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
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.

