Slashdot Mirror
Hotmail No Longer Accepts Long Passwords, Shortens Them For You
An anonymous reader writes "Microsoft doesn't like long passwords. In fact, the software giant not only won't let you use a really long one in Hotmail, but the company recently started prompting users to only enter the first 16 characters of their password. Let me rephrase that: if you have a password that has more than 16 characters, it will no longer work. Microsoft is making your life easier! You no longer have to input your whole password! Just put in the first 16 characters!" At least they warn you; I've run into some sites over the years that silently drop characters after an arbitrary limit.
That's enough for hotmail !!
12 letters, no special characters my ass.
No, you may not know which bank I use.
Somebody hasn't read the relevant xkcd.
greed@All_Evils:~#
Along time ago I had a 10 character password that ended with some numbers for an AOL account. I fumbled the numbers at the end of the password once, aware of such, but hit login anyway and it still let me in. I tested and confirmed it not to care what numbers were at the end of the password. Later it was revealed that AOL was just making a Hash of the first 8 characters of the users password, so it really didn't matter what you entered past the 8th char because it would be trimmed before computing the hash....
Umm, TFA says that Hotmail has never accepted passwords longer than 16 characters - it used to silently truncate them. The only thing that's changed is that Hotmail is now letting you know that it's truncating the password.
Well, in the Bad Old Days, Unix passwords could only be 8 characters, later extended to 16. Less concerned with the original scheme, more with the fact that Microsoft may be using password algorithms from the 1980s.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
RTFA and you learn that they've only been storing the first 16 characters for years, letting you type away in vain. Otherwise they'd have to produce new hashes for the "shorter" passwords that they expect users to use now. (There's no such thing as reading the first 16 digits of a hashed password).
Whenever I see any website that rejects passwords longer than X characters, I turn away and go somewhere else. My smallest password those days is 20 characters with numbers and special characters. I expect pretty much any decent website to accept those.
They're there in their room. You're on your own.
hunte
Hmm... Why wouldn't they just store a 16 char hash of whatever password you want?
Usually you only see this when someone is doing something wrong from a security standpoint.
Who in their right mind would trust anything sensitive enough to require a 16 character password to Hotmail?
Any insufficiently advanced magic is indistinguishable from technology.
As fun as it is to bash Microsoft, they're not the only ones who do this. Presumably there is some technical reason why this is done, but I am at a loss for what this would be. Would someone be able to explain to me the reason why such limits are put in place?
It seems with modern computer capability that absurdly long passwords would be trivial. The hashed password length would be the same irrelevant, so I can't see storage space as the issue. The only other idea which comes to my mind is the computational difficulty of hashing the passwords, but even that has to be trivial by today's standards, even with millions of users hitting the servers. Why not go overboard and just allow several kilobytes worth of password?
"A witty saying proves nothing." - Voltaire
As opposed to the sign-up page at Phil's Hobby Shop, which pretty much advertises that it's 936-compliant.
Most website authentication systems use a hash to store passwords. The unhashed string is formed from a salt, some unchanging record information (such as the user's username, or date of registration), and the user's plaintext password. During the hashing process, all of this gets distilled down to a fixed length string regardless of the complexity of the password. Thus, a lengthy password is not necessarily more secure than a short but sufficiently complex password. Any site worth their salt (pun intended) will lock an account after a number of failed logins anyway. The majority of compromised accounts come from successful phishing and social engineering, not from randomly guessing passwords. Now, encryption on the other hand should use a very strong and long password.
TD Bank, my current bank, has the following password requirements:
6-32 characters, no spaces, alphanumeric + the following symbols only: [list of characters removed because /. thought it was spam; it was a fairly short list, though. Didn't even include an asterisk]
Additionally, back when I signed up for online banking with them, I filled in a bunch of garbage for the security questions because security questions are just an attack vector, and I don't forget my passwords (I highly recommend KeePass for managing passwords, it's amazing).
Anyways, a few years ago I went to log in and was prompted to answer a security question. Wtf? I had to call customer service to get my security questions reset. Now, if they don't recognize the device, or every so often, in addition to password you need to answer a security question.
This means that I'm forced to either give real answers that I'll remember (and that anyone else could figure out to hijack my account), bogus answers that I can try to memorize, or garbage that I write down and hang onto.
I also recall, around 10 years ago, I was using Bank of America and they had a limit of either 12 or 16 characters on your passwords.
Of course, my email, web hosting, and even my fucking World of Warcraft use actual two-factor authentication, with phone apps that generate codes that are only good for around 30 seconds, and outside of a man-in-the-middle attack they're practically bulletproof. Why the fuck can't my online banking be as secure as them?
(The only way would be if they had anticipated such a change way back when the hashes were generated, and they generated a 16 character hash along side a full hash, and so now they are just switching which hash they use.)
That's not the only way. Another way would be that they silently dropped all characters after the 16th, then formed a hash from what was left.
Even if you as an attacker know that the user chose 2 arbitrary words out of the English language as their password (or that only two mattered), and you knew there was a space between them, and you knew the login was case-insensitive, you still have to deal with the (minimum) 29,403,847,100 possible password phrases (171,476 common-use words times 171,475 unique second words, if we ignore word duplication and obsolete words). This also assumes, of course, that the password used correct spelling and did not in any way try to obfuscate the words with replacement schemes like l33t speak.
Tell me again why it is terrible advice to use phrases?
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
My password is thus: SHA1 HMAC( PW, domain + salt ) -- Output as Base64 (where + is concatenation). I use this method because I can recreate the password at any time from anywhere. I don't rely on anyone else's password systems, I just use this simple algorithm which I can implement on any machine with the simple cryptographic primitives (hashed message authentication code, and a hash). I get a different password for each site, while using the same password everywhere. I change the salt and/or main password every so often, and only have to remember the current and last PW as I migrate to the new password as I run into sites I use.
At first I created a table within the bookmarklette that would allow me to set additional rules for passwords, limit length, use a different set of characters for the base64 output -- The hash would be filtered on a per site basis to comply with all the bullshit. I could deal with such shortcomings five or ten years ago, but not today. Synchronizing the booklmarklette defeats the purpose of using a simple algorithm. If a site won't accept something like: NzE1YWViMGQwMjU3NWRlNmI3ZDQ0NTQ0NzI4MjE3MGU5YzRlMWY3NiAgLQo= as a password then I just don't use the service.
I'll never use any Microsoft products, so I'll have to rely on others to discover: I imagine MS would simply ignore characters beyond the new limit? If not it would surely break password entry systems like my own or even saved password mechanic in all browsers... Including IE. It wouldn't surprise me if MS did break password entry for long saved passwords -- Smart folks who are security aware aren't their target audience.
They might have been only be passing the first 16 characters into the hash all along.
I swear to God...I swear to God! That is NOT how you treat your human!
Note that passwords must follow these rules:
* must be 6, 7 or 8 characters in length
* must contain at least one numeric digit
* must NOT start with a numeric digit
* must contain only lower-case alphabetic letters and numeric digits (that is no punctuation characters).
* the first three characters of your password must not be identical
* the first three characters of your password must not equal sap or pass
* the first three characters of your password and login name must not be the same
Here's your chance, hack hotmail, and get a treasure chest of emails and passwords, and subsequent Bank password reset opportunities...
Thanks, but the real opportunity was back in 1999 when they limited your password to two characters. Now those were some good times!
Even if you as an attacker know that the user chose 2 arbitrary words out of the English language as their password (or that only two mattered), and you knew there was a space between them, and you knew the login was case-insensitive, you still have to deal with the (minimum) 29,403,847,100 possible password phrases (171,476 common-use words times 171,475 unique second words, if we ignore word duplication and obsolete words). This also assumes, of course, that the password used correct spelling and did not in any way try to obfuscate the words with replacement schemes like l33t speak.
Tell me again why it is terrible advice to use phrases?
And at 100 billion guesses a second, using multiple GPU cards in a custom setup, you can test all those password in about 0.3 seconds.
0123456789ABCDEF
This is, well, stupid. I don't even know my own passwords. I have so many of them and they are so long with so many special characters that it would be impossible to keep up. I keep them in KeePass and just copy/paste them in the text box (it deletes the clipboard). Why place such a restriction on passwords when it is more important now then ever?
Any site worth their salt (pun intended) will lock an account after a number of failed logins anyway. The majority of compromised accounts come from successful phishing and social engineering, not from randomly guessing passwords.
That second fact is the reason why your first sentence is incorrect. Locking an account after a certain number of failed login attempts introduces a kind of denial of service attack on the site (at least, denying that particular user access) while not actually stopping any feasible attack vector. It's the kind of security flaw you see implemented by coders that don't really understand security. Preventing too many attempts in too short a time is a security feature. Locking an account after too many attempts is a security flaw. You might as well just give hackers an input field where they can type in the name of any legitimate user they want to lock out of a system illegitimately.
"Convictions are more dangerous enemies of truth than lies."
And at 100 billion guesses a second, using multiple GPU cards in a custom setup, you can test all those password in about 0.3 seconds.
It's remarkable when anyone has 100Mbps network to the world, you've got a large multiple of 100 Gbps, and the server actually responds with "invalid password" pages that fast?
So much for THAT strategy: http://xkcd.com/936/
The real question is how were they able to truncate your password if they used a hash?
Somebody who understands the consequences of this, please mod it up!
"Trump!!", the new Godwin.
Hmmm, I wonder what other opportunities for SQL injection there are that they don't have covered.
The question is why would you do that. Microsoft are a big enough customer to force the supplier to change their backward ways. Another more likely scenario is that they are moving from an old system that silently discarded everything above 16 characters to an unlimited system, but since old passwords only used 16 characters, they need users to only type the first 16 characters to be able to still log in.
Actually it's not that hard to "outsmart" brute-forcing - two simplistic ways are to insert a verification delay (artificial or computational depending on the situation) so that brute force attempts will generally takes months or years to succeed, or just block any attacker that makes multiple attempt faster than a human could reasonably be expected to. Even a really lax limit like blocking an attacking IP for a day after five failed attempts in a minute will block upwards of 90% of brute-force attempts and probably won't effect legitimate users at all.
Think of it as somewhat analogous to being the doorman at a speakeasy or illegal gamblng joint - you know, the guy in the movies that spends all night opening the tiny window and saying "Password?". It not exactly hard for him to tell when someone is just repeatedly knocking on the door and guessing wildly and politely ask him to leave while they still only have a few broken ribs.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
We understand what he means, but if you did not read the update here you go
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. When we changed “Windows Live ID” to “Microsoft account,” we also updated the sign-in page to let you know that only the first 16 characters of your password are necessary. To avoid this error message in the future, you only need to enter the first 16 characters of your password.
> If the server or isp supports ip6, the attacker just needs a home that can use 100000000000 IP addresses, and on ip6 is easy.
All with the same /64 or, if you're lucky, a /60 or /56 prefix.
For my own CMS, I do ratelimits on /56 and /24 subnets. I track the hostmask on ipv6 for things like logins, but that's largely just because it's there.It's about as useful and relevant to me as your connecting port. And don't expect a site owner to treat it as any more unique.
Adult Role Playing Forum
At least they warn you; I've run into some sites over the years that silently drop characters after an arbitrary limit.
I was here when Slashdot truncated our usernames after an arbitrary limit. I was originally "Lord Kano - The Gangster Of Love", then one day I log in and my username was shortened to "Lord Kano - The Gang" or some such. I had to get Taco to shorten it to its current form. That was a pain in the ass.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
PS: the password field itself allows more than 16 chars, but if you enter more characters, when you try to login you get back a message telling you that the password is wrong. I can only login if i enter ONLY the first 16 chars.
root@127.0.0.1
That's enough for hotmail !!
An AC makes a reasonable on topic first post with a more or less accurate entropy count (note that both sexconker and Immerman's posts are right; since most users will get a-z with first letter capitalized and a single numerical substiution you get about 26 variations per character + 2 bits for the substitution that gets you less than five bits per character; of course if you use a password safe then you can use A-Za-z1-9 + about 20 - 30 punctuation characters depending on your keyboard, for about 90 characters giving you just over six bits). The only possible explanation that it gets modded to zero immediately is that it's anti-Microsoft and the shills are out with their large number of mod points as ever.
Now, for the next trick. If you store passwords as a hash, as you are supposed to, then there is no way to shorten them since without the end of the password you won't be able to make the hash match. This means that at least somewhere Hotmail is storing passwords in plaintext. That's actually a much worse breach than having limited passwords since there is no way for the user to overcome it.
AC's post was excellently insightful. It should be modded back up to infinity.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Not really, you simply assume a /64 is the equivalent of a single ipv4...
It also makes other forms of attacks much harder, for instance with ipv4 it is common to scan a whole ip range looking for vulnerable hosts, with ipv6 this becomes completely impractical.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If you can make 100 billion incorrect guesses in a second to a remote webpage, there's really only two things to say:
1. I want your internet connection.
2. Password strength is not the critical flaw of that particular site - rather they should look into some way of not letting people try 100 billion passwords in a second without getting delayed/locked out.
It's feasible that the first time you log in since this was introduced that if the password validates then it gets truncated and the has based on the first 16 characters is stored.
Once that's done any future password could be truncated to 16 and compared with the new hash based on the first 16...
That way you can safely transition from one for to another without passwords stored in plain text.
It's been trimming password to the first 16 chars for a while now. I only found out because Messenger only allows 16 chars in the password field, and when I would paste from KeePass my (longer) password I had set in the website, I'd get a beep.
The hashing algorithm they use might have collisions past 16 characters anyway, so you'd get no added security out of extra characters, and you only hash and handle the hash from the first 16 characters.
A 128 bit hash doesn't have collision. In theory it can, if the hash function is cracked then collisions can be created, but in practice there are just no collisions. And there are plenty of devices (iPhone for example), where using lots of digits, upper/lowercase etc. makes the password impractical to enter, so I'd rather use a long (>16 chars) of lowercase characters and rely on length to produce bits.
Often it's due to single sign on, and it has to work on 100 different legacy systems. But yes, I've been told one place to set my password to 6 alpha characters and 2 numbers. I have no idea what would or wouldn't work, and the combinations I tried matching the published rules didn't work, but adopting the 6+2 scheme generated a valid password. Because of the 60 day pwd expiration, and no repeats in the last 12 passwords, everyone does 6 alpha in lower case, and numbers 1-12, rotated. It is roughly as secure as just 6 chars and no numbers, but no, we have to have the numbers and the short-ish expiration. I am of the opinion that expiring passwords leads to less password re-use, but less password entropy as well. For where that tradeoff gets us for security, I have no idea.
Learn to love Alaska
Deliberately naming names to indict the guilty... :-|
Bendigo Bank here in Australia truncates your password to just 8 characters, and like several other banks that I have come across, it also disallows punctuation or whitespace characters. So just enough characters to spell "FuckMeUp".
At least they do have the grace to offer one-time-key widgets, (FWIW), at a price...
Assuming a perfectly distributed hash for the purpose, and that your passwords have 64 valid letters, and your password hashes are the equivalent of a 16 byte string, you are guaranteed to have more than one password string that hashes to the same hash string - 256^16 < 64^22. There may be passwords with no collisions, you cannot say that all passwords would have not collisions.
Parent may have been assuming that the password box allowed any ascii character, in which case 256^16 < 256^(16+n) (where n > 0), which would also guarantee that at least some hashes would have colliding passwords.
If the hash is hex encoded and only takes up 16 characters in that state, then it gets even worse.
Can you be Even More Awesome?!