Passwords: Too Much and Not Enough 223
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 so high? (Score:5, Insightful)
Re:Why so high? (Score:5, Insightful)
Its not about entering passwords on the web login page, but securing the back-end system so that the password database cannot be stolen.
I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password. (incidentally, the developers didn't have access to production servers either)
So sites like ebay et al have direct DB connectivity to their DBs, so if any hacker exploits some zero day that gives them access to the OS, they can simple "select * from user" and download every password, hashed or not, and crack them at their leisure.
Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers that they need to be protected in other ways so the hacker cannot access them in any circumstance.
However, what I do find strange is that web devs do not know this, I wrote the above for an ArsTechnica comment and the "security editor" promoted a criticism of it where the concept of a 3-tier architecture was "too expensive" an d"inefficient", suggesting that storing your DB credentials in your web code was OK as long as you "secured" it. If this is the level of comprehension of security in the web dev community, then I'm not only unsurprised at the number of hacks, but will be using a randomly-generated password for every website that asks me for a password.
Re: (Score:3)
... but will be using a randomly-generated password for every website that asks me for a password.
I'm not in the position to argue the merits of the rest of your post, but this last part seems obvious.
Once you have more than a half dozen passwords, your ability to remember them drastically decreased unless you are some sort of savant. You need a password manager. Once you are using a password manager, there is no reason NOT to use a different, random, difficult to hack password on every site. I have no idea what the vast majority of my passwords are - the only ones I remember are the three I use mul
Re: (Score:3)
Once you have more than a half dozen passwords, your ability to remember them drastically decreased unless you are some sort of savant.
Absolutely. The fact that we (application developers) are dealing with passwords at all is the root of the problem here. The first time I wrote an app that did this (in 1997) I felt a little queasy about it. Yes you should use a three-tier design if at all possible. Ad-hoc queries cause many more issues than just this anyway; stored procedures should be the only allowed access from the middle tier. The password should be hashed a zillion times before being stored or compared.
But really, that's all just
Re:Why so high? (Score:5, Insightful)
As long as your DB is connected to any network in any fashion, its susceptible to cracking. You can't possibly know what new attack vectors may arise. And even if you somehow manage to guarantee 100% security in your software (which is frankly unlikely to the point of impossible -- software is hard!) you still can't guarantee that some human participant won't either go rogue or screw up, allowing access to the DB that doesn't require _any_ technological cracking.
The only way to completely lock down a computer is to keep it shut off in a vault that literally nobody can open. But of course that also makes it no more useful than a rock.
As for web dev's comprehension of security.. again, software is hard. When they say its "secured" what they mean is "I can't think of a way in." But of course that's a totally irrelevant metric because they aren't the attacker.
And that fact applies to everyone, up to and including the most experienced security researcher in the world, because of the obvious fact that if they could think of a way in, they'd patch it. Its always the ones you don't think of that get you.
No matter how smart you are, there will be a maximum program size you hit before the complexity overwhelms you and you have to internally abstract things, and every abstraction is a potential security hole that you may or may not ever consider. Never mind relying on third party libraries or for that matter the security of the hardware layers.
We've definitely come up with some best practices, and its no secret that there are loads of people who don't know, don't care, or don't have the time to implement the best practices.. but all the best practices in the world don't solve the problem of program complexity exceeding (full) human comprehension.
Re: (Score:3)
I used to work at a financial company where the web server didn't have physical connectivity to the DB,
I suspect you meant something entirely different from what you said. The webserver cannot be air-gapped from the password database unless you literallly have a person sitting between the two systems keying requests from one into the other and back again. Otherwise they most assuredly ARE physically connected in some way.
Personally, I think passwords should be stored in plain text in the DB as a reminder
Re: (Score:2)
I took "didn't have physical connectivity to the DB" to mean that they used Wi-Fi for extra security :-)
Re: (Score:3)
I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password
Occasionally I hear people making statements like this and while practically useful *at best* language is a dangerous assumption.
Additionally complexity of a middle tier just for security sake could well provide additional avenues of attack that may not be available in a globally less complex solution but it all depends on specifics of the implementation.
The reason why *at best* is wrong an attacker able to compromise the application, middle or data tier is almost always able to exert complete control over
Re: (Score:3, Interesting)
If you flag an account after 10 wrong guesses, start requiring a CAPTCHA after the first one ...
Didn't we see a story a while ago purporting CAPTCHA had been cracked? I didn't bother with it myself (don't much care). It's only useful for web based logins, yes? I'm not suggesting those don't matter; just they don't matter much to me.
... and ban ip addresses when you detect massive multiple account attempts ...
A few years ago, someone reported that has changed the attackers from "batter on the door until it breaks" into slow trickle instead; lots and lots of attacking hosts on separate IPs, each one making only one or two attempts, then moving on to the next on the list.
Re:Why so high? (Score:4, Insightful)
Then do the simpler thing and ensure the password file is securely protected and add some real time in the password entry. A simple countdown timer to slow password entry down and increasing the time each a wrong guess is made, say simply doubling of the wait time between entries ie 1 second, 2, 4, 16, 32, 64, 128, 256 and so it goes, with a reminder to the user of the implication of too many bad guesses. Throw in a email warning to the user when say three incorrect password attempts are made in a row. Also association IP addresses with user name passwords not locked so much as for when too many bad guesses occur as an additional flag. To go really secure put the passwords on a separate simple small cheap box and all that box does is encrypt, decrypt and test passwords and user names, nothing more. That is the only communications the box will accept and the only information the box will provide is pass or fail on that test.
The big security advantage in switching from boxes that do everything to appliances only, is that those appliances can be hardware and software configured to be able to 'ONLY' do what they have been designed to do. You make them unhackable by simply making sure they can not carry out the required functions needed to carry out the attack, they are locked into only carrying out their designed algorithms and require a specific hardware and software rebuild to do anything more. This can be done very cheaply with things a password checker. Flexibility in technology leads to a whole lot of security problems ie the system ends up doing things the user never intended.
Re:Why so high? (Score:4, Informative)
CAPTCHA had been cracked?
No.. CAPTCHA is a concept. Several specific CAPTCHA algorithms have been broken over the years, but new ones come to take their place.
Image-based CAPTCHAs (that is, stored images not ones that are generated on-the-fly) are trivially broken by building a database of them and solving them. Of course building such a database without being detected is the tricky part -- you can't just spam Recaptcha's server with 100 million requests and not raise some flags. The best / hardest to detect I've heard about is getting an MITM installed on a legitimate website and then when (real) users solve (real) captchas, you fire the answer back to your database. That's probably what you mean by the "trickle" you mentioned above (or something similar to it.)
Algorithmic image creation (ie: create a random string of letters/digits and then muck it up to make it hard for OCR software to read) is a lot more secure.. but at the same time its also a lot harder for a human user to successfully answer. Some of them get so bad that you can't even tell that they ARE letters never mind which ones.
Recaptcha (being pretty much the biggest third-party captcha provider out there) is interesting in the sense that they mix multiple algorithms. They use stored images.. they use generated images.. their generated images are obscured using multiple algorithms.
Sure adding an additional algorithm is only a linear complexity increase, but if you go from say 1 algo to 3 algos, you've dropped an attacker's chances of success by 66% (unless one of your algos is trivially breakable but we'll assume you know what you're doing when you introduce a new one.) That's not insignificant even if its only linear. And I'm pretty sure Recaptcha is up to a dozen or more different obscuring techniques.
It's only useful for web based logins, yes?
No, its useful any time you need to distinguish a real person from a machine attacker (in principle at least.) There's just very little need to make that distinction in most offline software. And of course you need to have at least the ability to pass images in order for a captcha to work at all, so you couldn't add a captcha to say telnet, which is intrinsically a text-based protocol.
Re: (Score:2)
Besides, it wouldn't matter if CAPTCHA were cracked for his purpose. His purpose is to raise the cost of intrusion to the point where the attackers go somewhere else. Not ideal, but it's probably the best you can do.
Now there are several layered approaches that one can adopt to strengthen the security, but convincing the attackers to pick on someone else is probably the best any of them, or all of them combined, will accomplish. How much security you use depends on what you're protecting. Personally, if
Re: (Score:2)
The idea should not be just to require CAPTCHA as an additional password, the idea is to slow down an attacker and break scripts.
Maybe it's just me, but TFA and most comments so far are way off base. A guy suggesting to store passwords plain text in a DB? TFA claiming 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."?
Is this an early April fools gag, did the NSA
Re: (Score:2)
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.
If it only takes 100 guesses, then an attacker can slowly try passwords stretched out over time, depending on his victim's routine behavior of logging in a couple times per day to reset the fail count. Or maybe he can try 1 guess (with 1/100th odds) on each account in the target system. If there are hundreds of accounts... well, you get the idea.
IP-based banning can make this harder (forcing the attacker to find/use multiple victim PC's), but it's not widespread yet (for instance, I don't think Active Di
Re: (Score:2)
Agreed
It's hard to imagine any site allowing 1,000,000 bad guesses
It probably varies by site, but methinks anything over 100 or so would trigger a response
Even if the limit was 1000, same outcome
Re: (Score:2)
I'd like to set it to any number of errors in a row starts increasing the time between allowed login tries, and start the delay with the 2 seconds and square it for each succeeding wrong guess. Also a warning on the login page as soon as even one erroroneous login attempt is detected.
Unfortunately, it's not a standard option, I'm lazy, and I don't have anything valuable on my machine. (E.g., I won't do banking over the internet.)
Paper statement surcharge (Score:2)
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?
Re: (Score:2)
Agreed
It's hard to imagine any site allowing 1,000,000 bad guesses
It probably varies by site, but methinks anything over 100 or so would trigger a response
Even if the limit was 1000, same outcome
Apparently, this guy had no problem trying to guess 20,000+ passwords for any account on iCloud [dailydot.com], a security issue he disclosed to Apple six months before CelebGate.
But again, this must have been user error.
The theft of the photographs, a statement from the company insisted, was not the result of “any breach in any of Apple’s systems including iCloud or Find my iPhone.”
The only thing Apple did wrong was not to educate its users about security.
“When I step back from this terrible scenario that happened and say what more could we have done, I think about the awareness piece,” he told the Wall Street Journal. “I think we have a responsibility to ratchet that up. That’s not really an engineering thing.”
Nobody does that (Score:2)
Why are we STILL discussing this? (Score:2)
Le'ts just get to Two Factor Authentication everywhere and be done with this conversation!
Re: (Score:2)
That's a long time in the coming. Screwing around with a keyfob or other physical item is a pain in the ass. Sometimes a worthwhile pain in the ass, but enough of one that "everywhere" is going to be a stretch.
Unless they can make the second factor an intrinsic value (that is, something built into the computer or the OS that could be passed without the user having to physically do much.)
It wouldn't even be all THAT hard to do, but it pretty much means having to set up some sort of certificate system which
Re: (Score:2)
Two factor authentication is no more secure than a longer password. (Granted, it can easily be the equivalent of a MUCH longer password.)
FWIW I think we should switch from passwords to pass phrases. "All cows eat radishes" is much harder to guess than "#iOpqn23!"
14 length passwords? (Score:2)
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)
Re: (Score:2)
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)
Or "totally random numbers from 0-9? (or even a-Z, 0-9)" plus punctuation chars, plus not made up of words which could be found in any dictionary, plus not made from anything that could be gleaned from your online activities or through social engineering.
I think I'll stick with ssh, post interfacing with a real human face to face.
Per-user salting (Score:4, Informative)
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.
Re: (Score:2)
How many people do per-user salting of the password hash?
People spouting things like this is precisely why we have tens of millions of web apps using shitty password storage solutions that boil down to HASH(salt + password) and are thus borderline fucking useless. It's like asking if someone's home-grown encryption algorithm uses an IV - that might be an important part of it but it's kind of missing the point.
If you're using passwords for authentication in your app, use a recognised key derivation function [wikipedia.org]. Use PBKDF2 or bcrypt and tune them to take at least 10
Re: (Score:2)
Two-factor auth is a big win, of course.
It's a double-edged sword. Do you really want every website out there to be able to track you based on your phone number?
Computers: They can respond fast -and- slow (Score:5, Insightful)
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.
The cost of great security is severe inconvenience (Score:2)
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.
Re: (Score:2)
Maybe a song will help. [youtube.com]
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Speaking of parsing...
Before Slashdot's got ahold of it, that read "offline [subqualifier]". Need to watch my > and < too, apparently...
Re: (Score:2)
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
2. Double the delay after every subsequent login attempt
3. Block the IP after 10 sequential failed logins
4. Lock ou
Re: (Score:2)
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.
Re: (Score:2)
Do you know the difference between STUPID and simply UNINFORMED? Also the difference between bold and SHOUTING?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Fine, be done.
Particularly envious of dev salaries today, or what?
Re: (Score:2)
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. ;)
Re: (Score:2)
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. Otherwi
Make the salts non-trivial (Score:3)
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.
Re: (Score:2)
Encrypting the password with a small salt is enough to slow down simple password guessing with rainbow tables.
What is the practical effect on a password list when rainbow tables are taken off the table?
Yes much easier everyone gets that...so what ... what does this actually mean in the real world?
Say I have a password list with 10000 accounts, they are all salted.. I'm still going to be able to recover thousands of passwords without much effort... still adds up to epic failure with or without salts.
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.
Symmetric keys are a much better idea than the dangerous delusion too many people seem to be subscribing to that clear
Re: (Score:2)
You can't save users who use 'aaaaaa' as a password. No matter what you do. Otherwise,
What about the user who uses 11elephant82 as their password? Are they doomed as well?
you're not going to recover thousands of strong passwords properly salted and hashed. It just isn't going to happen.
It will happen easily. The only thing that isn't *ever* happening is people using strong passwords relative to current and projected cost per transistor.
What are you going to protect with that symmetric key?
The password database? It'd still need to be accessible to the machine holding the database, in order to login.
Yes this is just punting responsibility for keeping a secret. Whether punted to physical keys, operating system keychain, TPM circuits or manual startup inputs all of these things do a better job than tens of thousands to millions of hashes stored in the clear on disk.
Re
Re: (Score:2)
I'm not sure you really understand how salting a password works.
There's never any point in "trivial" salt.
Salt is a public random value (randomly generated for each password), the same size as the hash. It's stored in plaintext alongside the hash.
To check the password, you hash <salt><password>. It's effectively impossible for <salt><password> to be in a table no matter what <password> is. It doesn't prevent brute-forcing the password in other ways of course.
I'm not sure what y
Re: (Score:2)
Perhaps you are unaware that a typical salt has historically been much smaller than a password. UNIX systems had a 12-bit salt, BSDi extended to 24 bits and earlier Linux systems had a salt of 48 bits. Only fairly recently has a salt of 128 bits come into use. Salts that were considered adequate in the past, should now be considered trivial.
The point of having a deep-deep-dark-secret password would be to permit the existing infrastructure of textual salted password files, but to augment that with an additio
Trivial to hack (Score:2)
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.
hunter2 (Score:2)
Quick someone mention the horse password thingy
Too many attempts, try again later. (Score:2)
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.
If your system really matters (Score:2)
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.
Re: (Score:2)
Biometrics sucks for authentication (Score:2)
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
No password can survive an offline attack (Score:2)
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
Re: (Score:3)
No password is complex enough to survive a brute-force attack.
Um, that's complete BS. I suggest you replace "No password is" with "Many passwords aren't". Most proofs in cryptography are based on assuming that you can convert a significant fraction of the Universe's resources into an attack on a given password/key. The idea is that the heat death of the Universe would happen sooner than a brute force attack.
The way we decrease the time needed to attack a given algorithm is by finding a flaw in the algorithm which reduces that complexity. A blanket statement that "no p
Don't manage passwords (Score:2)
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.
Offline vs online (Score:2)
WHY IS THE INTERNET FOCUSED ON THIS SHIT (Score:2)
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
Re: (Score:3)
Because if the password is hard to remember, chances are the user has it written on a piece of paper or a note somewhere..
Normal passwords don't tend to suffer from this problem.
If the super-complex password requires causes the user to write it down or store it on their phone or such, it is hurting security --- not helping it.
Re: (Score:2)
I've personally reverted to pattern based passwords now, they feel quite ingenious to me and simple to type but none the less they are probably not ideally secure. They are a breeze to input and get past idiot systems though
Example
567tyughjbnm%^&TYUGHJBNM
Try typing that, I can do it in about 1 second. :/
I shouldn't have to do that though and if you asked me to verbally recite my password to you, or type it into an android keypad or something not laid out identically to a standard PC 101? Yeah, I'd have trouble
Re: (Score:2)
Hah!
I used the same password all over. Fortunately I now know better.
allow all characters, always (Score:2)
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 sp
NTLM and LANMAN (Score:3)
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.
not news (Score:3)
Me and other security experts have been saying such things for years [dfn-cert.de].
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.
Re: (Score:3)
Because everyone writes absolutely perfect code, no one ever loses anything, and there are no exploits out there.
No, because there is a difference between looking for the perfect castle and realizing that maybe having a wall isn't so stupid and closing the door and night isn't a bad idea, either.
Making brute force attacks difficult is not a question of perfect code. It's a question of not allowing unlimited tries at unlimited speed (online) or not storing unsalted password hashes (offline). It's not a matter of protecting your server from compromise. A serious defense strategy always includes the assumption that sever
Re: (Score:2)
My very secure password, is well over 100 bits of entropy. Easily extendable when the time comes.
But that is not the problem. We're using a Secret for single factor identification. Real identification is multi-factor and requires non-secret means for identity, and then a secret for proof of identity. Non-secret identification requires a web of trust. Online systems have neither non-secret web of trust Identification nor proper secret proof of Identification.
Re: (Score:2)
requires non-secret means for identity
Not exactly true. It can to be a secret that the user themselves don't know. Many (most? all?) keyfobs work that way. The fob itself has a secret that only it and the fob provider know. And in particular, its a secret that you as the fob user doesn't know.
Re: (Score:2)
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.
Even better, pick some song lyrics as your password -- especially lyrics you have wrong inside your head. That way the password can be really long and extremely difficult to guess. Add in spaces and punctuation and it's even better:
would make an excellent password. And It's really easy to remember. Much easier than something akin to correcthorsebatterystaple [xkcd.com]
Re: (Score:2)
Because all password applications and databases have the same limitations and configuration
Many systems in use have similar "limitations and configuration".
which can never be modified.
Many systems in use "can never be modified" by end users.
Re: (Score:2)
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.
Re: (Score:3)
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 produc
Re: (Score:2)
Hopefully not ones from HID if you want any actual security.
Re: (Score:2)
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.
Re: (Score:2)
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 persi
Re: Passwords should not exist (Score:5, Interesting)
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.
Re: (Score:3)
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 yo
Re: (Score:3)
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
Re: (Score:2)
> 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.
Re: (Score:2)
> 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
Re: Passwords should not exist (Score:4, Insightful)
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.
Re: (Score:3)
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 pass
Re: (Score:2)
Because people like you still link to that shitty comic that's been debunked over and over and over.
Re: (Score:3, Insightful)
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 yo
Re: (Score:2)
replace 1 letter in each word with a number and use numbers as spacers, problem solved
Re: (Score:2)
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 th
Re: (Score:3)
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 m
Key stretching with PBKDF2 (Score:2)
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.
Re: (Score:2)
That's a great comic! If only people checked that the phrase being used were unconnected with them far far better system.
Re: (Score:2)
If the database can be stolen, then that, in itself, IS the problem.
Re: (Score:2)
$ pwgen -N 3 -y -s 20
Q^lu)bgREy3c$OH5PmGI 95Q~\\1?"W#S9*yDa1)A c0UX4]?e$1{WjM3N7inI
Re: (Score:2)
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 "p
Re: (Score:2)
Re: (Score:2)
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.