Hotmail No Longer Accepts Long Passwords, Shortens Them For You 497
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.
16 x 5 bits = 80 BIT !! (Score:5, Funny)
That's enough for hotmail !!
Re: (Score:2, Informative)
Where in the hell do you get 5 bits from?
A-Za-z alone gets you past that (52), add in 0-9 and some symbols and you'll be well past 64 (2^6).
My KeePass database lists my Hotmail address's password as having 99 bits of entropy.
Re: (Score:3)
Fair argument, AC probably just miscounted, they were only off by one after all. On the other hand if you assume a non-random character distribution the actual bits-per-character are considerably lower - for example even a very crude non-predictive Huffman coding of the english language reduces common characters to three bits or less, more efficient encodings can reduce that even farther, I could see the average easily falling below 5 bits, and quite possibly below 4, even after factoring in the mangling t
Re:16 x 5 bits = 80 BIT !! (Score:4, Funny)
Where in the hell do you get 5 bits from?
It's the old Baudot code [wikipedia.org] young whippersnapper. Haven't you ever used TTYs or paper tape writer/readers?
Get off my lawn!
That's nothing; think how they store the passwords (Score:5, Insightful)
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.
Re:That's nothing; think how they store the passwo (Score:5, Insightful)
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.
Re: (Score:3)
Re:16 x 5 bits = 80 BIT !! (Score:4, Funny)
"16 chars ought to be enough for anyone"
Hah! Take that, my bank! (Score:2, Interesting)
12 letters, no special characters my ass.
No, you may not know which bank I use.
Re:Hah! Take that, my bank! (Score:5, Interesting)
At least they warn you; I've run into some sites over the years that silently drop characters after an arbitrary limit.
Nah, they'd never do that at a reputable large financial institution... like, say, www.americanexpress.com
Maybe they somehow figured out how to make money from handling fraud claims?
Re:Hah! Take that, my bank! (Score:4, Interesting)
Stupid as this whole thing is, Microsoft does make one good point.
With the ease of phishing and harvesting passwords from other services where the user has used the same one.. who is gonna bother brute forcing a password.
It's like if your car has a notoriously easy to pick lock.. but you park in a parking lot where no one else even bothers locking theirs (and some have even had their doors removed for even more convenience..)
Re: (Score:2)
Re:Hah! Take that, my bank! (Score:4, Interesting)
It's kind of a back and forth game..
You can't outright block access to an account after a certain number of tries because that creates an easy way to denial of service (someone can lock you out of your account just by entering a few bogus passwords). So you either block after a certain number of failed attempts (at which point botnets come into play) or install a captcha (at which point standard spam-level anti-captcha stuff comes into play.
But my original point was that there are so many much easier ways to get accounts, why is anyone going to go through all that trouble.
There is an argument for brute forcing when someone has broken into a server and stolen a list of hashed passwords (as then they can crank away at them all they want) so limiting to 16 chars kinda makes that a bit easier.. but I still think given hotmails user base they could easily just check against hashes for "password123" and get more than enough hits to make it not worth going further...
Re:Hah! Take that, my bank! (Score:5, Insightful)
Re:Hah! Take that, my bank! (Score:5, Insightful)
Exactly. The fact that they can do this practically screams "We haven't bothered to implement even the most basic security precautions on our password database!" I mean come on - wasn't it established that storing recoverable passwords was a bad idea back in the text-only mainframe days? I could kind of understand it if it was some backwater site created by a high-school computer wiz, but Microsoft? Sigh. Yeah *sure* I'll trust your security software to keep my home PC safe - after all you're the company that did such a great job on the OS itself that running separate security software is practically mandatory.
Re:Hah! Take that, my bank! (Score:5, Insightful)
The real question is how were they able to truncate your password if they used a hash?
Maybe they always truncated the password, just didn't tell you.
Re: (Score:3)
That was my first question too.
A proper hash setup should flag only part of a password as wrong with no way of knowing if you were close or not. This is clearly screwed up. Either the hash is deliberately weak, or some idiot admin cracked the whole damn table and made it just 16 characters ... Which is even WORSE!
Re: (Score:3)
There is a way to do it securely (well as secure are max 16 char passwords are).
1. Collect plaintext from the user
2. hash the plaintext and validate against the old password db
3. If success, then truncate the plain text and store the new hash.
4. overwrite the old hash with some flag value, like say all NULLs
5. Wait until the old password database is all NULL and dump it.
Re:if they used a hash...? (Score:5, Informative)
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.
Re:if they used a hash...? (Score:4, Interesting)
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.
Re:if they used a hash...? (Score:4)
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.
Re: (Score:3)
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
Re: (Score:3)
If you block access to an account, you create a denial of service opportunity. The idea of account lockouts is thus utterly ridiculous.
And you do nothing to someone who takes the opposite approach - try thousands of accounts with a single password (where on a system as large as hotmail, someone will have "Password1" or similar.
Instead you really should block the source address of any obvious attacks, which while obviously not perfect (botnets, proxies etc) is at least moderately more effective.
Easy-stop on brute forcing (Score:5, Interesting)
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.
Re: (Score:3)
> 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.
Re: (Score:3)
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.
Re:Hah! Take that, my bank! (Score:5, Interesting)
> Nah, they'd never do that at a reputable large financial institution... like, say, www.americanexpress.com
Yeah. As you probably know, when you activate an AmEx corporate card, they require you to create a pin, and the voicemail says to use something you will remember, like the month/day of your mom's birthday.
The automated system will actually REJECT a pin that is not a valid month/day. (Well cool. 366 total possibilities. That's not easy to brute-force at all.) I futzed with the system until I got a real person, and insisted I wanted to use a randomly generated number instead (which didn't happen to be a valid month/day). He said he couldn't do that, it had to be a date. He asked me for my mom's birthday and said he would set it to that. (My theory is that they do this to cut down on service calls.) I pointed out that this string could be uncovered by anyone with facebook access. He said that this is what it had to be. I went over his head. Eventually I found someone with the authority to set the pin to a string of my choosing. As far as I know, I'm the only AmEx card holder who has a pin set to something other than the customer's mother's birthday.
This information (that AmEx has this requirement), could be of huge use to phishers were it ever, you know, published in a public forum.
Re:Hah! Take that, my bank! (Score:4, Funny)
I'll bet that their db servers and Windows domain passwords are "sa" and "admin" as well.
Re: (Score:3)
Oh sure. After I finished trying all 366 possible numbers you tell everyone your pin isn't a date! Just for that I'm going to rob someone else.
Re:Hah! Take that, my bank! (Score:4, Interesting)
americanexpress was the worst, the 'Set password' page input field was limited to the maximum number of characters however the 'Login' page was not.
So if my password is: 'myreallylongpassword', it would appear accept my password. But it would be only only use 'myreallylong' as input.
When I go to login and enter 'myreallylongpassword' it took the whole password as input and denied me access, since it didn't equal to 'myreallylong'.
I went through quite a few password resets before I figured this out.
Re: (Score:3)
How do they even do that?
Anyone doing a password system is going to take the input string and hash it. Hashes always come out with the same length (for a given algorithm, at least), so there's no reason to have *any* limit on password length. And even if you truncate it on entry, why would you not either warn the user (as Wachovia did back when I used them, with their 9-12 character passwords only), or at least truncate on password check as well.
The only logical explanation is that they're storing passwords
Re: (Score:2)
12 letters, no special characters my ass.
No, you may not know which bank I use.
Sounds like Bank of America. At least they let you use a mix of upper and lower case and numbers.
Re: (Score:3)
You've a pretty good bank. I've three bank accounts:
1) 4 digits (yes, numeric only), account disabled after ONE failed attempt (need to re-enable it at an ATM).
2) 8 letters/numbers, need to change it every 90days. Can't repeat old passwords.
3) 4 digits, and the username is "secret" too. If you fail to log in 3 times, your account is disabled and you need to pick a new password AND username.
While the latter offers a wierd but somewhat better form of security than the rest, you can be pretty sure that 12 l
Re:Hah! Take that, my bank! (Score:4, Interesting)
The only Australian bank that I use has the following setup-
Login: Primary Account Number
Password: 5 characters, A-Z 0-9 (no lower case)
Account locks after 3 incorrect attempts.
As a measure against the key-logger, the password is entered by clicking on a virtual keyboard which repositions itself on the screen randomly after each click.
Can not login without Javascript enabled. This measure is useless on mobile devices though as the virtual keyboard fills the entire screen and thus can not be repositioned. If an attacker found a chink in the armour that would allow multiple password attempts without locking the account (likely, as this appears to be done in script), a brute-force will likely succeed in a very short amount of time.
On the plus-side, I am informed of ALL login attempts and transactions via SMS and must login and enter a one-time-pad to authorize larger transactions. I am also given the previous login time and date upon login and a separate code is required to add a new payee or for overseas transfers.
Clearly (Score:2, Informative)
Somebody hasn't read the relevant xkcd.
Re: (Score:3, Informative)
http://xkcd.com/936/
As opposed to... (Score:5, Interesting)
Re:Clearly (Score:5, Interesting)
I've posted about this in the past http://slashdot.org/comments.pl?sid=3001279&cid=40757735 [slashdot.org]
Re: (Score:3)
Re:Clearly (Score:5, Interesting)
You are not the only one, and that's sad.
While the comic has a pretty poor explanation, the theory is sound: A four-word phrase offers more options (and therefore more protection against a brute-force attack) than an 8-character password, for even a very small dictionary. In fact, the number of options is so drastically larger that it more than compensates for any alterations to the password, like adding numbers or misspelling.
Of course, the number of options is expanded even further when the password may not actually be a phrase. Maybe the password is really just a 30-digit section of pi. An attacker must try that (and every other number combination) too, so the brute-force strength of a long phrase password is still higher than a shorter random password.
For a comic, the strip is perfectly valid. A longer (though simpler) password is vastly stronger against brute-force attacks than a shorter one, even though the shorter one looks weirder.
Note, though, that the strip does not account for attacks other than brute-force, but phrases are still usually better. An attacker physically standing in your office will quickly recognize that a jumbled mess of letters and punctuation taped to your monitor is a password, but an obscure quote attributed to someone he's never heard of is just another office decoration. Even against phishing attacks or plaintext storage hacks, a long phrase is no less secure than a shorter password, since it's not the password that's being attacked.
AOL Used to.... (Score:4, Interesting)
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....
Re:AOL Used to.... (Score:4, Insightful)
UNIX operating systems used to do that, too. This was happening as recently as early releases of OSX. Only eight characters of passwords were significant.
Re: (Score:3)
It's largely pointless anyway, because the windows networking protocols let you authenticate just using the hash (yes even today with lanman turned off)...
Ummm, nothing new here.... (Score:5, Informative)
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.
Huh. (Score:5, Informative)
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.
Re: (Score:2)
I definitely ran into a problem with this under an early BSD. Entered a longer password, entered it a second time, they matched, it was accepted. Then I could no longer log in the next day. Reset password and try again. Then the next day same problem. Eventually it was figured out and the admin patched a file and fixed it.
I think there was also a problem for awhile with user names where additional letters were ignored by some tools.
How were they storing the passwords before? (Score:5, Informative)
Re: (Score:3, Interesting)
From TFA:
[...] this can only mean one of two things, according to Kaspersky:
Store full plaintext passwords in their database and then compare the first 16 chars only.
Calculate the hash only on the first 16 and ignore the rest.
I’m fairly certain Microsoft isn’t stupid enough to go with the first option. Storing passwords in clear text would be a disaster,
I wouldn't doubt for a second that MS would go with the first option. They are, after all, competing with Yahoo [cnn.com] :-) Also, wasn't it Microsoft that came up with the oxymoronical term "reversible encryption"?
On the other hand, Hotmail was originally built on FreeBSD by non-MS types, so who knows? To this day I still find it amusing to think of all the difficulty they must have had porting the platform to Windows.
Re:How were they storing the passwords before? (Score:5, Insightful)
Also, wasn't it Microsoft that came up with the oxymoronical term "reversible encryption"?
You're perhaps thinking of hashing. Reversibility is pretty much a requirement for encryption.
Re:How were they storing the passwords before? (Score:4, Insightful)
When this happens... (Score:2)
Re:When this happens... (Score:5, Insightful)
The question that should be asked is, "What's a 'Special Character' and why shouldn't it be allowed in a password?"
I had this argument with a developer the other day.
Him: "What characters should be allowed in this text field?"
Me: "Um, How about all of them, at least the printable ones."
Him: "What about special characters?"
Me: "Give me an example."
Him: "The ! sign"
Me: "What's so special about that? I can type it? I use it at the end of some sentences when I'm angry. Why would you not allow it?"
Him: "What about non-latin characters?"
Me: "What, are they special too?"
Him: "You need to specify a list of every character that is allowed in the text field, otherwise I cannot program it."
Me: [Facepalm]
etc..
There doesn't seem to be any compelling security reason to exclude certain characters from eligibility for use in a password.
Re: (Score:3)
If you are using various devices to login with.
Sure, your normal keyboard may have an unusual keystroke that yields .
But, other OSs, or key maps are unlikely to either support the requisite keystroke ('But my phone doesn't even have alt-gr") or it is going to be in a place only findable With extreme effort.
Re:When this happens... (Score:5, Interesting)
Him: "You need to specify a list of every character that is allowed in the text field, otherwise I cannot program it." Me: [Facepalm]
The developer is right. You are trying to enforce an ambiguous requirement. "All of them, at least the printable ones" is not specific. "Printable" assumes a font. In the symbol font (as found on Winders) there are a lot of "printable" characters that don't show up on a keyboard. Since they are mapped into the same binary values, how do you differentiate?
"My password has a an "upside down A" but you are accepting a double quote and letting me log in. It's broke!"
This is not a trivial issue. It appears that someone has had the same kind of conversation with some web developers regarding proper email addresses.
Him: "What characters should be allowed in an email address?"
Boss: "Anything that is in an email address."
Him: "Hmmm, ok, all I've ever seen are A-Za-z0-9.- and one '@'. That's what I'll code.
Me: "Hey, your website it broken, it doesn't accept valid email addresses! Don't you idiots bother to read the RFC for internet messaging when you program this stuff?"
Him: "It works fine with my address."
Me: "It's broken AND HERE IS HOW TO CHANGE THE JAVASCRIPT CODE TO FIX IT."
Him: "How did you get ahold of our proprietary javascript code?"
Do you see the problem?
Re: (Score:3)
Arguably, the designation "printable character" does not imply a font at all. What the symbol font has is glyphs, which map to character code points -- ones that are already defined to mean something different and printable. "Printable" is more a property of the character (code point) and not of the glyph. Fortunately, there's this whole Unicode thing that (a) is a widely-accepted standard with easily-obtained libraries, (b) is supported by web browsers, Windows, Mac OS, etc., (c) will tell you if a charact
Re:When this happens... (Score:4, Informative)
Look at an ASCII table sometime.
The first 0x20 characters, plus 0x7F, are "non-printable" or "control" characters, having no visual representation in any "standard" font, instead having some effect on the system - NUL, start-of-header, start-of-text, end-of-text, enquiry, acknowledge, bell, backspace, tab, line feed, vertical tab, form feed, carriage return, shift out, shift in, data link escape, device codes 1-4, and a few others I can't remember. The other 0x5F are "printable" - they actually show some character on the screen. That includes everything from space to ~, literally.
Those are official terms. ISO encodings and Unicode add more printing and non-printing characters, but they all have the same base. And I suppose EBCDIC has its own set of control characters, incompatible with ASCII et al (although if you're basing your password system on "what EBCIDIC allows", you fail on at least a dozen levels already).
Re: (Score:3)
Re:When this happens... (Score:4, Informative)
you open up the crypto library on your system as a potential attack vector.
If your crypto library cannot hash an arbitrarily-long string of arbitrary binary data, then it's a very bad crypto library. Or, more likely, you are using it stupidly.
Re: (Score:3)
Really that's plenty - uppercase, lowercase, and numbers = 62 states per digit, or roughly 6 bits. To add just one more bit per character would require another 64 characters worth of punctuation and special characters - at that point you're making it dramatically more difficult to remember and type your password without actually increasing the security substantially - adding a couple more characters will be just as secure while being a lot easier to enter.
Let's give this a shot (Score:4, Funny)
hunte
Hash???? (Score:2)
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.
So? (Score:5, Insightful)
Why have such short limits? (Score:5, Interesting)
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?
Re: (Score:3)
Commenting here, as my finger slipped and I wrongly modded this as Troll. Gosh, I am a human, give me an option to remoderate my miskates, you silly slashdot!
Re:Why have such short limits? (Score:5, Interesting)
Every time I see any kind of password length limit somewhere, I instinctively know that somewhere behind the scenes there is this table column:
user_password VARCHAR(16) NOT NULL
It's the same sinking feeling I get when I see the "the following special characters cannot be used in the password field" error message, which just tells me immediately that the code that submits the password field looks like:
$cmd = "UPDATE ... user_password='" + $password + "' ... "
There really, really needs to be a "guild of programmers" or somesuch, along the lines of the Bar Association, so that anybody who writes code like the above can be summarily ejected from it.
Re: (Score:2)
Re: (Score:2)
Because people don't think. That is all.
Seriously, the people who design the web UI front end and the people who save the data to the databases on the back end are not security experts. They probably just thought "ok, gotta reserve space for a field, I think 16 characters is enough" and that was the end of the thinking process.
Re: (Score:3)
Re: (Score:3)
Most sites (don't know about hotmail for sure) only let you enter alphanumeric characters. That's 26 (lower case) + 26 (upper case) + 10 (digits) = 62 characters, or about 6 bits of entropy per 8-bit byte.
For a 160-bit hash like SHA-1, that's 26 characters.
For a 256-bit hash like SHA-256 or GOST, that's 42 characters.
For a 512-bit hash like SHA-512 or Whirlpool, that's 85 characters.
No secure hash (by the current standards) would limit the password space to 16 characters (that would be a 96-bit hash, rough
Shortens password? (Score:2)
Does this mean they were storing the passwords in cleartext? In a real system they would simply be storing the hashes, shortening the password would cause it to create a different hash and not match.
Re: (Score:2)
Does this mean they were storing the passwords in cleartext? In a real system they would simply be storing the hashes
I'm under the impression that they hash it after chopping off everything after 16 characters. Perhaps it's easiest to express in PHP: $hash = sha1(substr($password, 0, 16));
Slashdot has a limit to (Score:2)
Re: (Score:3)
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
Re: (Score:3)
Hmmm, I wonder what other opportunities for SQL injection there are that they don't have covered.
Re:Slashdot has a limit to (Score:4, Interesting)
Banks just as bad (Score:4, Interesting)
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?
Re: (Score:3)
At least... (Score:2)
At least you don't need to use your real name.
I generate my passwords (Score:5, Interesting)
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.
Re: (Score:3)
> SHA1 HMAC( PW, domain + salt ) -- Output as Base64 (where + is concatenation).
Interesting! So as long as the attacker does not have access to your local machine, you have more protection. (your password couls still be known for a single site, but could not be used elsewhere, does nto give away your 'formula' for passwords (like ending it with the site name, etc).
Do you have this integrated with keepass or something? This should be a desktop tool, hosted on github.
Re: (Score:3)
I used to do this, but it fails miserably on sites that require you to change your password, or when they redesign and redirect you to their "secure" domain to log in, or where they have multiple domains that share an account. I found I was spending too much time fighting edge cases, so I caved in and went for LastPass (which I consider adequate since it encrypts on my end). No regrets.
False value plus what the hash? (Score:2)
So MS is faced with one of three expensive situations:
They weren't hashing but storing my pass in some open or reversible format which when hacked will create a mega PR / liability problem or,
Two-factor or stay home. (Score:2)
In this age of ubiquitous spyware and key loggers passwords are pointless. Two factor security or don't trust anything important to a system.
My passwords for things are simple, but I only trust important data to to factor. I just assume anything only password protected is compromised.
WTF?! (Score:2)
Could someone explain how this would be even possible to pull off in the first place unless our passwords were stored in plaintext?
Last time I checked, you couldn't truncate a password like this after it's already been hashed.
Microsoft, shame on you.
Re: (Score:3)
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.
But the first 16 characers of my password are (Score:3)
0123456789ABCDEF
I don't even know my own passwords (Score:4, Insightful)
correct horse battery staple (Score:3)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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 atte
Re: (Score:2)
Rainbow tables are used for attacking hashed passwords. They are a reverse dictionary of hashes back to plaintext passwords.
These hotmail passwords are obviously stored in clear text, otherwise how would they be able to just chop them at 16 characters?
(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.)
So if you gain access to Hotmail's pass
Re: (Score:3)
(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.
Re: (Score:2)
These hotmail passwords are obviously stored in clear text, otherwise how would they be able to just chop them at 16 characters?
they've always been chopping them. they are chopped before they go into the hash function. they haven't changed anything, they are just now letting you know what they are doing.
Re:You need more than 16 char (Score:5, Informative)
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 [oxforddictionaries.com] 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?
Re: (Score:3)
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 [oxforddictionaries.com] 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.
Re: (Score:3)
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?
Re:You need more than 16 char (Score:4)
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.
Re: (Score:3)
They might have been only be passing the first 16 characters into the hash all along.
Re: (Score:3)
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 [wikipedia.org]. Now those were some good times!
Re: (Score:2)
it could mean that. but it could also mean they've always been truncating them from day one, and they are now just letting you know.