What do you mean password strength does not rely on length?
A longer password is MANY MANY MANY more times more secure than a complex one.
http://xkcd.com/936/
Microsoft has come in for a bit of stick in security circles for only allowing a 16-character password for sign-ups to Outlook.com, Redmond's newly launched Gmail rival. The service – which has already attracted more than a million sign-ups – has a maximum password length of 16 characters, the same as Hotmail.com and Windows …
I got a spam email yesterday in my new outlook.com email inbox - it said...
"Worried, embarrassed, ashamed of the length of your password? Your password length fails to impress her? Feeling inadequate next to that fat nerdy dude in the IT office?....." etc
Then it went on trying to flog me "herbal password extenders!"
"The length of a password is less important than its strength, which depends on whether the login credential uses a mix of letter, numbers and non-alphanumeric characters (good) or words that might be found in a dictionary (terrible)"
The length of the password is in fact much, much more important to its strength than whether it uses non-alphanumeric characters and such like. See for example http://xkcd.com/936/.
It's pretty easy to see why length is so much more important than the characters you choose -- the number of possible passwords is exponential in the length of the password, but only polynomial in the size of the alphabet you're drawing from.
Or if you get a failed login for a particular e-mail address, simple deny all logins from that source IP for say, five seconds. Hardly a great inconvience to a genuine user making a typo on the password, but makes a remote "dictionary attack" (where the dictionary including all combinations of upper, lower case and digits) of even an eight-character password unfeasible.
Granted, if someone gets hold of the underlying password database, and so can circumvent the connection and time restrictions imposed when connecting remotely, then the shorter passwords are now much weaker than longer ones.
<quote src=Graham 24>[...]simple deny all logins from that source IP for say, five seconds. Hardly a great inconvience to a genuine user making a typo on the password, but makes a remote "dictionary attack" (where the dictionary including all combinations of upper, lower case and digits) of even an eight-character password unfeasible.[...]</quote>
these days it's a lot easier to do DISTRIBUTED dictionary attacks or port/vulnerability scans, denying logins from a particular ip address or address range is meaningless.
It's better to deny logins globally to that account for x seconds/minutes and after that to add a mandatory captcha to the login for the next few hours. I've even seen servers that always ask for captcha on logins (i configure mine this way too.).
https://www.google.com/search?q=distributed+dictionary+attack
https://www.google.com/search?q=distributed+port+scan
"denying logins from a particular ip address or address range is meaningless."
It's there to preveny denial of service attacks against a single account.
"It's better to deny logins globally to that account for x seconds/minutes ".
If you do that, all I have to do is to log in as you with an incorrect password every few seconds, and you can never access your account. If you limit the lock out to the IP addresses that originated the failed login, the legitimate user can still get access.
"If you limit the lock out to the IP addresses that originated the failed login, the legitimate user can still get access."
or, you could do it the other way round: deny login attempts from any IP that has not previously successfully logged in to that account.
Either way you need to store _some_ IP addresses, the list of previously-successful IPs is likely to be much shorter than the list of DDOSing failed login sources.
If the hash is shorter than the passwords, does it not imply that more than one password must have the same hash? And therefore that one need only find A working password and not THE original password? Not my field, so please enlighten me if I'm missing something.
Yes, in hashes this is called a collision. When two or more plaintext items result in the same ciphertext (hash). The goal of hashes is usually not to eliminate all collisions (because it is impossible), but rather to make them as difficult as possible to generate and figure out without brute forcing through every single possible combination.
This post has been deleted by its author
This post has been deleted by its author
To all: I think my math is OK here, but pls forgive me. I didn't use billion, as the meaning changes depending what side of the Atlantic you're on.
AC: I don't think you understand just how large a 128-bit number is, let alone a 256-bit number. 128 bits works out to around 3.40 × 10^38 different numbers.
Humor me here: Fit 3 x 10^11 (three hundred thousand million) hashes in a cubic millimetre...
A desktop HDD has an outside volume of 386,022 mm^3. At the same storage density as above, the HDD would have to be able to store 115,806,600,000,000,000 128-bit hashes or 1,852,905,600,000,000,000 bytes (1.9 million petabytes - 1.9 zettabytes) of data to match the storage density of that cubic mm above.
To visualize just how much data that is, think how big a pile nearly two million million 1TB drives would be. The annual HDD production of any sized-storage by the three largest manufacturers is 200M - so that'd be 10,000 years' production.
Last year, IBM announced that it is building a 120 PB HDD data repository - an array of 200,000 HDDs. That 1.8ZB HDD would represent 15,834 of IBM's arrays.
The volume of the Earth is roughly 1.097 x 10^27 mm^3. That's a thousand million million million million.
A planet-Earth-sized pile of 1.8ZB HDDs would be needed just to store all possible 128-bit hashes. (Seagate expects to use HAMR to produce 60 TB+ 3.5" hard drives within the next ten years - you'd still need 31,666 of 'em for ONE 1.9 ZB HDD.)
At current rates of manufacturing, you would need every HDD produced for 2.6 x 10^21 years just to store all possible 128-bit hashes. That's 1.8 x 10^11 times the age of the universe...
Oh, it gets worse, AC.
To store all possible 256-bit hashes, you would need 3.40 × 10^38 Earth-size piles of 1.9 ZB HDDs.
THAT, my friend, is sufficiently large haystack to hide a needle in.
Password hashing IS good practice. Best practice is salted hashing, with individual, random salts (assuming the salts aren't stored with the hashes) and a slow, or a memory-intensive hashing algorithm.
"I don't think you understand just how large a 128-bit number is"
I do understand that thank you, it's eight times wider than the 16bit numbers I grew up with, but I need some help understanding why anyone would think it's relevant in the context of a "discussion" re hashed passwords.
Outlook.com fails on a lot of important features besides password length.
Two factor authentication and IMAP are two very big ones. The problem with MS is they have a very strong culture of not invented here. For example, the outlook.com team recently had an AMA (ask me anything) on reddit and the constantly repeated question of "why don't you support IMAP, we want IMAP" was repeatedly responded with a cookie cutter meaningless response typically with "we support exchange active sync" much to the derision and face palming of redditors.
MS outlook.com simply cannot compete with gmail, they're out of touch with what people actually want versus what they think people should use/have.
I signed up for an account but was disappointed with both lack of IMAP and mobile support. Every email provider I use has a mobile webpage for speedy access but somehow outlook's doesn't work properly. Try m.outlook.com and it will initially open a mobile-looking outlook site but quickly re-direct you to the full website.
I use easily remembered passphrases and these are parsed by a little (very well protected -only root readable) C program that swaps letters around, adds fixed characters, pads, adds different numbers to some characters etc. so that a simple passphrase like "Ballmer is a bum" comes out as (something) like :-
ttxbv34jb21Mxsm1FncZpp
Just copy/paste. Anyone see a problem ?.
This is only for the really important ones such as finance or SSH where I think it's worth putting in a little effort. Even if someone gets local access to the computer and knows about my system they'd still have to know the passphrases ( I don't use MYBanksPassword etc. !)
Yes longer passwords are most certainly more secure but the geeks always overlook the user factor & they really believe people are going to use more characters than they have in their own name.
Its never going to happen that non-professional computer users use security best practices. NEVER going to happen.
The big rub is that major providers of software & hardware try to implement security for "the masses" but the loud voices of IT folks online scream & cry privacy issues so loud they push the providers into a half-cocked system. So thanks Sophos I guess. You've just provided another avenue for biometrics asshats to get involved.
Thanks again.
Strength is an exponential function of a password's length.
*Even if you throw together 5 random unrelated dictionary words, you still have ~ 200,000^5 possibilities.
320,000,000,000,000,000,000,000,000
An 8 letter password using a-zA-Z and punctuation is ~ 64^8 possibilities.
281,474,976,710,656
It would take 1136868377216 times as long to crack the password based on dictionary words using a brute force attack.
Clearly long passwords using just dictionary words are vastly more memorable and secure than 8 letter passwords composed of random characters.
The statement is at best misleading, though I'd go with just plain wrong.
*Assuming 200,000 dictionary words, OED estimates a quarter of a million not including inflections
"Clearly long passwords using just dictionary words are vastly more memorable and secure than 8 letter passwords composed of random characters."
Might be true but most people don't know what many of the 200k words in the English dictionary mean. Most people have a working vocabulary of about 5000 words. I'm pretty much prepared to bet that if you asked most people for 5 random words you would get 5000^5 ~= 10^18 bits of entropy at most. So I reckon you're out by a factor of 100 million or so in you estimate.
You're still better off with this than 8 characters though.
Ok, I never stated 'generated by a human', I was assuming a computer would generate both the random words and password, because humans are frankly shite when it comes to generating random sequences of anything.
Even 5000^5 is more than 64^8. That's ignoring the fact that a normal human vocabulary is *50,000 words (and we're still not including inflections). So your argument fails even on it's own rather suspect numbers.
*source: BBC http://news.bbc.co.uk/2/hi/uk_news/magazine/8013859.stm
This post has been deleted by its author
Wow, I can see you didn't read my post before hitting the downvote button. It actually agrees that 5000^5 is still better than 64^8. It's just a note of caution that the xkcd 'correct horse battery staple' entropy is often overestimated. I'd normally be interested to know why you think my 'argument fails even on it's own rather suspect numbers' but the fact you couldn't even read and comprehend this short post tells me all I need to know.
It's funny this exact issue is how come I one day went into an interview for a junior developer role at a medium sized firm in Norwich and came out as their Head of Security.
They were using an aging in-house order system which required all employees change their password every 90 days. The problem was there were no proper constraints on password length or complexity and they had discovered employees were using twatish passwords like "123" and even " " (a single space!). They wanted me to join their developer team in a project to add proper password constraints to the system. I looked them in the eye and said something like "cancel your expensive security project and make me head of security, I can fix this for you without hassle or expense". Needless to say they gave me the keys to the castle that very afternoon.
My trick was to track the 90-day period before which an employees password expired. The night before a password expired I would remove that employee's monitor and lock it in the security room. The next day they would have to come to me for their monitor, at which point I would sit them down and oversee them entering their new password to make sure it met constraints.
I even introduced my own password complexity scheme. To foil hackers, employees were made to fire up character map and switch to the wingding character set. They would then choose 8 symbols* and copy paste them into the new password field using the mouse. This not only foiled keyloggers but I discovered that the characters get "converted" after they are pasted into normal characters, thus even if hackers could see the new password field they would just see something like "hgfiofkg", but not the actual wingding characters behind it.
*The symbols they choose had to be authorized by myself - which was easy as I, or a member of the security team (I say "security team" but the only other member was the bosses nephew who was more of a temp and had no idea about security) was sitting behind them watching the whole process. I disallowed simple symbols, especially arrow symbols which could potentially be easily rotated by cracking software. Although as I told my future boss in the interview, all the password crackers out mainly just try different combinations of normal letters and numbers so the last thing they'd expect is wingding.
This post has been deleted by its author
This post has been deleted by its author
" This not only foiled keyloggers but I discovered that the characters get "converted""
"Head of Security" discovers that Wingdings is just a bloody font... In other news, he flies to the moon powered only by his own sense of illusion.
Strictly speaking, you give a guy a torch and a nice blue uniform and have him guard a small lock-up in Norwich, he's "head of security"...
But realistically I think we're being trolled good and proper
The security of long or complex passwords is overrated. Even for short passwords the probability of guessing a password randomly is low if only a few failed tries are allowed before the account is locked (source IP should be ignored for this). The guessing process becomes costly per account if a delay of several seconds is enforced after an unsuccessful attempt, especially if the few seconds occurs between the attempt and the failure notification and the notification provides no information to distinguish between failure to match an account at all and failure to give the correct password for an existing account. My previous employer required, at one time, 8 character passwords with a 62 character alphabet (UC, LC, Numeric, Special, two from each group), changed at least every 60 days. The account was locked on the third consecutive fail, requiring administrator intervention to unlock the account, and a new password was required at that time. The new password could not be any of the most recent 10 or have been valid during the previous 365 days and was failed if found in a password dictionary. By my reckoning, the probability of randomly guessing the password of a known account under these conditions is in the order of 1 in 10^13. The actual probability likely is several orders of magnitude larger, but still small enough to be ignored for many purposes.
The risk that concerns me is that the provider might store the password hashes insecurely or worse store them reversibly encrypted or not encrypted at all, and that the file would fall into the hands of someone with technical skills and nasty intentions. For plain text or reversibly encrypted passwords, password length has no benefit in this case. For hashed passwords, and only those, is length of significance, and should be enough to make finding any account/password combination economically unfeasible.
So I am leery of, and within reason avoid, services that
(1) can tell me my forgotten password (and think twice about those who can tell me my forgotten userid);
(2) respond in under several seconds if I make a mistake or respond to an error faster than a good login;
(3) allow more than a small number of failed attempts;
(4) do not require a new password after administrative action to unlock the account.
I am much less concerned with required length or complexity, but do use more of each for such critical accounts as those with banks or credit card issuers.
Am I wrong here?
A very long time ago, I had to have a MS account for acces to some dev resources (I think it was for Wince). So I created the account fine, using a fairly long but not exessively so password, and the found thst the website, ftp, dev program would only allow something like 8 chars, so I couldn't type it.
At the end of the day though, history has shown that you just need to say you've lost your password and type in what uou find looking on Google (ask Sarah Palin)
but with a specific target, social engineering.
I speak from experience: this last week, my octagenarian and infirm, though mentally alert, father was relieved of over fifty grand from his bank account... having been persuaded by the black hats to hand over sufficient information that they could extract the loot.
Although he was bright enough to insist on calling the bank, the black hats hung across the line and he believed them when they said things were OK. They then managed to redirect his phone (I haven't worked out how they did that yet) so no-one, in particular the bank, could contact him until we arranged a neighbour to wander round.
Irrespective of the complexity of his password, it wouldn't have stopped the attack.
(He has the money back now, thanks to the bank, and some improved protocols which require him to call someone whose voice he recognises before calling the bank (or other alleged agency)).
This advice is just sooooo utterly wrong, but for some reason perpetuated by even corporate IT departments. What do you think takes longer to brute force hack?
1"3$5Az@
or
thisisareallylongpasswordthatIcanremembereasilybecauseitsjustanormalphrase
Hint: work out the number of unique combinations of upper/lower case letters, digits, and symbols in each case. Let this be n, in case 1 the answer is n^8 ... in step 2 it's n^75 (unless the attacker knows that it doesn't contain any symbols or numbers, but he'd have to know the password to know that, so that arguments FUD).
This is also why people generally "salt" the stored versions of passwords ... to make them longer, not more complex.
All of the above is true, if and only if the attacker was using a brute force using all ASCII characters, instead of a dictionary attack (with some combinations in your case) or rainbow tables which are much more common attacks.
Plus you've also selectively picked your quote and ignored where the article points out that length is a factor of strength anyway.
Ok, so I can put a deliberate typo in somewhere and presumably thwart the dictionary attack.
As for the rainbow table, the example I gave was 75 characters, including at least one upper case, so the rainbow table would have to cover at least 32 (26 lower case and 26 upper case) characters.
Now let's forget about the fact that any sensible security scheme would have the passwords salted, so it's going to be even bigger than that. Also leave out character encoding complexities, and assume 1 character = 1 byte. Even in this very trivialised case, your rainbow table is going to take up 7.6957043352332967211482500195593e+100 terrabytes, which seems to me to be a bit of a case of "good luck with that"*.
Have I missed something?
*Someone with more energy than me can feel free to correct me on that calculation!
Over the last few days I have opened a number of accounts on Outlook.com.
The all have the same simple password.
This is because they are intended to be disposable accounts for websites that insist I join with an email ac in order to use their facilities or download something or buy something - you know the sort of thing.
There is no link back to me, and as soon as one account starts getting too much spam or junk I will dump it. Who cares if it gets hacked?
This talk of password hashing, salting etc has made me realise...when I log on to my bank's website, I'm asked for (say) the first, third and sixth letters of my password. This must mean they're storing the passwords in either plain text, or hashed in a reversible manner (is this the same thing as unsalted?). I'm no security expert so: is my conclusion correct and should I be concerned?
It depends ...
done *properly*, when the password is created, the app also creates a hashed code for each letter in the password. When you are prompted - it compares your input with the hash. Systems like this should be more secure, because even if you speak to an agent - you never give them your whole password (so they can't hightail it out back and hijack your account).
However, you highlight one thing: once you have entered your password, and pressed "return" you have absolutely no idea what happens to it. Which is why you should NEVER reuse passwords.
"generating all the letters to match the hash probably takes one micro second (incl. adding the salt, if present)."
So?
My bank's attempt at this kind of thing locks you out after three or so consecutive failed attempts.
In this set of circumstances, surely it's not the time it takes to generate the hash that matters, it's the chances of being right first time?
The secondary password fragments are just a fallback measure
- to avoid keyboard sniffing by entering from a drop-down list, so if some automated attack has already uncovered your ID and password it still doesn't have access
- to provide an extra variable, so some chancer looking over your shoulder (or watching a spycam) is left guessing.
At least that's how my bank does it.
"anyone who can guess your user name can have you locked out, right?"
Correct, but irrelevant in these particular circumstances.
It's not an internet-only bank, it's a telephone and online bank. Their telephone service is open 24x7 (x365), and the telephone folk can quickly remove the lockout using a *different* set of security questions. I know, I've used the facility several times (usually a little while after routinely changing the password and then forgetting the new one).
In a case where such independent re-authentication was not provided, an option might be to have a limited lifetime block of an hour or three. It'll sort itself out after a while, whilst still providing adequate security and adequate deterrent for most folk.
Other more creative alternatives are possible, especially in an era where cellphones (and, increasingly, smartphones) are near ubiquitous.
Now, where were we?
I have a random selection of passwords I use when joining sites and I sigh heavily when I enter a password only to be told that my password must "contain numbers and letter only". If you ignore that you then run into some stupidly short 'maximum' length at around 16 characters. Remembering different passwords over numerous sites is hard enough without having to shorten what you might use on some sites.