I have like 12 eff’ing passwords at work, and some of them have different rule requirements, and a restriction that they must be changed every 30 days, and you can never reuse the same one. I am not a goddamn savant, people. The only thing that brings my piss to a boil more is spam, and when the f-lock key resets every time I reboot.
I have like 12 eff’ing passwords at work, and some of them have different rule requirements, and a restriction that they must be changed every 30 days, and you can never reuse the same one. I am not a goddamn savant, people.
+1
Given the number of systems I work on, I’ve given up trying to remember them. It was getting to the point where I was forced to get the passwords reset.
The worst case of this I’ve ever dealt was with one particular nightmare client. In order to connect to the corporate network over VPN, we needed a username, password AND a keyfob, but the account automatically expired after 24h. So we’d need to call in every morning to activate new personal credentials for the day. The VPN automatically disconnected every single god damn hour so we’d need to repeat the password/keyfob process, and in the meantime we’d loose all our active connections.
You’d think this was for some top secret operation, but no it was just some probes and a server on an isolated network with benign temperature data on it. The whole thing was overzealous IT policy. I complained strongly to absolutely no avail. Then they complained about the bill, what the hell do they expect, there’s no way for contractors to work efficiently under their IT policy! I wonder if they fixed it or there’s still some poor SOB pounding his head into the wall every day.
I’m sure everyone has experienced terrible policies at some point in their carrier
Temperature data leads to climate change proof. Climate change proof leads to regulation. Regulation leads to the dark side AKA lower profits. That can not be allowed!
Seriously though, their policy is absurd. It would be hard not to ask if they’re joking. At least there’s some solace in knowing you aren’t the only one, by a long shot, who has had to deal with that kind of nonsense.
Temperature data leads to climate change proof. Climate change proof leads to regulation. Regulation leads to the dark side AKA lower profits. That can not be allowed! [/q]
Haha
[q]Seriously though, their policy is absurd. It would be hard not to ask if they’re joking. At least there’s some solace in knowing you aren’t the only one, by a long shot, who has had to deal with that kind of nonsense.
It wasn’t a joke. When I complained, the project lead said he understood and that he would make sure they got it taken care of, but they just doubled down. It doesn’t make sense to me either, but I was just a contractor so maybe there were some office politics or maybe an audit I wasn’t privy to because it didn’t seem rational on it’s face. Anyways, we live through it and move on. To be perfectly honest most companies seem to go the other way around and don’t take security seriously enough.
I have like 12 eff’ing passwords at work, and some of them have different rule requirements, and a restriction
that they must be changed every 30 days, and you can
never reuse the same one.
It’s not “secure” unless it’s so hard for users to remember their password/s that they’re forced to write them on yellow sticky notes and stick them to the edge of the monitor. 😉
add to the fun situations where you sometimes need different keyboard layout and that causes login failures and account locks, because you forgot to switch to your native layout.
It’s a bit of an implementation detail, but make sure maximum password length is reasonable as well.
I’ve had several sites that silently truncate my saved password, but don’t truncate my entered password so I kept having to reset my password until I could deduce that they were silently cutting off the end of it. And then there’s that QuickBook’s database that would randomly corrupt on long admin passwords. Which they still haven’t fixed in the 2016 version. At least I was able to get one other developer to fix their problems with long passwords, though that was like pulling teeth to prove it to them.
The biggest passwords related headache is the minimum password age rule. I have never understood how it would increase security.
I can answer that. It is used in combination with “Last XX passwords remembered”. In most cases, you CAN re-use your old passwords, you just can’t re-use last XX number of passwords (since storage for password history is limited). So most policies only remember, let’s say last 15 passwords you used and you can re-use older ones. Now if there was no minimum password age, when your password expires, you could just change your password 15 times in a row in quick succession and then just re-use same password you used yesterday…
Now if there was no minimum password age, when your password expires, you could just change your password 15 times in a row in quick succession and then just re-use same password you used yesterday…
Why that choice is really stupid: Half of the people who call for a password reset can’t use a temporary password. So I have to give them a password that I can tell over a bad phoneline. After that I have to tell them to change it after 48 hours even though they often like the password I made for them. On top of that they don’t get a reminder to change the password. So a lot of people tell me 3 months after I helped them with a password reset that they filled in the correct password; the password I gave them…
Why that choice is really stupid: Half of the people who call for a password reset can’t use a temporary password. So I have to give them a password that I can tell over a bad phoneline. After that I have to tell them to change it after 48 hours even though they often like the password I made for them. On top of that they don’t get a reminder to change the password. So a lot of people tell me 3 months after I helped them with a password reset that they filled in the correct password; the password I gave them…
I agree. Never said it was a wise or even acceptable solution… Just explained why it exists.
I think we all agree that passwords are a bit of a pain in the arse with all these rules we’re forced to follow. Why not make the actual cracking more difficult by increasing the time between login attempts? After the first attempt you must wait two seconds before your next attempt, then four seconds, 8 seconds … As we all know the waiting time would become very large, very quickly.
Surely this would be easy to implement and very effective.
Yep, I’ve always wondered about that too. Trivial to implement, and would effectively stop brute force attacks dead without inconveniencing the average user – most people will only try 4 or 5 passwords at most before they ring support.
I think we all agree that passwords are a bit of a pain in the arse with all these rules we’re forced to follow. Why not make the actual cracking more difficult by increasing the time between login attempts? After the first attempt you must wait two seconds before your next attempt, then four seconds, 8 seconds … As we all know the waiting time would become very large, very quickly.
Surely this would be easy to implement and very effective.
You could implement something like this, but it doesn’t necessarily help against cases where the attackers bypass the authentication code by means of a privilege escalation vulnerability on the local machine. Many of the biggest leaks with millions of accounts at stake happen because the attackers managed to get local access. Hashing passwords can increase the cost of the attack, but if the passwords are short it’s still viable to brute force them “offline”.
Nevertheless, I agree online login attempts should be rate limited, however it’s not without cons since rate limiting can easily be exploited to create denial of service attacks against legitimate users through no fault of their own. If you only allow 3 failures every minute, then a hacker could prevent the legitimate user from logging in by using those up. If the delay increases exponentially then that makes the denial of service even more effective.
We can make the rate limiting more complex by tracking each login attempt per IP rather than per account, but that makes the protection much less effective against a distributed attack. So the problem turns out not to be so simple.
What I sometimes do is ban entire networks from which I detect brute forcing, however being overzealous can create false positives. Meanwhile the attackers often just continue from a new subnet, making it a game of IP wack-a-mole.
One time I redirected the attack to a honeypot that accepted any login. This fooled the hacker’s scripts into thinking they found a valid password and their brute forcing stopped. Presumably the bad login/password got added to their list, but it’s bad data so who cares; I won the wack-a-mole game by fooling the automated scripts into thinking they won, they weren’t designed to handle that. I wonder if this strategy could be packaged into a more generic solution.
Edit: I used to try to report these hackers with full packet traces to abuse@ISP, etc, but they usually don’t seem the least bit interested about abuse happening from their IPs. I think they’d rather accept the money and look the other way.
I think we all agree that passwords are a bit of a pain in the arse with all these rules we’re forced to follow. Why not make the actual cracking more difficult by increasing the time between login attempts? After the first attempt you must wait two seconds before your next attempt, then four seconds, 8 seconds … As we all know the waiting time would become very large, very quickly.
Surely this would be easy to implement and very effective.
My online bank gives you three attempts before imposing a 30 minute lockout.
I think we all agree that passwords are a bit of a pain in the arse with all these rules we’re forced to follow. Why not make the actual cracking more difficult by increasing the time between login attempts? After the first attempt you must wait two seconds before your next attempt, then four seconds, 8 seconds … As we all know the waiting time would become very large, very quickly.
Surely this would be easy to implement and very effective.
Are you kidding?.. No one uses online brute-force attack these days any more. Password guessing is used on offline dumps of password hashes, databases or any other type of offline/isolated data where it’s not possible to impose such delays.
Are you kidding?.. No one uses online brute-force attack these days any more. Password guessing is used on offline dumps of password hashes, databases or any other type of offline/isolated data where it’s not possible to impose such delays.
If you can get a DB dump, clearly that’s valuable to a hacker. However if you have a public facing server, take a look at your logs and you’ll probably see that someone is doing a brute force attack against it right now! It’s gotten worse, not better, I see this on every single one of my hosts at completely unrelated locations across all sorts of services too: ssh, smtp, administrative control panels, etc.
Is this more of a US-centric phenomenon?
Of course the risks of success are low if you’ve chosen sufficiently long passwords, but brute forcing logins are definitely still a thing.
If you can get a DB dump, clearly that’s valuable to a hacker. However if you have a public facing server, take a look at your logs and you’ll probably see that someone is doing a brute force attack against it right now! It’s gotten worse, not better, I see this on every single one of my hosts at completely unrelated locations across all sorts of services too: ssh, smtp, administrative control panels, etc.
Is this more of a US-centric phenomenon?
Of course the risks of success are low if you’ve chosen sufficiently long passwords, but brute forcing logins are definitely still a thing.
I agree regarding logs, but this kind of attack is not even worth attention at the moment since that is the dumbest kind of attack there is and also so easy to block (auto-ban the offending IP after XX number of failures) that I consider this trivial. Offline attacks are much more concerning and harder to prevent.
I agree regarding logs, but this kind of attack is not even worth attention at the moment since that is the dumbest kind of attack there is and also so easy to block (auto-ban the offending IP after XX number of failures) that I consider this trivial. [/q]
While you say it’s easy, it’s not something most daemons will do out of the box. What do you need to install (ie fail2ban). How does it cope with distributed attacks? How long before unbanning the source? Considering the source IP is likely to be another victim or a public access point, how do you handle that? Is it acceptable to punish innocent bystanders too? How do you fundamentally apply banning to IPv6 which has significantly more address space?
So personally I don’t think it is trivial, the subject merits attention.
[q]Offline attacks are much more concerning and harder to prevent.
I agree that a database leak can be very damaging, however the protections for passwords specifically are well known. They can be (and should be) protected with “salt”, which means that each and every user would have to be brute forced independently rather than as a combined set.
So for example: brute forcing passwords for every bank account in one go could be financially viable, whereas one by one would not be.
The other thing we can do is reiterate the hash an arbitrary number of times to multiply the time of brute forcing attempts. Iterating the hash 2000 times will make brute forcing 2000 times slower. In theory you could make it arbitrarily slow even for short passwords, however it also increases the computational power needed to authenticate a legitimate user.
So if it took one second to compute the millions of hashes needed to authenticate a user, it would become a prime target as a vector for an attacker to take down a server by starving it’s CPU resources with relatively little traffic.
Why would ’18atcskd2w’ and ‘3rjs1la7qe’ be among the 25 most used passwords? I’m presuming this is for the English-speaking world (as ‘qwertyuiop’ is among them but, for example, ‘azertyuiop’ isn’t), but I don’t get what those are corruptions of or stand for.
They are. Everyone needs to jump on the U2F bandwagon. Screw passwords to hell and back. USB dongle you insert, *boom* secure authent-freaking-cation.
Agree, a universal standard would address lots of problems. I like that U2F doesn’t rely on 3rd parties (like google or facebook or anyone else). Of course the problem is actually getting everyone to implement it natively without having to assume the user has to (or can) install other software.
Obviously google implemented it in chrome, but apple, ms, mozilla have not:
Even with installed apps, the NFC authenticators don’t work on IOS because apple bans users/devs from functionality that might be used to compete with apple pay. The technology works and has been possible for a very long time, but corporate control and infighting has created barriers to progress.
Yeah, stupidity often blocks the march of superior concepts. If I were a God King of technology, I would decree that it not be terrible and it would not.
U2F is still password based. It’s a public-key challenge-response mechanism, but the private key is still a password, and in fact, most password systems are technically almost public-key systems anyway (the hashed password that gets stored is essentially a public key). The only difference is that it’s physical hardware remembering it not a person, and user authorization is through a physical hardware button instead of a software button.
U2F by itself is better than traditional passwords, but it’s also designed to be part of an authentication system, not an authentication system itself. It has a number of issues, namely that it requires hardware that’s pretty easily lost or destroyed, and that it requires the user to functionally trust what amounts to a black-box (no good authentication system should require this).
U2F by itself is better than traditional passwords, but it’s also designed to be part of an authentication system, not an authentication system itself. It has a number of issues, namely that it requires hardware that’s pretty easily lost or destroyed, and that it requires the user to functionally trust what amounts to a black-box (no good authentication system should require this).
It’s the “something you know plus something you have” method of authentication. Sure, if you loose it, then that is a con, but I would argue that this con is outweighed by the benefits consolidating password schemes across myriads of services.
Don’t forget the problems being addressed are significant: remembering dozens of passwords sucks, using the same password across dozens of sites sucks, writing passwords down sucks, having dozens of key fobs/authentication devices sucks… So by process of elimination a consolidated authentication system seems to be the best solution.
And while I can agree something physical has it’s cons, I think it’s merits of a unified standard outweigh the negatives and I think most services using this would actually be safer for it too. The problem though is getting everyone on-board with a unified standard since we’ve been using the less secure passwords forever now and most companies are unaware and/or uninterested in making the investments.
No, No it isn’t. That’s an absurd contortion of the meaning of the concepts. Its like asking why humans aren’t on display in zoos.
[q]and that it requires the user to functionally trust what amounts to a black-box (no good authentication system should require this)
Not sure what you mean by this. Are you saying that the user won’t understand how the process works? Or that U2F doesn’t verify the Host?
As you said U2F Just like passwords, is part of an authentication system. The other parts of the authentication system are responsible for ensuring that you are aware or not if you are truly trying to authenticate with the right entity.
If you are complaining that users won’t understand the implementation details, well I’m at a loss. Users never understand how anything works. And most well designed things don’t require that they do. I think they are ok with some physical thing that gives them access to a resource. Much more like a key, which they understand.
As for the costs of maintaining a system, and dealing with lost keys, well I don’t have much experience with admining anything like that. But I wouldn’t think it would be that bad, but again I’d defer to others experiences.
No, No it isn’t. That’s an absurd contortion of the meaning of the concepts. Its like asking why humans aren’t on display in zoos. [/q]
No, a password can be anything. It’s just another word for an authentication token. The fact that it traditionally means a string of bytes entered and represented as text is simply a side-effect of classical hardware and software limitations. U2F is literally just public-key challenge-response authentication on a dedicated co-processor with physical authorization and hardware-level key sequestration. It’s a reasonably secure option, but the private key is still a password, and therefore, U2F is still password based.
Not sure what you mean by this. Are you saying that the user won’t understand how the process works? Or that U2F doesn’t verify the Host?
No, I mean that the user has to trust that the U2F hardware itself isn’t in some way compromised by design or otherwise malfunctioning with no way to verify that trust.
Put slightly differently, if you’re just using a password, you have to trust:
1. Your computer hardware.
2. Your OS
3. Your antivirus/antimalware software
4. Your Web Browser.
5. Any other software you might have running at the time.
6. The service itself.
If you’re using U2F, that becomes:
1. Your computer hardware.
2. The U2F device hardware.
3. Your OS. (toa greater degree because you’re using more of it).
4. Your antivirus/antimalware software.
5. Your web browser (to a greater degree, because again you’re using more of it).
6. Any other software you might have running at the time.
7. The service itself.
The situation is pretty similar for any other hardware security device. You add the requirement of trust in that particular piece of hardware, as well as increasing the required trust in other parts of the authentication path. On top of that, the additional hardware you have to trust is functionally impossible to examine in any way to determine if it’s actually working the way it’s supposed to. This is part of why the TPM never caught on all that well for this type of thing despite the fact that it would provide pretty much the same functionality without the need for extra hardware outside of the system. It requires the same extended degree of trust in other components, as well as being a functional black-box that couldn’t be realistically verified.
[q]As for the costs of maintaining a system, and dealing with lost keys, well I don’t have much experience with admining anything like that. But I wouldn’t think it would be that bad, but again I’d defer to others experiences.
In a corporate environment where you have centralized IT administration, it’s actually pretty easy (assuming you have reasonable funding). That’s not the environment I’m worried about though, because many corporate environments are already doing things similar to this with Smart Cards or Yubikeys (or some other hardware authentication token). What I’m worried about is the home users, where it is a nightmare to properly handle (largely because of how most websites decide to handle password resets). In essence, until people start better authenticating password resets for public services (and ensuring the reset e-mails/texts/whatever don’t ever go over unencrypted channels), there is functionally an upper limit to how secure anything in such an environment can be, and U2F doesn’t really raise that bar all that much unless the service requires it’s usage (which in turn causes all kinds of other issues).
No, a password can be anything. It’s just another word for an authentication token. The fact that it traditionally means a string of bytes entered and represented as text is simply a side-effect of classical hardware and software limitations. U2F is literally just public-key challenge-response authentication on a dedicated co-processor with physical authorization and hardware-level key sequestration. It’s a reasonably secure option, but the private key is still a password, and therefore, U2F is still password based.
… [/q]
You are right it does not protect the “something you know”, rather it’s intended to be “something you have”. PKI does add some security benefits that we can’t get with just a password, they’re not the same thing.
With a normal password (ie something I know) successful attackers will have all our credentials and will be able to continue to have access unbeknownst to us.
With PKI authentication and hardware key (something we have) the attackers will only obtain our passwords (what we know), but they still lack the hardware key required to pass authentication.
Now it’s possible for both our password and hardware key to be stolen by the same attackers, in which case the security is broken, but at least the owner should be be alerted to the fact that the physical security device was stolen.
The idea here is that “something you have” + “something you know” is more secure than just “something you know”, which is what virtually all ordinary websites today use. The security of the vast majority of websites would go up while also making it easier for users to login to all their accounts.
[q]The situation is pretty similar for any other hardware security device. You add the requirement of trust in that particular piece of hardware, as well as increasing the required trust in other parts of the authentication path.
Granted, you always have to trust the manufacturer for any hardware you use. Hopefully it’s all open source and the manufacturer faithfully implements the spec.
Nice in theory except… do you want to be the one to keep replacing everyone’s lost USB key, especially considering how often they lose something so important as their house keys? I can only imagine the nightmare that would be for any IT department. It’s bad enough with smart cards already.
And before anyone suggests it, a password manager is not a solution. Hiding ultra-complex passwords behind one that isn’t quite so complex is stupid, especially when one considers that now, the attackers only need to get one password to rule them all. The whole system is out of control, and the solutions are so simple! A phrase, coupled with an escalating lockout timer with a finite limit before the account is hard-locked, would quickly bring this problem under control.
So go ahead and use a phrase. If the password field is hashed as it should be, then the length of your password should be mostly arbitrary (within reason). Whether it’s 10 or 1000 characters long, it can be hashed to the same 16-32 bytes for everyone. I think the theme of this article is that some password implementations are overly restrictive, that’s true.
That said, even if there were no issues with password field restrictions, we can’t ignore that password management itself is still a problem for humans when you have so many accounts.
Sometimes I don’t even remember the username, much less the password/passphrase. A well secured password manager is going to beat the security of any adhoc password management that the user comes up on their own (ie writing them down).
As for the criticism of putting all eggs in one basket: just because you use a password manager doesn’t mean you’re forced to use a single lock, it would really be up to you, the user, to determine how many baskets you need.
Why are we so freaking obsessed with passwords? This isn’t the decade of DOS or TOPS-20. There’s this magic thing called a space, and with it, we could even have passphrases or sentences. Much, much harder to crack and much easier to remember. Yet no, it has to be one long string of uninterrupted jibberish that no one could possibly remember.
And before anyone suggests it, a password manager is not a solution. Hiding ultra-complex passwords behind one that isn’t quite so complex is stupid, especially when one considers that now, the attackers only need to get one password to rule them all. The whole system is out of control, and the solutions are so simple! A phrase, coupled with an escalating lockout timer with a finite limit before the account is hard-locked, would quickly bring this problem under control.
I actually do use a passphrase for my SSH and GPG keys — it’s a section from a song, and I bookmarked the page where the lyrics were so I could copy and paste them. But at one point those services started using dialog boxes for pin entry (even where SSH was invoked from a command-line utility such as Git) which don’t accept copy and paste, and manually typing the lyrics wasn’t possible as I couldn’t see them, so I couldn’t tell where I’d made mistakes. In the end I used ssh-add so I could still copy and paste it into the terminal, but pass phrases as opposed to words are more error prone for the user.
https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-…
I have like 12 eff’ing passwords at work, and some of them have different rule requirements, and a restriction that they must be changed every 30 days, and you can never reuse the same one. I am not a goddamn savant, people. The only thing that brings my piss to a boil more is spam, and when the f-lock key resets every time I reboot.
Edited 2017-03-11 02:13 UTC
WorknMan,
+1
Given the number of systems I work on, I’ve given up trying to remember them. It was getting to the point where I was forced to get the passwords reset.
The worst case of this I’ve ever dealt was with one particular nightmare client. In order to connect to the corporate network over VPN, we needed a username, password AND a keyfob, but the account automatically expired after 24h. So we’d need to call in every morning to activate new personal credentials for the day. The VPN automatically disconnected every single god damn hour so we’d need to repeat the password/keyfob process, and in the meantime we’d loose all our active connections.
You’d think this was for some top secret operation, but no it was just some probes and a server on an isolated network with benign temperature data on it. The whole thing was overzealous IT policy. I complained strongly to absolutely no avail. Then they complained about the bill, what the hell do they expect, there’s no way for contractors to work efficiently under their IT policy! I wonder if they fixed it or there’s still some poor SOB pounding his head into the wall every day.
I’m sure everyone has experienced terrible policies at some point in their carrier
Edited 2017-03-11 03:33 UTC
Temperature data leads to climate change proof. Climate change proof leads to regulation. Regulation leads to the dark side AKA lower profits. That can not be allowed!
Seriously though, their policy is absurd. It would be hard not to ask if they’re joking. At least there’s some solace in knowing you aren’t the only one, by a long shot, who has had to deal with that kind of nonsense.
ilovebeer,
It wasn’t a joke. When I complained, the project lead said he understood and that he would make sure they got it taken care of, but they just doubled down. It doesn’t make sense to me either, but I was just a contractor so maybe there were some office politics or maybe an audit I wasn’t privy to because it didn’t seem rational on it’s face. Anyways, we live through it and move on. To be perfectly honest most companies seem to go the other way around and don’t take security seriously enough.
Hi,
It’s not “secure” unless it’s so hard for users to remember their password/s that they’re forced to write them on yellow sticky notes and stick them to the edge of the monitor. 😉
– Brendan
add to the fun situations where you sometimes need different keyboard layout and that causes login failures and account locks, because you forgot to switch to your native layout.
Can’t agree with this part more!
It’s a bit of an implementation detail, but make sure maximum password length is reasonable as well.
I’ve had several sites that silently truncate my saved password, but don’t truncate my entered password so I kept having to reset my password until I could deduce that they were silently cutting off the end of it. And then there’s that QuickBook’s database that would randomly corrupt on long admin passwords. Which they still haven’t fixed in the 2016 version. At least I was able to get one other developer to fix their problems with long passwords, though that was like pulling teeth to prove it to them.
Read this, which uses less profanity, and is appropriate for passing along to management:
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules…
The biggest passwords related headache is the minimum password age rule. I have never understood how it would increase security.
Edited 2017-03-11 07:14 UTC
I can answer that. It is used in combination with “Last XX passwords remembered”. In most cases, you CAN re-use your old passwords, you just can’t re-use last XX number of passwords (since storage for password history is limited). So most policies only remember, let’s say last 15 passwords you used and you can re-use older ones. Now if there was no minimum password age, when your password expires, you could just change your password 15 times in a row in quick succession and then just re-use same password you used yesterday…
Why that choice is really stupid: Half of the people who call for a password reset can’t use a temporary password. So I have to give them a password that I can tell over a bad phoneline. After that I have to tell them to change it after 48 hours even though they often like the password I made for them. On top of that they don’t get a reminder to change the password. So a lot of people tell me 3 months after I helped them with a password reset that they filled in the correct password; the password I gave them…
I agree. Never said it was a wise or even acceptable solution… Just explained why it exists.
easy way to protect your password visit here
http://www.unblockedhappywheels.com/
Edited 2017-03-11 16:45 UTC
I think we all agree that passwords are a bit of a pain in the arse with all these rules we’re forced to follow. Why not make the actual cracking more difficult by increasing the time between login attempts? After the first attempt you must wait two seconds before your next attempt, then four seconds, 8 seconds … As we all know the waiting time would become very large, very quickly.
Surely this would be easy to implement and very effective.
Yep, I’ve always wondered about that too. Trivial to implement, and would effectively stop brute force attacks dead without inconveniencing the average user – most people will only try 4 or 5 passwords at most before they ring support.
waynej,
You could implement something like this, but it doesn’t necessarily help against cases where the attackers bypass the authentication code by means of a privilege escalation vulnerability on the local machine. Many of the biggest leaks with millions of accounts at stake happen because the attackers managed to get local access. Hashing passwords can increase the cost of the attack, but if the passwords are short it’s still viable to brute force them “offline”.
Nevertheless, I agree online login attempts should be rate limited, however it’s not without cons since rate limiting can easily be exploited to create denial of service attacks against legitimate users through no fault of their own. If you only allow 3 failures every minute, then a hacker could prevent the legitimate user from logging in by using those up. If the delay increases exponentially then that makes the denial of service even more effective.
We can make the rate limiting more complex by tracking each login attempt per IP rather than per account, but that makes the protection much less effective against a distributed attack. So the problem turns out not to be so simple.
What I sometimes do is ban entire networks from which I detect brute forcing, however being overzealous can create false positives. Meanwhile the attackers often just continue from a new subnet, making it a game of IP wack-a-mole.
One time I redirected the attack to a honeypot that accepted any login. This fooled the hacker’s scripts into thinking they found a valid password and their brute forcing stopped. Presumably the bad login/password got added to their list, but it’s bad data so who cares; I won the wack-a-mole game by fooling the automated scripts into thinking they won, they weren’t designed to handle that. I wonder if this strategy could be packaged into a more generic solution.
Edit: I used to try to report these hackers with full packet traces to abuse@ISP, etc, but they usually don’t seem the least bit interested about abuse happening from their IPs. I think they’d rather accept the money and look the other way.
Edited 2017-03-11 20:52 UTC
Thanks for the response. I’d always wondered why it wasn’t implement widely, but that makes sense. Cheers.
My online bank gives you three attempts before imposing a 30 minute lockout.
Are you kidding?.. No one uses online brute-force attack these days any more. Password guessing is used on offline dumps of password hashes, databases or any other type of offline/isolated data where it’s not possible to impose such delays.
FooBat,
If you can get a DB dump, clearly that’s valuable to a hacker. However if you have a public facing server, take a look at your logs and you’ll probably see that someone is doing a brute force attack against it right now! It’s gotten worse, not better, I see this on every single one of my hosts at completely unrelated locations across all sorts of services too: ssh, smtp, administrative control panels, etc.
Is this more of a US-centric phenomenon?
Of course the risks of success are low if you’ve chosen sufficiently long passwords, but brute forcing logins are definitely still a thing.
I agree regarding logs, but this kind of attack is not even worth attention at the moment since that is the dumbest kind of attack there is and also so easy to block (auto-ban the offending IP after XX number of failures) that I consider this trivial. Offline attacks are much more concerning and harder to prevent.
FooBat,
I agree that a database leak can be very damaging, however the protections for passwords specifically are well known. They can be (and should be) protected with “salt”, which means that each and every user would have to be brute forced independently rather than as a combined set.
So for example: brute forcing passwords for every bank account in one go could be financially viable, whereas one by one would not be.
The other thing we can do is reiterate the hash an arbitrary number of times to multiply the time of brute forcing attempts. Iterating the hash 2000 times will make brute forcing 2000 times slower. In theory you could make it arbitrarily slow even for short passwords, however it also increases the computational power needed to authenticate a legitimate user.
So if it took one second to compute the millions of hashes needed to authenticate a user, it would become a prime target as a vector for an attacker to take down a server by starving it’s CPU resources with relatively little traffic.
Why would ’18atcskd2w’ and ‘3rjs1la7qe’ be among the 25 most used passwords? I’m presuming this is for the English-speaking world (as ‘qwertyuiop’ is among them but, for example, ‘azertyuiop’ isn’t), but I don’t get what those are corruptions of or stand for.
http://www.gizmodo.co.uk/2017/01/2016-top-passwords/
Correct title should be:
“Passwords are Bullshit”
They are. Everyone needs to jump on the U2F bandwagon. Screw passwords to hell and back. USB dongle you insert, *boom* secure authent-freaking-cation.
Bill Shooter of Bul,
Agree, a universal standard would address lots of problems. I like that U2F doesn’t rely on 3rd parties (like google or facebook or anyone else). Of course the problem is actually getting everyone to implement it natively without having to assume the user has to (or can) install other software.
Obviously google implemented it in chrome, but apple, ms, mozilla have not:
https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
Even with installed apps, the NFC authenticators don’t work on IOS because apple bans users/devs from functionality that might be used to compete with apple pay. The technology works and has been possible for a very long time, but corporate control and infighting has created barriers to progress.
Edited 2017-03-12 06:55 UTC
Yeah, stupidity often blocks the march of superior concepts. If I were a God King of technology, I would decree that it not be terrible and it would not.
Hey, guess what!
U2F is still password based. It’s a public-key challenge-response mechanism, but the private key is still a password, and in fact, most password systems are technically almost public-key systems anyway (the hashed password that gets stored is essentially a public key). The only difference is that it’s physical hardware remembering it not a person, and user authorization is through a physical hardware button instead of a software button.
U2F by itself is better than traditional passwords, but it’s also designed to be part of an authentication system, not an authentication system itself. It has a number of issues, namely that it requires hardware that’s pretty easily lost or destroyed, and that it requires the user to functionally trust what amounts to a black-box (no good authentication system should require this).
ahferroin7,
It’s the “something you know plus something you have” method of authentication. Sure, if you loose it, then that is a con, but I would argue that this con is outweighed by the benefits consolidating password schemes across myriads of services.
Don’t forget the problems being addressed are significant: remembering dozens of passwords sucks, using the same password across dozens of sites sucks, writing passwords down sucks, having dozens of key fobs/authentication devices sucks… So by process of elimination a consolidated authentication system seems to be the best solution.
And while I can agree something physical has it’s cons, I think it’s merits of a unified standard outweigh the negatives and I think most services using this would actually be safer for it too. The problem though is getting everyone on-board with a unified standard since we’ve been using the less secure passwords forever now and most companies are unaware and/or uninterested in making the investments.
Not sure what you mean by this. Are you saying that the user won’t understand how the process works? Or that U2F doesn’t verify the Host?
As you said U2F Just like passwords, is part of an authentication system. The other parts of the authentication system are responsible for ensuring that you are aware or not if you are truly trying to authenticate with the right entity.
If you are complaining that users won’t understand the implementation details, well I’m at a loss. Users never understand how anything works. And most well designed things don’t require that they do. I think they are ok with some physical thing that gives them access to a resource. Much more like a key, which they understand.
As for the costs of maintaining a system, and dealing with lost keys, well I don’t have much experience with admining anything like that. But I wouldn’t think it would be that bad, but again I’d defer to others experiences.
In a corporate environment where you have centralized IT administration, it’s actually pretty easy (assuming you have reasonable funding). That’s not the environment I’m worried about though, because many corporate environments are already doing things similar to this with Smart Cards or Yubikeys (or some other hardware authentication token). What I’m worried about is the home users, where it is a nightmare to properly handle (largely because of how most websites decide to handle password resets). In essence, until people start better authenticating password resets for public services (and ensuring the reset e-mails/texts/whatever don’t ever go over unencrypted channels), there is functionally an upper limit to how secure anything in such an environment can be, and U2F doesn’t really raise that bar all that much unless the service requires it’s usage (which in turn causes all kinds of other issues).
ahferroin7,
Granted, you always have to trust the manufacturer for any hardware you use. Hopefully it’s all open source and the manufacturer faithfully implements the spec.
Nice in theory except… do you want to be the one to keep replacing everyone’s lost USB key, especially considering how often they lose something so important as their house keys? I can only imagine the nightmare that would be for any IT department. It’s bad enough with smart cards already.
darknexus,
So go ahead and use a phrase. If the password field is hashed as it should be, then the length of your password should be mostly arbitrary (within reason). Whether it’s 10 or 1000 characters long, it can be hashed to the same 16-32 bytes for everyone. I think the theme of this article is that some password implementations are overly restrictive, that’s true.
That said, even if there were no issues with password field restrictions, we can’t ignore that password management itself is still a problem for humans when you have so many accounts.
Sometimes I don’t even remember the username, much less the password/passphrase. A well secured password manager is going to beat the security of any adhoc password management that the user comes up on their own (ie writing them down).
As for the criticism of putting all eggs in one basket: just because you use a password manager doesn’t mean you’re forced to use a single lock, it would really be up to you, the user, to determine how many baskets you need.
So, everyone and his brother agrees that passwords are bad.
Yet – replacements (for passwords) aren’t coming anytime soon.
Because everyone has their own (different) idea about a replacement?
Why are we so freaking obsessed with passwords? This isn’t the decade of DOS or TOPS-20. There’s this magic thing called a space, and with it, we could even have passphrases or sentences. Much, much harder to crack and much easier to remember. Yet no, it has to be one long string of uninterrupted jibberish that no one could possibly remember.
And before anyone suggests it, a password manager is not a solution. Hiding ultra-complex passwords behind one that isn’t quite so complex is stupid, especially when one considers that now, the attackers only need to get one password to rule them all. The whole system is out of control, and the solutions are so simple! A phrase, coupled with an escalating lockout timer with a finite limit before the account is hard-locked, would quickly bring this problem under control.
I actually do use a passphrase for my SSH and GPG keys — it’s a section from a song, and I bookmarked the page where the lyrics were so I could copy and paste them. But at one point those services started using dialog boxes for pin entry (even where SSH was invoked from a command-line utility such as Git) which don’t accept copy and paste, and manually typing the lyrics wasn’t possible as I couldn’t see them, so I couldn’t tell where I’d made mistakes. In the end I used ssh-add so I could still copy and paste it into the terminal, but pass phrases as opposed to words are more error prone for the user.