The problem is that there are billions of existing USB devices and cables that will need adapters and new cables to work with new Type-C devices. It’s a lot like when Apple released the Lightning connector, but on an even grander scale.
What problem? My existing micro-usb devices won't need adapters, new devices with Type-C connectors will come with Type-C to Type-A cables, and when desktops/laptops start to come with Type-C connectors I'll just buy some new cables.
It's the same situation when micro-usb replaced mini-usb, I don't remember there being a problem on a "grand scale" then either.
If the attacker is performing the attack "offline" then you've already lost the security battle. That's the point. If you lose your password database, assume the passwords are all broken, no matter whether you have "must have 3.2 uppercase and 4.35 lowercase letters, 0.6 special characters and as many numbers as you like, so long as it doesn't start or end with a number" rules or let them use plain English sentences.
The point is a decent password scheme will make brute force attacks a lot more difficult. Relying only on "never getting hacked" isn't a good policy, so taking a complete approach to security as a whole (such as also coming up with a better password scheme) will always be better than only concentrating on one aspect. Coming up with a password scheme that is both more secure and easy to remember is one of the big unsolved IT security problems of course.
A hashed " " is as meaningful as a hashed "a" so "cat dog run fast" is better than a very random 8-char password.
Not quite, according to Randall 4 common words has an entropy of 44 bits (as long as they are chosen randomly). 8 random characters (uppercase, lowercase, numbers) has around 47.6 bits of entropy. If you have GPU that can chew through hundreds of millions of hashes a second (the record is 350 billion/sec for a 25 GPU cluster) you'd still ideally want more entropy than that though.
You are making a lot of assumptions there; but, ok, I guess...
There are no assumptions here, it's well known that a high percentage of users reuse the same password for multiple sites, including their email. Therefore if you crack an average user's account on a site you've got a good chance of also having their email address password. Obviously having control of someone's email is ground zero as far as getting account credentials is concerned, but even if they use a different password for email there could be connected sites (such as the Sony example in the link) that many users use the same login for, so a breach in a "low importance" service could expose users on more important service from the same company.
Your "solution" is poorly thought out and is why nobody does it that way
Banks will lock you out on the 2nd or 3rd failed attempt. A quick Google finds plenty of sites like Paddy Power and Yahoo lock accounts after a few bad password entries.
Most sites at least switch to a captcha after several failed logins too.
You should still only allow a certain number of failed login attempts for a given username. Sure it's rare to brute force via an online login, but it's worth doing to protect a user's account. Sure it sucks for that individual user to have the small possibility of being locked out their account temporarily, but it's not as bad as losing their account and also discourages any hacker from hammering your server and sending your entire site down in an actual DOS.
I fully understood what he put forth and repeatedly stated that it had no relation to the context of my original statement.
Sorry Desler you can't just say I was only talking about dictionary attacks on rate limited login portals, so no-one is allowed to talk about anything else, if you're going to mention dictionary attacks then attacking hashes will always be part of that discussion whether you want it to be or not.
Indeed, although whatever hashing scheme you have, having a password that's findable in a dictionary attack will always be much quicker than one that needs to be completely brute forced.
I really don't see how that's true, look at how the thread progressed -
AC1: "[We just need better passwords - eg. a complete sentence]"
AC2: "[That password could be broken by a dictionary attack]"
Desler: "Dictionary attacks can be trivially defeated by [rate] limiting"
Me: "Unless you have the password hash"
Desler: "(Insults)... But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all."
Me: "[Password hashes are one way only so still need to be attacked, weak passwords are susceptible to brute forcing the hash]"
Desler: "Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker."
Me: "[Rate limiting doesn't apply to brute force cracking of hashes]"
Desler: "(more insults) Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone."
Seriously, between him throwing insults and going on about rate limiting preventing brute forcing a hash, where have I misread what Desler said?
So, what if everyone used passwords like that? No doubt cracking scripts would change. But how is a dictionary attack going to work? They can't possibly put every parsable sentence of a language into a dictionary! The example sentence was 11 words. Even if we treated that as a limit, how many sentences can be made out of 11 or fewer words? Certainly there are far more possible 11-word sentences than there are 11 character passwords.
If that were the only password like it in a database that's true, but if we're suggesting a new password scheme that's adopted (like the XKCD several random words password) then a password made from a valid sentence like that would be easier to crack than a nonsense sentence.
As I originally responded to AC-x, if the attacker already has the hash and can then brute force it, of course what I mentioned doesn't stop them, but that scenario is no different than knowing their phone's PIN and being able to side step any of the very same protections I mentioned that phone OSes use which is to use a lock-out after a certain number of failed attempts.
As I've had to point out many times knowing the hash is very different to knowing a pin code. Seriously here's an SHA1 hash, can you reverse it? b6faa93a9e6ca445875c6b5511e2153bb51ef43a
The point you've been missing from the original AC's post is that some password schemes are much easier to brute force (eg. with a dictionary attack) than others. That's completely separate to rate limiting online logins and password resets etc.
But the real point is that's got nothing to do with having a password scheme strong enough to defeat a dictionary attack, which is what the AC above posted about.
In theory password hashes can be uncrackable, in practise most people pick passwords that can be cracked using a dictionary attack.
Coming up with a password scheme that is easier for people to remember but more difficult to brute force would be a huge step forward in IT security, and more useful than relying on all websites to never leak password hashes.
Nope, because I never claimed that. You misunderstood my point and started falsely assuming things
Yes you did:
"But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all." - No, you still need to attack (brute force) the hash to extract the password.
"Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary." - As written by you direct reply to a post about having the hash of a password, and is completely irrelevant if you have a hash.
Of course it is predicated on knowing you've been attacked. I was pretty sure that would be quite obvious.
The point is having a strong (not dictionary attackable) is preferable as it protects against password cracking proactively. Resetting a user's password after a hack is simply not as good as having a strong password that can't be cracked.
You've basically have been twisting my words into something I never stated or implied and then have applied them to scenarios outside of what I originally responded to. At this point I'm simply just going to ignore you.
Do you notice that nowhere in that quoted statement is there anything about the attacker performing a dictionary attack using online login attempts?
It's rare for someone to attempt an online dictionary attack because it's slow and obvious. My post that, in the more likely real-world scenario of hackers having the password hashes, passwords are still vulnerable to (offline) dictionary attacks is absolutely true. To think that rate limiting of online logins can defeat dictionary attacks is foolhardy...
By your previous posts it seemed you needed things put in simple terms, especially since you claimed that 1) knowing the hash is the same as knowing the password (it's not) and 2) rate limiting could defeat offline password cracking (it can't). Do you stand by those claims?
Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone.
That's no solution: 1) Relies on the attack being detected in the first place. 2) If the user has reused their password elsewhere this doesn't reset those too. It's also completely irrelevant to the question of being able to dictionary attack a password.
Hey Desler I really don't get you, you (appear to) know what a salt is yet you don't understand that an attacker would be performing the attack on the hash offline, with their own hardware. Rate limiting their own hardware would be, as you put it, the height of idiocy.
You probably shouldn't try to write about things you don't know about or understand.
1. The industry accepted way to store passwords securely in a database is with a one-way, salted cryptographic hash (using as CPU intensive algorithm as possible).
2. Many organisations have had database intrusions where these password hashes have been stolen (eg. eBay, Linkedin, LivingSocial etc.)
3. When this happens (i.e. "they have a copy of the password hash") passwords can be cracked offline. Strong passwords are safe (too hard to brute force), but weak passwords can be found using a dictionary attack.
4. Once the password is found offline a hacker can log straight in to the victim's online account with a single password attempt.
You seem to have no clue what a password hash actually is. The whole point of a cryptographic hash is it's one way operation; You can turn a password into a hash easily, but you can't turn a hash into a password without brute forcing it.
Having a hash of a sufficiently string password is perfectly safe, in fact here's one now, bet you can't find the password from it. It's a basic SHA1 hash, not even salted: b6faa93a9e6ca445875c6b5511e2153bb51ef43a
However if a chosen password appears in a password dictionary than you can cut down your brute force search space by so much it goes from taking years (even centuries) to crack a password to taking a few hours (sometimes minutes).
"entirely new CPU architecture" ? The A7 uses a 64 bit variant of ARM. If you want a mobile OS that's been ported to completely different CPU architectures then look at Android; It supports ARM, MIPS and x86. They can even run the same apps.
Yeah, I hope that's a joke, because I did a survey of people in the smoking area of a bar and found that 19 out of 20 of them smoked. Extrapolated to the population of Earth that makes 6.7 billion smokers...
I have to say that Google certainly left my Nexus S in bad shape, they updated it all the way to 4.1.2 which was too resource heavy for it, then didn't update it to 4.2 which contained a bunch of performance improvements that the NS badly needed! I've been on a close to stock custom rom since then, and every major release has improved it until it's now very usable on KitKat.
Obviously in the mean time I upgraded, but it still makes a very usable 2nd phone running KK.
Slashdot Mirror
HTML5? You don't need HTML5 to animate a few divs moving around, hell it'd be easy enough to make something that works as far back as IE6.
The problem is that there are billions of existing USB devices and cables that will need adapters and new cables to work with new Type-C devices. It’s a lot like when Apple released the Lightning connector, but on an even grander scale.
What problem? My existing micro-usb devices won't need adapters, new devices with Type-C connectors will come with Type-C to Type-A cables, and when desktops/laptops start to come with Type-C connectors I'll just buy some new cables.
It's the same situation when micro-usb replaced mini-usb, I don't remember there being a problem on a "grand scale" then either.
If the attacker is performing the attack "offline" then you've already lost the security battle. That's the point. If you lose your password database, assume the passwords are all broken, no matter whether you have "must have 3.2 uppercase and 4.35 lowercase letters, 0.6 special characters and as many numbers as you like, so long as it doesn't start or end with a number" rules or let them use plain English sentences.
The point is a decent password scheme will make brute force attacks a lot more difficult. Relying only on "never getting hacked" isn't a good policy, so taking a complete approach to security as a whole (such as also coming up with a better password scheme) will always be better than only concentrating on one aspect. Coming up with a password scheme that is both more secure and easy to remember is one of the big unsolved IT security problems of course.
A hashed " " is as meaningful as a hashed "a" so "cat dog run fast" is better than a very random 8-char password.
Not quite, according to Randall 4 common words has an entropy of 44 bits (as long as they are chosen randomly). 8 random characters (uppercase, lowercase, numbers) has around 47.6 bits of entropy. If you have GPU that can chew through hundreds of millions of hashes a second (the record is 350 billion/sec for a 25 GPU cluster) you'd still ideally want more entropy than that though.
You are making a lot of assumptions there; but, ok, I guess...
There are no assumptions here, it's well known that a high percentage of users reuse the same password for multiple sites, including their email. Therefore if you crack an average user's account on a site you've got a good chance of also having their email address password. Obviously having control of someone's email is ground zero as far as getting account credentials is concerned, but even if they use a different password for email there could be connected sites (such as the Sony example in the link) that many users use the same login for, so a breach in a "low importance" service could expose users on more important service from the same company.
Your "solution" is poorly thought out and is why nobody does it that way
Banks will lock you out on the 2nd or 3rd failed attempt. A quick Google finds plenty of sites like Paddy Power and Yahoo lock accounts after a few bad password entries.
Most sites at least switch to a captcha after several failed logins too.
You should still only allow a certain number of failed login attempts for a given username. Sure it's rare to brute force via an online login, but it's worth doing to protect a user's account. Sure it sucks for that individual user to have the small possibility of being locked out their account temporarily, but it's not as bad as losing their account and also discourages any hacker from hammering your server and sending your entire site down in an actual DOS.
So, how does cracking a password on one site gain you any knowledge whatsoever as to where, in the vastness of the internet, that it was used again?
The email address they used to register is the obvious one. They may also have connected social media accounts to whatever site got hacked.
I fully understood what he put forth and repeatedly stated that it had no relation to the context of my original statement.
Sorry Desler you can't just say I was only talking about dictionary attacks on rate limited login portals, so no-one is allowed to talk about anything else, if you're going to mention dictionary attacks then attacking hashes will always be part of that discussion whether you want it to be or not.
Indeed, although whatever hashing scheme you have, having a password that's findable in a dictionary attack will always be much quicker than one that needs to be completely brute forced.
I really don't see how that's true, look at how the thread progressed -
AC1: "[We just need better passwords - eg. a complete sentence]"
AC2: "[That password could be broken by a dictionary attack]"
Desler: "Dictionary attacks can be trivially defeated by [rate] limiting"
Me: "Unless you have the password hash"
Desler: "(Insults) ... But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all."
Me: "[Password hashes are one way only so still need to be attacked, weak passwords are susceptible to brute forcing the hash]"
Desler: "Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker."
Me: "[Rate limiting doesn't apply to brute force cracking of hashes]"
Desler: "(more insults) Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone."
Seriously, between him throwing insults and going on about rate limiting preventing brute forcing a hash, where have I misread what Desler said?
So, what if everyone used passwords like that? No doubt cracking scripts would change. But how is a dictionary attack going to work? They can't possibly put every parsable sentence of a language into a dictionary! The example sentence was 11 words. Even if we treated that as a limit, how many sentences can be made out of 11 or fewer words? Certainly there are far more possible 11-word sentences than there are 11 character passwords.
If that were the only password like it in a database that's true, but if we're suggesting a new password scheme that's adopted (like the XKCD several random words password) then a password made from a valid sentence like that would be easier to crack than a nonsense sentence.
The problem with that scheme is if you let users pick their own passwords they tend to follow certain patterns that make them easier to brute force.
As I originally responded to AC-x, if the attacker already has the hash and can then brute force it, of course what I mentioned doesn't stop them, but that scenario is no different than knowing their phone's PIN and being able to side step any of the very same protections I mentioned that phone OSes use which is to use a lock-out after a certain number of failed attempts.
As I've had to point out many times knowing the hash is very different to knowing a pin code. Seriously here's an SHA1 hash, can you reverse it? b6faa93a9e6ca445875c6b5511e2153bb51ef43a
The point you've been missing from the original AC's post is that some password schemes are much easier to brute force (eg. with a dictionary attack) than others. That's completely separate to rate limiting online logins and password resets etc.
But the real point is that's got nothing to do with having a password scheme strong enough to defeat a dictionary attack, which is what the AC above posted about.
In theory password hashes can be uncrackable, in practise most people pick passwords that can be cracked using a dictionary attack.
Coming up with a password scheme that is easier for people to remember but more difficult to brute force would be a huge step forward in IT security, and more useful than relying on all websites to never leak password hashes.
Nope, because I never claimed that. You misunderstood my point and started falsely assuming things
Yes you did:
"But if the attacker knows the password hash that is not a dictionary attack. In fact, there would be no need for any attack at all." - No, you still need to attack (brute force) the hash to extract the password.
"Yes, that's why you stop such attacks by rate limiting and cooldowns and then eventually just ban their IP if they are just obviously an attacker. If they can only have 5 tries every 15-20 minutes the attacker is going to give up unless the user's password just happens to be near the very beginning of the dictionary." - As written by you direct reply to a post about having the hash of a password, and is completely irrelevant if you have a hash.
Of course it is predicated on knowing you've been attacked. I was pretty sure that would be quite obvious.
The point is having a strong (not dictionary attackable) is preferable as it protects against password cracking proactively. Resetting a user's password after a hack is simply not as good as having a strong password that can't be cracked.
You've basically have been twisting my words into something I never stated or implied and then have applied them to scenarios outside of what I originally responded to. At this point I'm simply just going to ignore you.
You trolling or what?
Do you notice that nowhere in that quoted statement is there anything about the attacker performing a dictionary attack using online login attempts?
It's rare for someone to attempt an online dictionary attack because it's slow and obvious. My post that, in the more likely real-world scenario of hackers having the password hashes, passwords are still vulnerable to (offline) dictionary attacks is absolutely true. To think that rate limiting of online logins can defeat dictionary attacks is foolhardy...
Duh. Being Captain Obvious again?
By your previous posts it seemed you needed things put in simple terms, especially since you claimed that 1) knowing the hash is the same as knowing the password (it's not) and 2) rate limiting could defeat offline password cracking (it can't). Do you stand by those claims?
Of course, this is why you lock the accounts until the user resets the password. Poof that attack vector is now gone.
That's no solution: 1) Relies on the attack being detected in the first place. 2) If the user has reused their password elsewhere this doesn't reset those too. It's also completely irrelevant to the question of being able to dictionary attack a password.
Hey Desler I really don't get you, you (appear to) know what a salt is yet you don't understand that an attacker would be performing the attack on the hash offline, with their own hardware. Rate limiting their own hardware would be, as you put it, the height of idiocy.
You probably shouldn't try to write about things you don't know about or understand.
1. The industry accepted way to store passwords securely in a database is with a one-way, salted cryptographic hash (using as CPU intensive algorithm as possible).
2. Many organisations have had database intrusions where these password hashes have been stolen (eg. eBay, Linkedin, LivingSocial etc.)
3. When this happens (i.e. "they have a copy of the password hash") passwords can be cracked offline. Strong passwords are safe (too hard to brute force), but weak passwords can be found using a dictionary attack.
4. Once the password is found offline a hacker can log straight in to the victim's online account with a single password attempt.
You seem to have no clue what a password hash actually is. The whole point of a cryptographic hash is it's one way operation; You can turn a password into a hash easily, but you can't turn a hash into a password without brute forcing it.
Having a hash of a sufficiently string password is perfectly safe, in fact here's one now, bet you can't find the password from it. It's a basic SHA1 hash, not even salted: b6faa93a9e6ca445875c6b5511e2153bb51ef43a
However if a chosen password appears in a password dictionary than you can cut down your brute force search space by so much it goes from taking years (even centuries) to crack a password to taking a few hours (sometimes minutes).
Dictionary attacks can be trivially defeated by rating limiting tries and after, say, 5 tries
Unless they have a copy of the password hash
Do they have a Corporate Congress yet?
Yes, corporations with premises in the City of London are given a number of votes in local elections based on the number of employees they have.
"entirely new CPU architecture" ? The A7 uses a 64 bit variant of ARM. If you want a mobile OS that's been ported to completely different CPU architectures then look at Android; It supports ARM, MIPS and x86. They can even run the same apps.
Yeah, I hope that's a joke, because I did a survey of people in the smoking area of a bar and found that 19 out of 20 of them smoked. Extrapolated to the population of Earth that makes 6.7 billion smokers...
I have to say that Google certainly left my Nexus S in bad shape, they updated it all the way to 4.1.2 which was too resource heavy for it, then didn't update it to 4.2 which contained a bunch of performance improvements that the NS badly needed! I've been on a close to stock custom rom since then, and every major release has improved it until it's now very usable on KitKat.
Obviously in the mean time I upgraded, but it still makes a very usable 2nd phone running KK.