Seems like a big improvement over the typical banhammer approach. Let cheaters play with other cheaters while legit players can continue to enjoy the game normally. Contrast this to Blizzard's apparent approach where everyone thought to cheat (even in single-player, apparently, since they've blurred the single vs multiplayer line on D3 with this always-on crap) suddenly have their $60 purchase made worthless.
The hashing algorithm is far more important in offline attacks than in online attacks. Please don't suggest otherwise, as you don't appear to have a background in security (this isn't a personal attack, but people without security backgrounds should never give security advice).
If the table containing password hashes is compromised and leaked, the only thing preventing the plaintext being bruteforced is the strength of the algorithm. Salting prevents using a rainbow table, but you have to assume the salt is also compromised. If there's a global salt, it's just a matter of building a new rainbow table with the known shared salt: this is time consuming, but not that bad especially for weaker passwords IF THE ALGORITHM WAS CHOSEN POORLY. When each password has its own salt, an attacker must go one at a time, slowing the entire process down by a factor of [number of users in the compromised system].
The algorithm's speed comes into play here. MD5 and SHA1 are meant to be used as checksums and are designed run as fast as possible - hundreds of thousands of times per second on password-length strings with modern hardware. This of course disregards the fact that they are not cryptographically secure. SHA256, same situation: it's a bit slower and while it's currently still considered crytographically secure, it's designed for speed. I can compute a rainbow table for a dictionary attack in about two seconds (or two seconds per row, assuming unique per-row salts). Compare to something like bcrypt or PBKDF2* which include a number of rounds specifically to slow things down: with even a relatively low number of rounds ($08$ to $09$ in bcrypt, for example) modern hardware caps at about ten hashes per second. Now going down/usr/share/dict/words takes 25,000 seconds - seven hours - instead of 1-2 seconds. That timeframe is going to get exponentially longer when you consider variations, substitutions, mixed case, and multi-word passwords, assuming the password being attacked is dictionary-based at all.
You do raise a valid point about the other damage a data breach may cause, but aside from encrypted data (such as financial information), the password is the most damaging thing an attacker could retrieve since that probably grants access to a whole host of other sites since so many people re-use passwords. If you're OK with that, fine - go ahead and re-use crappy passwords everywhere. But for the love of security, please don't give advice on how people/companies should hash passwords.
*PBKDF2 is meant to be used as a key derivation function to convert a password into a cryptographically-secure encryption key. It's not the best choice for password digests, although because it includes a work factor like bcrypt is still relevant to the discussion, and is certainly a better choice than MD5 or SHA-family alone.
I'd wager they'll draw far less - the demand for long battery life in the mobile space has made its way into desktop hardware. It's amazing what the engineers can come up with when they actually try to reduce power consumption. Today's crappy outdated system might have been a high-spec machine five years ago; unfortunately, that was near the peak of our "throw more electricity at the problem" phase in hardware design (Prescott, anyone?).
Because the interface hasn't been defined yet. They're making experimental functions with no standard interface, so the prefix indicates it's not designed for production use yet. Look at CSS gradients, and even border-radius: until relatively recently, there were multiple different ways to achieve the same effect depending on the browser and that vendor's prefix: -moz-border-radius-topleft vs -webkit-border-top-left-radius (the latter won out and is now the standard, sans prefix) further complicated by non-circular radii; see http://www.css3.info/preview/rounded-border/. And that's dead-simple compared to gradients - look at the output to get something cross-browser here
This is definitely a real problem. Too bad the proposal doesn't actually solve it. While it goes in the right direction by asking for support of non-prefixed properties from day one, that effectively ensures that the first implementation out there defines the interface, which can easily leave a huge mess behind (again, see webkit's gradient interface). The proposal's author is aware of this and dismisses it as a non-issue, which is incredibly ignorant.
Congratulations - you give a damn! You're well ahead of most geeks.
And when dealing with others, that's all it really comes down to. It either appears that you care or that you don't care, and the former tends to go a long way.
I know you're commenting with extreme sarcasm, but I do think that's actually the case. An elected official using their power in a manner designed to undermine the Constitution isn't technically treason by most definitions, but I feel it should be punished just as severely.
It's hard to detect whether this is being done by automated spamming tools or humans. We have a dashboard at our office that streams mentions of our company on twitter, and we'll often see spurts of a human spamming the link to their donation campaign at celebrities asking for handouts.
To be fair, you may want to solve that problem as well, but it sounds like Twitter is just trying to silence the bots.
I'm sorry, please explain to me how distributing an eBook could in any world be more expensive than mailing around paper. Unless it's delivered 160 bytes at a time via 25-cent text messages... no.
The rest of the costs, sure. But distribution? I think not.
It's fully encrypted with a crappy passcode, too. It just takes no more than 10,000 attempts to crack, and if they're able to dump the contents of the storage that's easy to bruteforce (hopefully law enforcement would try to do it by hand, hit the ten-attempt limit and cause the device to wipe itself). As usual, encryption is only as strong as it's weakest link, and a 4-character numeric pin will be cracked twice as fast as an all-lowercase three character password (17576 possibilities)
That may have been the case at one point, but based on my own work that's no longer true. Your acquiring bank assigns your business an MCC (merchant category code) when you first get your account, and that's sent back to Visa/Mastercard when authorizing a transaction. Moreover, that's not even something you send; it's just part of how your account is configured when your acquiring bank sends the transaction over the network.
Depending on your merchant processor and acquiring bank that may be customizable (though I have never seen it done, and I've worked with quite a few processors), but for the vast majority of merchants, it's simply a very generic four-digit code that's associated with the full dollar amount of the authorization. All I need to authorize a card payment is the amount, account number, and expiration date - CVN, billing address, and even consumer name are optional, although your pricing will be downgraded (i.e., more expensive) if you omit those fields due to the higher risk.
For me, the convenience of being able to track my own spending far outweighs my ability to care if the government can subpoena where I buy my morning coffee from. I understand (and agree with) your concern, but using payment cards offers a huge number of incentives that cash does not and can not.
And FYI, plenty of criminal transactions occur in the plastic world - and the red tape imposed by the government in trying to prevent that makes my job a lot more painful (and risky) than it needs to be. Criminals are always going to ruin things for everyone else; doubly so when it comes to getting paid. Sorry, that's just reality. Blame stupid law enforcement (see also: war on photography)
It either a) stops the pump if it cannot approve the number (including non-recognition) or b) stops the pump if it detects an unauthorized number. There's a subtle difference, but only the latter wouldn't be a complete disaster - though the summary describes the former.
And when the system crashes, nobody in all of England can refuel? It *must* be default-allow to handle failures. Which of course makes it pointless, but who ever thought government ideas were any good?
I hope they don't design a system that failure-prone, should they actually go ahead with such a big-brother measure (history tells us they will).
Slashdot Mirror
I'll happily do my part to produce orphans.
Pretty sure that most sex offenders got off.
*ducks*
Seems like a big improvement over the typical banhammer approach. Let cheaters play with other cheaters while legit players can continue to enjoy the game normally. Contrast this to Blizzard's apparent approach where everyone thought to cheat (even in single-player, apparently, since they've blurred the single vs multiplayer line on D3 with this always-on crap) suddenly have their $60 purchase made worthless.
The hashing algorithm is far more important in offline attacks than in online attacks. Please don't suggest otherwise, as you don't appear to have a background in security (this isn't a personal attack, but people without security backgrounds should never give security advice).
If the table containing password hashes is compromised and leaked, the only thing preventing the plaintext being bruteforced is the strength of the algorithm. Salting prevents using a rainbow table, but you have to assume the salt is also compromised. If there's a global salt, it's just a matter of building a new rainbow table with the known shared salt: this is time consuming, but not that bad especially for weaker passwords IF THE ALGORITHM WAS CHOSEN POORLY. When each password has its own salt, an attacker must go one at a time, slowing the entire process down by a factor of [number of users in the compromised system].
The algorithm's speed comes into play here. MD5 and SHA1 are meant to be used as checksums and are designed run as fast as possible - hundreds of thousands of times per second on password-length strings with modern hardware. This of course disregards the fact that they are not cryptographically secure. SHA256, same situation: it's a bit slower and while it's currently still considered crytographically secure, it's designed for speed. I can compute a rainbow table for a dictionary attack in about two seconds (or two seconds per row, assuming unique per-row salts). Compare to something like bcrypt or PBKDF2* which include a number of rounds specifically to slow things down: with even a relatively low number of rounds ($08$ to $09$ in bcrypt, for example) modern hardware caps at about ten hashes per second. Now going down /usr/share/dict/words takes 25,000 seconds - seven hours - instead of 1-2 seconds. That timeframe is going to get exponentially longer when you consider variations, substitutions, mixed case, and multi-word passwords, assuming the password being attacked is dictionary-based at all.
You do raise a valid point about the other damage a data breach may cause, but aside from encrypted data (such as financial information), the password is the most damaging thing an attacker could retrieve since that probably grants access to a whole host of other sites since so many people re-use passwords. If you're OK with that, fine - go ahead and re-use crappy passwords everywhere. But for the love of security, please don't give advice on how people/companies should hash passwords.
*PBKDF2 is meant to be used as a key derivation function to convert a password into a cryptographically-secure encryption key. It's not the best choice for password digests, although because it includes a work factor like bcrypt is still relevant to the discussion, and is certainly a better choice than MD5 or SHA-family alone.
I'd wager they'll draw far less - the demand for long battery life in the mobile space has made its way into desktop hardware. It's amazing what the engineers can come up with when they actually try to reduce power consumption. Today's crappy outdated system might have been a high-spec machine five years ago; unfortunately, that was near the peak of our "throw more electricity at the problem" phase in hardware design (Prescott, anyone?).
Because the interface hasn't been defined yet. They're making experimental functions with no standard interface, so the prefix indicates it's not designed for production use yet. Look at CSS gradients, and even border-radius: until relatively recently, there were multiple different ways to achieve the same effect depending on the browser and that vendor's prefix: -moz-border-radius-topleft vs -webkit-border-top-left-radius (the latter won out and is now the standard, sans prefix) further complicated by non-circular radii; see http://www.css3.info/preview/rounded-border/. And that's dead-simple compared to gradients - look at the output to get something cross-browser here
This is definitely a real problem. Too bad the proposal doesn't actually solve it. While it goes in the right direction by asking for support of non-prefixed properties from day one, that effectively ensures that the first implementation out there defines the interface, which can easily leave a huge mess behind (again, see webkit's gradient interface). The proposal's author is aware of this and dismisses it as a non-issue, which is incredibly ignorant.
Congratulations - you give a damn! You're well ahead of most geeks.
And when dealing with others, that's all it really comes down to. It either appears that you care or that you don't care, and the former tends to go a long way.
$200,000? In California? Try $2,000,000.
But yes, point taken.
I know you're commenting with extreme sarcasm, but I do think that's actually the case. An elected official using their power in a manner designed to undermine the Constitution isn't technically treason by most definitions, but I feel it should be punished just as severely.
Neckbeard like that? No doubt :p
You can perform that same hack with an extension cable.
Tweet something containing "iPad", "iPhone", etc. Wait about ten seconds. Check your @replies. It's definitely a real problem.
It's hard to detect whether this is being done by automated spamming tools or humans. We have a dashboard at our office that streams mentions of our company on twitter, and we'll often see spurts of a human spamming the link to their donation campaign at celebrities asking for handouts.
To be fair, you may want to solve that problem as well, but it sounds like Twitter is just trying to silence the bots.
They charge you for using resources you're already paying for, and you're pointing this out as a good thing?
Didn't you get the memo? People and corporations are legally equivalent.
I'm sorry, please explain to me how distributing an eBook could in any world be more expensive than mailing around paper. Unless it's delivered 160 bytes at a time via 25-cent text messages... no.
The rest of the costs, sure. But distribution? I think not.
Well I, for one, am much more of other people's left hands now.
I agree with you conceptually, but that's the same government that is training its members that the law does not apply to them.
Assuming you meant "lives saved" by "lives", rather than "ruined", "ended", "imprisoned", or something else.
It's fully encrypted with a crappy passcode, too. It just takes no more than 10,000 attempts to crack, and if they're able to dump the contents of the storage that's easy to bruteforce (hopefully law enforcement would try to do it by hand, hit the ten-attempt limit and cause the device to wipe itself). As usual, encryption is only as strong as it's weakest link, and a 4-character numeric pin will be cracked twice as fast as an all-lowercase three character password (17576 possibilities)
Where? Yes, but only because that's associated with the merchant authorizing the payment.
What? Very, very unlikely - outside of the vague categories provided by Merchant Category Codes.
That may have been the case at one point, but based on my own work that's no longer true. Your acquiring bank assigns your business an MCC (merchant category code) when you first get your account, and that's sent back to Visa/Mastercard when authorizing a transaction. Moreover, that's not even something you send; it's just part of how your account is configured when your acquiring bank sends the transaction over the network.
http://www.irs.gov/irb/2004-31_IRB/ar17.html
http://web.archive.org/web/20070710202209/http://usa.visa.com/download/corporate/resources/mcc_booklet.pdf
Depending on your merchant processor and acquiring bank that may be customizable (though I have never seen it done, and I've worked with quite a few processors), but for the vast majority of merchants, it's simply a very generic four-digit code that's associated with the full dollar amount of the authorization. All I need to authorize a card payment is the amount, account number, and expiration date - CVN, billing address, and even consumer name are optional, although your pricing will be downgraded (i.e., more expensive) if you omit those fields due to the higher risk.
The purchases are linked back to the loyalty card. It's your own fault if you let that card become associated with you.
For me, the convenience of being able to track my own spending far outweighs my ability to care if the government can subpoena where I buy my morning coffee from. I understand (and agree with) your concern, but using payment cards offers a huge number of incentives that cash does not and can not.
And FYI, plenty of criminal transactions occur in the plastic world - and the red tape imposed by the government in trying to prevent that makes my job a lot more painful (and risky) than it needs to be. Criminals are always going to ruin things for everyone else; doubly so when it comes to getting paid. Sorry, that's just reality. Blame stupid law enforcement (see also: war on photography)
It either a) stops the pump if it cannot approve the number (including non-recognition) or b) stops the pump if it detects an unauthorized number. There's a subtle difference, but only the latter wouldn't be a complete disaster - though the summary describes the former.
And when the system crashes, nobody in all of England can refuel? It *must* be default-allow to handle failures. Which of course makes it pointless, but who ever thought government ideas were any good?
I hope they don't design a system that failure-prone, should they actually go ahead with such a big-brother measure (history tells us they will).