Slashdot Mirror
Passwords: Too Much and Not Enough
An anonymous reader writes: Sophos has a blog post up saying, "attempts to get users to choose passwords that will resist offline guessing, e.g., by composition policies, advice and strength meters, must largely be judged failures." They say a password must withstand 1,000,000 guesses to survive an online attack but 100,000,000,000,000 to have any hope against an offline one. "Not only is the difference between those two numbers mind-bogglingly large, there is no middle ground." "Passwords falling between the two thresholds offer no improvement in real-world security, they're just harder to remember." System administrators "should stop worrying about getting users to create strong passwords and should focus instead on properly securing password databases and detecting leaks when they happen."
Why would it ever be even close to that high. Every decent system I have ever encountered raised some serious flags after 3-5 wrong guesses. If you flag an account after 10 wrong guesses, start requiring a CAPTCHA after the first one, and ban ip addresses when you detect massive multiple account attempts, you can offer security fool proof security, with, lets say, around 100 guesses.
Troll is not a replacement for I disagree.
Le'ts just get to Two Factor Authentication everywhere and be done with this conversation!
Am I wrong for thinking this means you just need a string of totally random numbers from 0-9? (or even a-Z, 0-9)
PS: I don't reply to ACs.
log2(1,000,000) is only 19.9 bits.
log2(100,000,000,000,000) is 46.5 bits.
An 8-character random password with upper/lower+numbers only has log2(62^8) = 47.6 bits.
If you're serious about security, use something longer. A 16-character password has 95.3 bits.
tl;dr: Memorize a random 16-character password, and use it to to access your password vault of other 16-character random passwords.
Two-factor auth is a big win, of course. For anything financial, and for work accounts, the whole idea of strong passwords should be abandoned in favor of well-designed two-factor solutions.
How many people do per-user salting of the password hash? It's an important best practice to defeat rainbow tables. If you have thousand of passwords stolen, despite your best efforts, the least you can do is make it non-trivial to guess each one.
Mostly, though, encrypt your stored credentials in some way that requires an attacker to compromise two unrelated machines to get anything of value. Even a simple AES encryption with a hard-coded key is a win, as it's actually pretty tough (for a non-insider) to figure out he needs to either hack the source code repo, or somehow find the key in the object, on disk or in-memory. That's not impossible, but practically it limits the threat to malicious insiders, and malicious governments.
Socialism: a lie told by totalitarians and believed by fools.
There are infinite varieties of ways to inject a delay between login attempts, or lock out the console/IP entirely, after N failed attempts. N should be on the order of 10, not 1,000,000 or 100,000,000,000,000.
This has been well-understood by the entirety of the competent developer world for years, and implemented extensively as such. I hope security "analysts" catch on to reality soon.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Authentication should be a combination of "something you know" and "something you have". Smartcards shouldn't replace passwords but they can enhance their security.
Google Authenticator is a great solution to improving authentication security on most websites.
Try entering multiple incorrect passwords into your offline *nix box of choice. See how it responds.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Something is so very wrong with a web site or software program that allows any kinda brute force password cracking attempts. How many times can I type in a guess to a web site I might have forgotten the password too? Its way less then 10 in 1 minutes time I can tell you that.
Jack of all trades,master of none
Encrypting the password with a small salt is enough to slow down simple password guessing with rainbow tables. If you make the salt non-trivial, such as encrypting with a 64-bit additional site password, tables wouldn't work. Of course, the same password could have been used to encrypt the entire password file in the first place, but this technique allows the password to be stored in the usual way. You have to keep that additional site password a deep-deep-deep-dark-secret, even more secure than you thought you were keeping your password file. It can't just be included in the source file - or appended to the end of the password file - best if the password verifier reads it from a separate secure location. In that way, 2-factor encoding works for the password data itself.
Quick someone mention the horse password thingy
I believe they don't want to stop it that will stop them from doing things they already know they shouldn't be. Im with you take the toys from the scriptkiddies tool box
Jack of all trades,master of none
You don't need long passwords, just reasonably good ones, to defeat online guessing. Estimates of how quickly billions of guesses can be performed assume that all your encrypted passwords have been downloaded and can be subjected to brute force, offline. That means your security has already been compromised.
Until someone generates a rainbow table for that. More important is to salt passwords individually and use a hash function with a work factor, instead of a hash designed to be run quickly.
When you send things down a wire, everything is "something you know".
A smart card or an RSA clock or a code sent via SMS is effectively just another password. And while it may be a strong password that's hard for an attacker to know, changes with time, etc., it's still vulnerable to MITM attacks because you're sending your shit over a single, unsecured channel. It's also a password the user has little to no control over, can lose and not have a backup of, etc., so there are entire management, recovery schemes introduced to make them usable. They provide very little in terms of security over a strong password. They only fix 2 problems - weak passwords and keyloggers. But keyloggers are just a subset of compromised boxes, and if you're using a compromised box then you're susceptible to an active attacker MITMing you using your valid smart card / token / codes / etc.
For two-factor security to actually be "two-factor", you have to validate the 2 things separately and via different means. A bank can do this in person by verifying your account information/name/etc. and your photo ID by actually fucking looking at the ID and you. When you automate everything and shove it down a single pipe (the internet), it's all effectively just a password.
Do you know what an OFFLINE attack is? Hint: it's one where you're NOT sitting at a login prompt.
Wow.. the stupid in this one is strong. Let me explain it: an offline attack is where you have the password database itself and don't need to wait for a login program. You're free to hash things as fast as you like.
Hopefully not ones from HID if you want any actual security.
Implement two factor authentication. It's not hard program nowadays and it makes your login system far more resilient to password related fuckups from your users.
No need to. "Offline" means precisely how I used it. That you have a more qualified usage in mind is something I'd address when it was stated.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Because people like you still link to that shitty comic that's been debunked over and over and over.
No, it doesn't mean what you think it means. It has a specific meaning in relation to security. It has absolutely nothing to do with whether or not a box is connected to a network.
You're showcasing your complete incompetence by talking out of your ass. Just shut up already.
Two factor authentication for most applications - something you have, something you know will do nicely. Three factor authentication for the sensative stuff - something you have, something you know and something you are.
If the database can be stolen, then that, in itself, IS the problem.
Linked below.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
The phrase "offline attack" is not the word "offline". Tough concept, I know. The AC above said "offline attack", not "offline".
You need to shove it, because you have NO IDEA what you're talking about.
Again, the phrase "offline attack", which is what the AC used is NOT the same as the word "offline" used all by itself.
How hard is that to grasp for you? You're here spouting off suggestions for cryptography/security without knowing the most basic terms.
I've never had my passwords guessed. They have been given away by the likes of Target,Wallmart,Sony,Facebook,EA, and the long long list I don't even know. 1 brute force attempts must be blocked period end of story. Any business who has customer data in an unencrypted formatte when stolen..opps Given away, must be fined 50 million dollars per customer data stolen..opps given away. You laugh at 50 million I am however not laughing. its time to get serious
Jack of all trades,master of none
Sorry, I can in fact parse the sentence as an attack that occurs "offline", as well as a more selective usage parsing it as "offline attack".
Good luck with your emotional self-control.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
The fact that you would choose to parse it that way shows that you have no idea what you're talking about. The topic at hand is passwords and security. The phrase "offline attack" has a specific meaning within that context. More to the point, only you used the word "offline" all by itself.
You must be trolling. This is an incredible level of stupid or purposeful ignorance. I'm done trying to fix that much stupid.
Because its wrong.
If you treat each word as a symbol, rather than each letter, then you find the average vocabulary is about 10000 symbols and you have just generated a 4-character password (admittedly in base-10000 rather than base-26) but you'll find its still easily crackable, especially if the hacker uses pre-generated rainbow tables.
Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours. For reference, 16 random characters would take 2.5 billion years (ie 64^16 = 8*10^28, which is 8*10^16 trillion seconds, or 2512 million years). Ok probability says your chances are on average half that.. only 1.25 million years.
The best password is a random one, use a tool to generate and store them and let it type them into the password field. If you must use a xkcd style password, at least stick a digit between each word.
Again, my parsing of the sentence is fine, and was the one pertinent to the suggestion that 10,000,000 online attempts is a reasonable possibility to be addressed.
Which is what I intended to convey.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
That's a great comic! If only people checked that the phrase being used were unconnected with them far far better system.
Fine, be done.
Particularly envious of dev salaries today, or what?
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
So, back to my original statement:
Correct, absolutely, as stated, that the ability to inject delays into the supposed 1,000,000 online attempts makes the notion superfluous as a theoretical security concern.
Here, I am using "online" to me specifically the use of "online" clearly called for by the premise of the topic.
Again, no problem. I am using it in the way relevant to the question.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Then you've accomplished essentially the same thing as salting, because you'll need to store the number of times hashed along with the password entry in the database. Why not just make life simple and use something designed for hashing passwords, like bcrypt and a salt?
Frankly, you're overcomplicating things. Complicating your security scheme is a bad idea, like inventing your own crypto. As a hobby, I study cryptography and write crypto code, but I would never use one of my own homebrewed schemes in production or for anything important. The chance of screwing up something non-obvious is far too high.
Stick with the tried and true.
Offline, the attacker can if all else fails brute-force the password. No password is complex enough to survive a brute-force attack. With the growth in computing power, including the ability to apply GPUs and specialized hardware to the task, search space size alone isn't enough protection. The only protection, as noted, is detecting the leak of the password database early so users can change passwords before the offline attack has yielded usable results. Alternatively, the authentication system can employ two-factor authentication so that the password alone isn't enough to compromise the account.
For on-line attacks, I'd argue the number given's too large. A properly-designed on-line system should be designed with rate-throttling and account-locking mechanisms, and with those in place a password should only need to survive at most maybe 10 attempts before even the correct password won't access the account. Those mechanisms can be applied to all current systems right now.
The biggest hole isn't the password itself, it's the password-recovery system. Why bother with either an offline or on-line attack on the password when you can initiate password recovery and change the password on the target account to one you know?
That's not true. They also provide protection against:
For example, consider heartbleed. If someone stores your encrypted communication, and later compromises a host's private key, that attacker could ostensibly decrypt those communications. If you use a password, that password is compromised, and it's "Game over, man." If you use a physical token, only the PIN is compromised (assuming the actual verification happens in a separate process).
Ideally, you would still want to issue new PIN codes, but the account hijacking risk would be largely mitigated by the physical token requirement, at least after the n-hour cookie expiration window passes, and you could even eliminate that window by expiring any cookies in your authentication database before bringing it back online after you fix the heartbleed vulnerability.
Check out my sci-fi/humor trilogy at PatriotsBooks.
So now I have trolls accusing me of trolling and ACs deriding me for supposedly posting AC...
But no, wasn't me. My emoticons are dashless. ;)
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Make that:
$ pwgen -N 3 -y -s 20
Q^lu)bgREy3c$OH5PmGI 95Q~\\1?"W#S9*yDa1)A c0UX4]?e$1{WjM3N7inI
My blog, if you're interested: http://www.purp
Yes, it is. And I've been here a long time.
People getting emotionally irate at reading "offline" as "not online" rather than "offline " is reasonably rare here, fortunately.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Speaking of parsing...
Before Slashdot's got ahold of it, that read "offline [subqualifier]". Need to watch my > and < too, apparently...
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
Don't roll your own password system. If you're a public site, use OAuth Connect to let them sign in with their account from Google, Yahoo, or some other company that specializes in this sort of thing. If it's a business-to-business site, use Kerberos or LDAP to let them sign them in with their own company's username and password. This also cuts down on the number of usernames and passwords users must remember.
Well, I wouldn't argue that on a theoretical level that a password of any size or complexity can't be compromised by a botnet of arbitrarily large size. The article opens with what is "enough", and with an arbitrary number of IPs over an arbitrarily large amount of time, no password complexity would be "enough".
However, I think simply doing this:
1. Delay 5 seconds after an incorrect login ...would be very difficult to brute-force even given a very large IP pool, and that size is ultimately limited by cost.
2. Double the delay after every subsequent login attempt
3. Block the IP after 10 sequential failed logins
4. Lock out the account after 100 sequential failed logins, and require a CAPTCHA or e-mail process to re-enable the account
As you say, though, it doesn't stop someone from executing a DDOS attack, but the potential exposure and damage there is quite different.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
When you hash something twice, you've limited the input space to the second hash function to the output space of the first function. This is often smaller than the thing you were initially hashing.
Instant flaw, and not immediately obvious.
That's where trusted authorities and public key encryption comes into play. The trusted authority essentially acts as the "different means."
Of course its still susceptible to MITM if the attacker can get between you and the point where the data transmission splits off between the CA and the destination site (and of course are already in place at the time you register with the CA and have the private key on the wire.)
Not impossible, but also pretty difficult to achieve since it usually means physical access to something relatively local to the sender. At least until the ISPs themselves become the MITM attacker (which is becoming more and more probable unfortunately in the modern age of Orwellian surveillance attempts.)
Of course yes, the most obvious solution is to just pass the key over a different communications channel. But nothing is ever absolutely secure. If you meet the person face-to-face to exchange the secret, you have no guarantee that he isn't in collusion with or coerced by an attacker, or won't be at some point in the future.
The only way to be 100% sure that a secret is safe is to keep it in your head (don't even write it out or save it to your hard drive!) At least until we figure out mind-reading devices. But most secrets need to be shared with someone to be useful so that's not always a plausible solution.
Your online password could turn to be an offline one if the crypted version of it was in a server with a vulnerability/been hacked/given to authorities.
Did you read TFS?
Yes.
They say a password must withstand 1,000,000 guesses to survive an online attack...
Feel free to state if you think this phrase, which my post addresses, is or is not present in TFS. If we agree it is, that is what I was responding to, on the basis that one can respond to something in any way they wish, in whole or in part. If you feel I am required to have responded to some other part of the summary, or in some other way per your preferences, feel free to explain why. Otherwise, your own independent post making your own points seems appropriate.
Slashdot is getting really OCD-strange lately...
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
If you can get at the info, a TLA can coerce you into giving them the information. Unless you're both willing to die and to be tortured to protect the information, you can't both access the information and keep it from them, if they're determined. Of course, if they're just mildly curious you can do it, but then things that work against the phone company should work.
I think we've pushed this "anyone can grow up to be president" thing too far.
> so there are entire management, recovery schemes introduced to make them usable.
I'm hoping that other companies do this better, but I've noticed that the recovery scheme is particularly open to a social engineering attack. If you lose your RSA clock dongle or it quits working, a call to the helpdesk will get you a "temporary code" that gives you access to the company's intranet. To do this only requires the helpdesk phone number and a valid employee name and associated employee number. None of these items are particularly secret.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
> Not impossible, but also pretty difficult to achieve since it usually means physical access to something relatively local to the sender.
Wow I just had a flashback. This was the first step of the plan in most Mission Impossible episodes.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
One martini is not enough
Two martinis is too much
Three martinis is not enough
“He’s not deformed, he’s just drunk!”
replace 1 letter in each word with a number and use numbers as spacers, problem solved
And you fail your check when I use Correct instead of correct.. or corr3ct.. or whatever. That adds a LOT of complexity to the basic 4^10k. Throw in variable punctuation and spacing and things start looking a little uglier to an attacker.
And yes, 16 completely random characters is probably still harder to crack, but how many people use completely random characters? How many people would be able to remember their passwords even if they did make such a one? And if you're using a password program rather than trying to remember it, you may as well make it 64 completely random characters cause why not.
There's a tradeoff between perfect security and practical security. You can't just assume that because your favorite scheme is 10 or 100 or 10^100 times more secure than the one that's currently in use that anyone's actually going to switch if it means an enormous amount of extra work on the part of the users.
it's still vulnerable to MITM attacks
No. The smartcard is pre-programmed with the public key of the authenticator, and vice versa. Unless someone knows the private key of one of the endpoints, the authentication cannot be faked. A MITM attack will not work.
Smartcards. Please.
Smartcards alone are not a solution, because they can be lost or stolen. You want both a smartcard and a PIN/password. You smartcard may get stolen, or your password may get compromised, but it is less likely that both will happen at the same time. You might want to setup a threshold for PINless transactions for, say, purchases under $10, but you still want more security for important stuff.
I won't do banking over the internet.
Some banks have started charging a $60 per year fee to send paper statements instead of e-mail. What will you do once all banks with ATMs in your home town do this? Switch to an online bank that can't accept cash deposits?
The comic does tread each word as a symbol, which is why it only claims 11 bits of search-space per word, which requires a dictionary of only 2048 words, and there are way more than 2048 words that are long enough that the fact that they're in a dictionary is the limiting factor. It's already accounted for in the search space estimate.
The claim of the comic hasn't been "debunked" because the claim isn't that you can use words to have a lot of characters in your password, it's that we've been focusing too much on getting the most search space out of each character when the thing we want to optimize is the total search space per password that a person can remember, and the word technique sacrifices a lot of character efficiency to result in better overall passwords.
Your hypothetical user isn't choosing between four words from in a 10k word dictionary and a 16 character password. The fully random 64-symbol password of equivalent memorability is probably quite a bit shorter than 16 characters. I wonder what research has been done on this; I'd put my money on the equivalently memorable password being closer to 6-8 characters.
It only takes nine words from a 10k dictionary to beat a 16 character (64 symbol space) password. It also only takes 21 lowercase letters to beat your "complex" 16 character password, and I know which one I'd prefer to actually have to type regularly. More symbols per element is only a benefit when it increases the ability of the user to actually use stronger passwords.
Can you be Even More Awesome?!
Things like Facebook Connect, OpenID Connect and Mozilla Persona (BrowserID) are better than passwords [and] easy on the user when implemented right
The problem comes when well-known sites don't implement it right, such as by implementing only Facebook Connect and nothing else. The Huffington Post, for example, requires each commenter to have a valid subscription to mobile phone service and give a globally unique number capable of receiving SMS to Facebook.
There are infinite varieties of ways to inject a delay between login attempts, or lock out the console/IP entirely, after N failed attempts. N should be on the order of 10
At which point you may be on the wrong side of the tradeoff between security and convenience. If you have 100 subscribers behind a proxy with a single public IPv4 address, and ten of them forget one password, good luck fielding customer support calls for all of them.
a CPU that can manage a trillion hashes per second (easy)
A trillion (10^12) hashes per second can still check only 100 million (10^8) passwords per second if checking each requires 5000 rounds of PBKDF2. In the common PBKDF2 built on HMAC, each round is two hashes, making a 5000-round PBKDF2 take 10,000 (10^4) hashes.
I'm so sick of these goddamned articles, insisting I need FDGHN$@%YFSDG#$T#62532@..1..sdg..FGT34#$% as a password or horsebatterystaplegoatsehamburgerlolsixtynineomelette?
Tell me internet, tell me, how many compromised accounts over the past decade have been from poor passwords, OR how many have been compromised due to the site / service in question having a security hole / unpatched exploit run on it and tell me even further how many are due to social engineering?
I'm more than willing to bet that over 95% of all compromised accounts on any system(s) in the entire world is due to those 2 things and not the complexity of the password and frankly, I'm sick of having to have monstorously complex or awkward passwords in some environments which are almost deliberately difficulty to remember.
I really wish I could convey how much I appreciate the poseur irony of this post, particularly with the "coincidental" CAPTCHA.
Maybe a song will help.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
I understand different places have differing levels of "complexity" requirements for passwords, by why would there ever be a limit on the characters you can use?
One site might want 8 characters, with one number and one uppercase, and one special character, but they only allow "certain" special characters!
Some sites are ok with dashes, others, underscores... WHO CARES!
Oh, and don't get me started on credit card input "please enter just the number, no spaces or dashes" - Well, if you don't want the spaces and dashes in the user input, JUST FUCKING REMOVE them, and say "thank you" to the customer, who used to always be right, but now is apparently just a schmuck.
Was that too harsh?
This issue is a bit more complicated than you think.
When you send things down a wire, everything is "something you know".
Kinda one of the points of smartcards is that you don't know the key inside of them. Thus your access can be revoked physically by depriving you of the card, should it become necessary.
And no, MITM attacks don't affect properly implemented smartcard or even password authentication, as preshared material and/or mutually trusted authorities counteract that.
With regards to TFA, here's an example of how PubkeyAuthentication has some drawbacks and is not a hands-down superior method for authentication over passwords. Letting users leave those lying around wherever they please means the weak passwords they chose on those keys are more likely to be guessed in an offline attack than is a password in an online attack against a rate-limited authenticator.
Someone had to do it.
Do you know the difference between STUPID and simply UNINFORMED? Also the difference between bold and SHOUTING?
Someone had to do it.
Don't remember passwords: keep them on a physically secure device protected by ONE password you remember.
Ok, so we give a password manager device to all the users that cannot be trusted to create strong passwords, or if given a long password will write it down, probably on a sticker attached to said device. Then, they take 4 times as long to log into things since they constantly have to unlock their password manager, and each time they do so open a window to keylogging or sideband attacks on the same password. And they leave their passwords hanging around in cut and paste buffers. Finally they lose their "physically secure device" in a public location and expose it to an offline attack, and possibly also lose their written-down copy of the master password.
Not a fan of those systems.
Someone had to do it.
Are there really password managers that don't purge the clipboard a few seconds after copying a password?
You must have encountered one of the few systems where people actually pay attention to such "details". There are plenty of locations where you can brute all you want and where the entire DB of passwords or hashes is relatively easy to obtain for a hacker. Since people re-use passwords a lot, that's often enough to get into the few locations where brute-forcing is made more difficult.
I was promised a flying car. Where is my flying car?
You just created one tiny extra step for people stealing the database. If a system is so flawed that an attacker can get your database, they will most likely only take a few extra minutes to get their paws on your salt.
Granted, they need to write their own module for oclhashcat to get this cracked at a decent speed, but once that's done, your proposal isn't functional.
I was promised a flying car. Where is my flying car?
Because biometrics can often be cloned, copied or otherwise be "fooled" when used for authentication. Finger print scanners are worthless since so many attacks exist to current finger print readers when someone copies your print. You can't get new finger prints once someone made a copy of yours, so as an authntication method they are worthless.
Some other authentication methods using biometrics exist, but they are generally too expensive to implement in most cases. They may not be "affordably" circumvented yet, but I have no doubt that once it's worth it to put time and effort in it, people will find ways to fool those systems too. I'd hate to have to get new eyeballs because someone copied a scan of mine onto a synthetic ball.....
Apart from this, remote authentication using biometrics replaces the biometrics with some sort of device sending some sort of signal to the remote location with either a signature of the biometric information, or just a version of "I've check this person out and they're okay". You once again transfer the problem from biometrics to some form of digital communication which obviously is just as weak to hack as the technology you are trying to augment for being weak.
I was promised a flying car. Where is my flying car?
Disclosure: I work as a penetration tester In my line of work, we often go for passwords, encrypted or not. Especially on office networks, we go for the LANMAN (yes, we do get to see those on a regular basis still) or NTLM password hashes. Even NTLMv2 are useful to us, although cracking those requires more time.
The reason that LANMAN and NTLM are so useful to us, is that we can just use the hashes to authenticate against remote servers. That's right, knowing the password isn't required, just having the hash is enough for the remote server to authorize us as the person that the hash belongs to. This is "fixed" in NTLMv2 and if you properly implement Kerberos for your AD authentication. However, since legacy systems are abundant, in practically every office network we encounter, the older systems are still in place because of "backwards compatibility requirements".
No amount of password complexity helps against the above problem. Several commercial 2-factor vendors solutions aren't even a solution. Why? Because they replace the password prompt for a prompt for a token generated by their device and once that reply is satisfactory, they simply send the hash themselves. Their solution replaces the password, but not the real weakness, the hash itself.
This may not be a significant problem on the internet, but once an attacker has gained access to your corporate network, this problem usually means doom for anything password protected. This sort of thing happens on a larger scale than most internet users realize. Advanced Persistent Threats (APTs) aren't named that for no reason and they are just a few of the many organizations and individuals attacking companies these days.
I was promised a flying car. Where is my flying car?
What I want to see is a smarter card. Ideally it has a few indicator leds and a membrane keypad on it.
It should support ssh style security and a simple agent protocol so that you can plug it into a reader, enter a pin directly on the card (so no intercepting the PIN from a hostile terminal). This should log you in and allow you to use agent forwarding to connect to other machines you are authorized on.
Possibilities when you pull the card out include locking the screen or logging you out.
It should have persistent storage as well so it can be used as a payment card as well. Enter a maximum amount of payment you are willing to make using a wallet device, then insert into a reader on the POS. POS presents it with a transaction record and if the amount is correct, it signs it and hands it back. The record should contain a sequence number so that the bank will only accept the transaction record once.
Restrict the record to ASCII so that it can be cut-pasted if you want to complete a web based transaction without a browser plug-in. At that point, the account number is strictly for identification, the crypto signature is what authorizes the transaction.
More advanced features can be carried out on a trusted computer such as your home PC.
They're talking about a different problem. If hackers get ahold of the password hashes, then restricting the rate of login attempts on the server itself won't help. That's where that "100,000,000,000,000" number comes from. I believe it's saying that's how strong the password needs to be to withstand a brute force attack when an attacker has gotten ahold of the table containing encrypted passwords. That's why it says:
System administrators "should stop worrying about getting users to create strong passwords and should focus instead on properly securing password databases and detecting leaks when they happen."
However, that seems like a short-term solution when there's a better long-term solution that's pretty obvious, which doesn't require relying on system administrators to secure password databases. If we stopped using passwords and used public key encryption instead, then websites wouldn't have your password, so they wouldn't be able to leak it.
It's an obvious solution. We know how to do it; the technology isn't new. We won't do it, though, because we don't care about security and we're unwilling to develop new standards. The companies who could push new standards forward are more interested in maintaining walled gardens.
Me and other security experts have been saying such things for years.
Basically, our password handling systems and policies are completely broken. It's not just what xkcd pointed out - it's worse. Those policies are based on making brute-force attacks more difficult. But to sum up a complex topic in a soundbite: If your system allows for brute-force attacks, your system is fatally broken.
Assorted stuff I do sometimes: Lemuria.org
or lock out the console/IP entirely, after N failed attempts.
Which opens the door to DOS attacks on target accounts, but there are several smart ways to work around that (send an unlock link to the e-mail address for that user, for example).
I hope security "analysts" catch on to reality soon.
There are two kinds of security people in the business world. Those with a real interest in advancing the field and making computing more secure, and those working for large consulting and IT "Security" companies. I am exaggerating some, of course, and there are great people in those companies as well, but unfortunately the business concept of too many of them is based on solving problems in such ways that you can sell the solution to many other customers, not on finding a solution that takes care of the actual problem.
It's the same with consulting companies and the insource/outsourcing cycles. There are good arguments for both of them, but if you've watched the business world for a decade or two you understand that they are hyped in cycles so the same consultants who sold outsourcing to a company last period can sell insourcing to the same company next period or after the next CTO change.
Assorted stuff I do sometimes: Lemuria.org
Just for the record, the strength of a random 16-character password with random combinations of upper and lower case letters and decimal digits is:
62^16 = 47,672,401,706,823,533,450,263,330,816
Well, that's the number of combinations, and one would need to check half of them to have a 50% chance of cracking such a password. (Well, that's not precisely the strict probability theory language for it, but it's something like that.) In other words, anyone who uses a simple password manager should be fine.
2FA
This is a reply not just to the comment from amxcode but the GPpost from ColdWetDog.
A random-seeming password doesn't really have to be random, and thus you don't have to rely on someone else's software to keep track. You can generate a long password by hashing a short, easy-to-remember "pre-password" that only you could guess.
For example, you can decide that your personal password-salt is "ColdWetDog", and the pre-password for your Amazon login is simply "amazonColdWetDog". (And the pre-password for your bank would be "bankColdWetDog".) Then you hash it with MD5 (or SHA-1 or RIPEMD-160 if you don't like the collision vulnerability of MD5, though in tis case it doesn't make a difference). The result is a long string, and you can take the first n bits and use that as your password. (Yes, MD5 only generates hex digits, so accumulate it into base64 to make them ASCII characters.)
And, boom!, there's your big long pseudorandom password that you can use no matter which operating system you switch to, without having to worry about any password app from some app store.
My own password manager is a text file encrypted with open-ssl. It's not just that I am paranoid about password apps someone else wrote; I also need it to work on multiple platforms. Write your own; it's not that hard.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours.
Err... that's rather faster than any CPU or indeed GPU I've ever heard of. Depends, of course, on your hashing algorithm, but the fastest I've ever heard of is 3.5 x 10^11 NTLM hashes, which wasn't a single CPU but a cluster of 25 GPUs, so call it 2x10^10 for a single processor, or approximately 2 orders of magnitude slower than your suggestion of what is "easy" to achieve.
Also note that this was NTLM, which is a lot weaker and easier to calculate than most of the algorithms used by web-based systems today. The same cluster only managed 71,000 hashes per second against bcrypt, which is the algorithm that is usually recommended for new systems at the current time. That's about 3,000 hashes per second per processor.
So cracking that XKCD-style password in less than 3 hours...? Not in reality it can't. That's 10^12 possible passwords. If they were hashed using NTLM and you were using all 25 nodes of the fastest password cracking cluster that has been publicly described, and they were as short as the passwords used in the original benchmark it would take about 3 hours, yes. But (1) nobody seriously uses NTLM, and (2) few attackers have that kind of hardware available, with cost estimated at around $30,000.
Used on a site complying with modern standards of password encryption against a realistic attacker (a script kiddie using a couple of high-end gaming system with 2 top-end GPUs, thus cranking out about 10^4 bcrypt hashes per second) your XKCD-style password would last about 5x10^7 seconds, or approximately 1.5 years.
Change your password every 6 months and as long as the site uses modern encryption techniques you'll be just fine.
We have hundreds of accounts scattered across the net, and each's security relies on a secret that is supposed to be unguessable and shared only between you and that site. Such is the primary assumption of passwords, and yet such a system can never work for people.
The only solution is to stop using passwords as passwords and instead consider them as "symmetric keys". Master Password is a password generator that takes the name of your site and generates a unique key for you and it which you use as the password for the site. The awesome thing is that it's a generated key and thus doesn't rely on any form of storage, be it cloud or require backups and sync, nor can it ever be lost. It uses the scrypt KDF to protect itself against off-line reversal attacks.
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''