Yes, that. I thought that was clear enough, particularly after I elaborated on some of the details, but about seventy ACs seemed to misunderstand entirely.
Also, it's good to know that such a browser extension already exists, although there's no excuse whatsoever for websites not doing this on their own unless they have some good reason for wanting zero client-side scripting (which obviously excludes almost everyone on the web today, including eBay and most webmail.)
This is about protecting good passwords, not bad ones. My password was strong and long enough to resist even a very clever dictionary attack run on very powerful machines.
hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts
"Only" ?? Uh, this is ebay we're talking about here, and they're not alone. It happened to some other big names. It happened to Ubuntu Forums a while back. I recently saw confirmation that our ISP (a name you would recognize) uses plaintext password storage. it appears that the industry standard practice with websites is to use plaintext password storage. Am I wrong?
It makes zero sense as part of a websites arsenal against attacks.
Well, first off it makes sense because you, the client side guy, can fix things even if the backend guy can't/won't. More importantly, it's important because it's user-visible and auditable, so everyone will know whether or not your site uses it. If enough of a stink can be raised--"Don't use gmail! They use incorrect security procedures that allow your password to be easily stolen and used on other websites! Use [x]mail instead." (this being the simplified version you tell non-technical people) then enough corporations might be pressured into adopting the standard to make it a de facto industry standard, at which point we can dispense with the canard that the user needs to memorize a different password for every single website they visit. In the future, any website not using a salted client side hash should prompt security alert emails, and your browser should give you big red popups strongly advising you against creating an account with the website (or at least to make sure to use a completely different password.)
There are slight negatives in the sense that the backend guys may no longer feel any need whatsoever to do further hashing (which would be unfortunate, since a server-side hash can prevent many database breaches from translating into instant account access), but I think on net this would be head and shoulders above the current situation, where casual users (people who aren't going to use special password management tools) are completely and totally fucked because there is no way they are going to be able to memorize a totally different and robust password for every site they use.
I'm not sure how many different ways I can say this, but here goes: "I don't wish to be cruel, but you really should take the time to understand how cryptographically secure hashing works, and also maybe re-read the specifics of my issue." It was a good, strong passphrase. If I had two client side hashed versions of this passphrase, one with "ebay.com" and the other with the email provider, and I sent each to the appropriate server to act as my server-stored passwords... please, explain to me exactly how an eBay breach could result in my email being collateral damage?
Answer: It can't happen without a massive break in the hashing algorithm. And the fact that this could be all client-side means it's very easy to spot weak or cheating implementations. It could also mean that someone could write a browser extension to do it without the cooperation of the sites, but since it seems like the majority of people here don't even understand how a known salt hash could help, I'm a bit pessimistic about the prospects of it attracting a decent-sized user base.
Well, this is something that can be easily verified on the user's end. So there remains a glimmer of hope that with enough fuck yous and making noise that people could be shamed into adopting at least a client-side fix (there are important server-side bits as well, but we have to take your word for those things.)
The other possibly, that I'm currently thinking very hard about, is to write a suite of free (with premium upgrades and management available) tools to allow the users to add this layer themselves. I'm currently not sure the free version can be made interesting enough or easy enough for most people to bother with (especially vs. the solution of just having random passwords for everything and storing it in an existing password manager), and the premium versions, while interesting, could only accomplish so much without the user actually trusting them with all their passwords, which isn't a general trend I would like to see in the realm of computer security.
You store the salted-hashed password on the server. The server never gets to know your "real" password.
Your "real" password, if it's a good one (i.e. long and unusual enough to resist the cleverist brute force cracking systems out there), can be freely reused with any website you wish (as long as all websites use this scheme) and each site breach will be completely contained--knowing your hashed version on site A doesn't get the attacker anywhere with site B, because a completely different salt was used. It doesn't matter that both salts are publicly known; that doesn't make reverse engineering easy if the password is strong and the hashing algorithm a sound one.
Sending a plaintext password over https also achieves a similar result.
Am I really that bad of a storyteller or are you people really that ignorant about crypto? Jesus fucking Christ...
No, he is completely wrong. Salted client-side hash would have completely prevented my email account breach, because the passphrase in question was a good one. Pre-computed rainbow tables do not help you crack a *good* passphrase. The whole point of my scheme is to prevent a stolen password from being used with an account on another website, utilizing a transparent system requiring no active work on the part of anyone.
Protecting *bad* passphrases from being discovered is completely beyond the purview of my scheme and is ultimately impossible to do without requiring the user to do something different ("you can't fix stupid.")
There's also an argument for the server doing its own hashing (and not permanently storing the pre-server-hashed passphrase it receives), since this would prevent certain types of database breaches from immediately translating into full account access.
Holy crap. The ignorant ACs are really out in force today. I don't mean to be unpleasant, it's just... depressing.
The salted hash is to prevent a GOOD password from being discovered even if a site is compromised. If that same GOOD password is being used with a different site (and thus with a different salt, but all salts and the hash algorithm can be entirely known to the attacker) then the attacker can... what? Good cryptographically secure hashes are one-way things. He can't use the stolen hashed passphrase to retrieve your original passphrase, which is he needs in order to re-salt/hash it for the different (unbreached) site.
I'm not concerned with protecting bad passwords that can be cracked. Go use a secret keyfile if you want to protect your bad password.
Because it allows the safe reuse of a GOOD passphrase (not a bad one) on multiple sites without a reduction in security--if one site is compromised, it doesn't take down the rest.
No. Look, this MIGHT be a confusion of terms (there's something called a "nonce", for instance, that's like salt but used in a different way. And then there are IVs...), but the fact is it's OK if the salt is known--as per my sob story, I'm talking only about protecting good passphrases, not bad ones. Bad passphrases can only be protected with what I usually term a "keyfile", which should be guarded the same way that the password is guarded, but you can achieve quite a lot with known salt hashing on both client and server sides.
By good passphrase, I mean one that can survive all brute force attacks using all of the common known behavioral tricks.
As per my little sob story, I am talking about protecting GOOD passwords from discovery (and thus allowing their safe refuse), nothing more. And I specifically said I was much more interested in client-side salt (although there is an argument for server-side as well.)
This was about good passphrases, not bad ones. If you don't understand how using a cryptographically secure hash function with salt (even known salt) accomplishes this goal, then "I am sorry" but you do not understand the first thing about cryptography.
To clarify 2-4, which I mangled a bit (it's 9am, so sue me), yes you can and should have the server do its own private hash because that brings a few advantages to the table, particularly in the rather obvious case of using a stolen hash with the very site you stole it from; however, overall the client side hash is much more important for the basic reason that the client is already trusted. It HAS to be trusted. And if the only practical way to standardize such a system is through JS, then that's a small price to pay, and those scripts can be whitelisted. If you hate JS to the point of not even being willing to whitelist stuff using extensions... well, good luck with that.
1) It explicitly requires JavaScript on the client browser to be enabled.
2) Where do we store the salt? On the server? Well, that means we have salt+hash on the server which is what you wanted to replace in the first place (we'd also need to send it back to you without really knowing who you are, which doesn't seem secure). So we'll store it on the client! Which means it will be unique to the browser. Sucks to be you if you ever want to log in from a different device or clear your cookies, your password wont be valid.
3) Since we can never really trust that the client is actually doing what it should be doing - it may well still just be sending us a plaintext password - to be secure we're still gonna have to salt and hash it on the server anyway.
4) Hopefully the above points demonstrate that the security gains are, realistically, utterly minimal if salting/hashing is done server side PROPERLY. Sure, ebay wouldn't have lost your password if they followed this scheme (usability be damned of course) but likewise they wouldn't have if they were salting/hashing server side in the first place.
1. I'll take that risk. Better yet, get one third party source to provide the script and box for everyone and I'll whitelist only that source in uBlock. Better yet, put this in HTML6 or something. Implement some highly specific DSL stuff that hopefully can't be exploited. (Protip: Offer $100k reward during draft phase to the first one to publish an exploit.)
2. Storing it on the server is fine. You obviously need some salting, prior to it being stored in the database, or else a break-in would be trivial with a stolen hash (just modify the client side JS.) But the salt doesn't need to be kept a secret--that's the great part about (some uses of) salt.
3. Uh, no. That's dumb. The server just stores the salt. The server doesn't perform the hash. If the client is responsible for the hash then it makes it easy to audit and make sure they aren't screwing you over. If someone gets infected with something that stealthily replaces the site's JS with some other JS that doesn't properly hash it... well, if an attacker can do that then there are a lot of very nasty things they can do anyway, and having the server do your hashing for you isn't going to change anything. Use HTTPS and pay attention to your certificates, but that has nothing to do with what I'm talking about here.
4. No. Heck, the server doesn't even need to store the salt--the salt can be the root domain name--ebay.com. Years ago, I was tempted to write a browser extension that would do just this... but it seemed like a fair bit of effort to do it properly and I never got around to it.
Lastly, I find it difficult to be sympathetic to someone who never changed his email password since they were twelve. What was the point in transitioning to a randomized password if you used it everywhere?
I didn't say that. The email account had its password changed several times over the years, and the last password I'd changed it to was very secure and wasn't used for anything other than other important accounts, not random forum stuff. I let myself slack off changing it to something unique (and totally random, although what I had was very strong) for that very reason, since all of my bank accounts and such were by then changed to something unique and at the time the breach happened there were only a couple big name accounts (but not the ones I generally used a lot) that still shared that same robust (but shared) password.
Here's the golden rule of internet security: Your email account is the single most important account you have.
It wasn't my main email account any more, but there was a lot of legacy and nostalgic stuff of lesser importance that I didn't yet have the time to manually transfer over to the new address. Do you have kids? You sound a tiny bit like someone who does not have kids.
To clarify, what this would do is allow people to reuse a quality password with all websites and apps that adhered to this standard. If any one site was subject to a data breach, this would only give the attackers access to the hash and the salt; they wouldn't be able to reconstruct your password (as long as it was a good password), thus they wouldn't be able to log in to any other website you used the same password with as long as the hashing algorithm remained secure (e.g. as long as collisions couldn't be engineered with arbitrary salt values.)
If a hashing algorithm is ever compromised such that chosen collisions with arbitrary salt values become feasible, someone immediately issues a bulletin and hash security upgrade. All sites that upgrade their hash algorithm immediately become invulnerable to collision attacks (after the user logs in at least one time, post-upgrade), even if a data breach happens on a server that hasn't yet upgraded their hash. This upgrade could happen in the background, without forcing the user to change their password. The only action the user would need to take is to log in to all websites or apps they have an account with as soon as possible (but neglecting to log in to one site, post-upgrade, would not compromise the security of the others.)
And none of this would prevent client-side scripts from running during password generation to inform the user that their chosen password is too short/weak.
The sane fix would be to push web standards that require all passwords be hashed with server-provided salt on the user's side prior to being sent over an HTTPS connection to the server.
Websites meeting this standard could have fancy little badges of honor to display on their homepage.
Websites failing to meet this standard should be regularly listed in security advisories, companies could discourage or forbid their employees from using these websites, your web browser should warn you that your password on this site should not be considered safe, etc.
This solution to password compromise occurred to me a very long time ago, almost immediately after I learned about hash functions. It seemed so obvious and easy to implement that I was certain it would come about within a year or two. But what have we received instead? Sites that still transmit and store your password in cleartext, but now they send you little verification emails every time you try to log in from a new browser (or the same browser with the cookie deleted).
Six months? Luxury. The places I've worked at all required monthly or 60 day changes, which means that virtually everyone ends up simply appending a number matching the current month to the end of the password. What they don't bother to do is inform you when your credentials have been used to log in at 3am. Or from someone else's workstation. Or from a Hong Kong IP address.
Call me cynical, but most user security policies don't make much sense except from a job security standpoint.
I recently lost an email account I've had since I was twelve apparently due to one of the eBay breeches. Yes, I used the same password for both (never got around to changing them after I made the transition to randomized passwords) so it's my fault, right?
How about great big "fuck you" instead? How about a wall of shame for every website that does not hash passwords, with salt, prior to transmission over the internet? This is kiddy level shit here. The slowest smartphone in the world should be able to do this in its sleep.
And the majority of sites still have incredibly stupid password policies, almost all forcing you to use special characters and numbers instead of long passphrases which, if properly constructed (such as via dicewords), can be considerably more secure than the average "unicorn16!" type password. Some sites even impose a ridiculous maximum length policy, and some sites also forbid certain special characters, probably for some horribly depressing reason like they can't be bothered to make sure the password field can't be used for SQL injection or overflow attacks.
Work passwords aren't much better. The constant changing is completely pointless; everyone either uses a very simple incrementing number system (often tied to the current month) or they use Post-Its. A sane alternative would be to track logins and alert the user and/or security admins of unusual times or locations and to use keyfiles on smartcards or regular USB drives.
I've checked the literature and these ridiculous practices are still being taught to people studying for CompTIA certifications. Can't someone please... I don't know, do something about this? Can't we have some industry leaders say that they're no longer recognizing CompTIA Security+ or Network+ certifications as worth anything? This shit has been going on for far too long, and in an effort to made up for their shitty password infrastructure many places are adopting painfully annoying supplementary security systems.
I meant more in terms of existing and widely deployed products seamlessly supporting these alternate keying methods, though I guess I should dig through the details of the TLS standard sometime to see what can be done, at least in theory.
By the time we know for sure it's feasible, I suspect we'll be pretty darn close to having something real to worry about. A lot of people used to claim that Van Eck interception was infeasible in real world conditions but, uh... it's not. Seeing as how it not only allows for unlimited interception of encrypted data but also unlimited spoofing, it's not unreasonable to say that if they can ever figure out a way to do it in a less than 10 figure budget, they will. And they won't be in any hurry to hint at the fact that they can until other world powers begin to develop the same capabilities.
Maybe someone out there could crunch some back of the napkin numbers to estimate how many qubits would be needed for reasonably fast break of a 2048 bit RSA key?
And ECC. Probably not with this generation, but it's entirely possible three letter organizations are close to having a machine that can at least break smaller key sizes. Which in and of itself isn't especially worrying, except that the more sophisticated and rogue state-sponsored criminals won't be lagging very far behind.
There's no good reason why our web security infrastructure shouldn't immediately begin upgrades to support multiple, extensible and arbitrary methods of key exchange, including but not limited to stateful solutions using out of band preshared keys. Given it would only costs a few bucks to buy a gigabyte of key material stored on redundant robust flash memory, and each symmetric key wouldn't need to be more than a kilobit at the most, and in principle one would only need a couple keys to securely receive keys generated by trusted session key providing servers...
So no, I don't particularly feel like providing you with an in-depth, blow by blow, thoroughly sourced analysis unless you pay me. However, I am still curious what it's like to be a grown man who would rather believe that the science and the numbers lie instead of considering the possibility that people simply suck.
Any state not having a verifiable paper trail as a backup is insane.
Yes, and this is a pretty big indictment of the laziness (...or cynical job protection) of IT experts. They've had 16 years to explain to people that the best way to secure and streamline the infrastructure is also the cheapest: optical scanners backed by random double-checking with hand counts, with a few statisticians on hand to flag any suspicious-looking results that should be audited. Black box systems that don't involve a paper trail are more expensive, incur additional expenses in auditing and hardening, and inevitably turned out to be much less reliable than the old methods... now we're seeing hints that these things are actually being networked? If each individual vote-counting machine were kept separate and offline then the attackers' job becomes completely impractical, as they would have to successfully attack a large proportion of the machines involved in an election in person in order to change the outcome.
In case you're still convinced the nuclear industry report drafters know what they're talking about, other posters have already replied to you with some specifics: apparently fuel is being thrown away while it's still useful due to structural heat-induced changes in the ingots, and it's also apparently the case that "spent" fuel (which in its original state is really something like 95% non-fuel blended with ~5% fuel) is currently tossed aside instead of being re-enriched with active isotopes. There are probably hundreds of economically feasible ways to address these problems. Non-fuel waste is similarly mitigatable by using materials less vulnerable to neutron embrittlement, using more durable parts and machines in general, and decreasing the amount time that certain bits are exposed to intense neutron radiation.
Probably what happened was older techniques and designs assumed that it wasn't going to be too big a deal to simply throw this stuff away (because people threw away non-nuclear highly toxic waste all of the time, so they weren't anticipating anti-nuclear hysteria leading to the government demanding the use of super secured dump sites), and out of stubbornness or sloth or subsidy they've continued doing what they originally planned on doing, but there's no compelling reason why the plants have to produce much waste.
Stupidogenesis is not something I research for fun. Pay me money for my time and I'll examine the plans, crunch the numbers and explain to you precisely how this issue of too much waste came about and how it could easily be solved... but that wasn't what this thread was originally about. It was about the intrinsic expenses of nuclear power.
Your deference to reports drafted by incompetent people probably using outdated designs is unbelievable.
I don't know or care how much waste the assholes are producing now. I am saying that any competent engineer could easily produce a design that could store all of its waste on-site, because the mechanics of basic nuclear power generation do not generate much waste. This thread has been about refuting claims that nuclear is intrinsically more expensive than other options, which it is not.
I have no desire whatsoever to prove that people currently running the nuclear industry in this country are competent. If this industry is like most industries older than fifty years then the answer is no, probably not.
They are not 'wacky' beliefs; they are scientifically literate ones. If they are producing so much waste that it cannot physically remain on-site then someone has fucked up, period. The fuel waste alone should be very, very, very small. The non-fuel waste can and should be minimized. If you're producing so much non-fuel waste that it won't fit on the lot then either the designer or the operator(s) of the plant has been moronically reckless.
Clear thinking and scientific literacy should never take a back seat to the reports produced by bureaucratic incompetents.
Slashdot Mirror
Also, it's good to know that such a browser extension already exists, although there's no excuse whatsoever for websites not doing this on their own unless they have some good reason for wanting zero client-side scripting (which obviously excludes almost everyone on the web today, including eBay and most webmail.)
This is about protecting good passwords, not bad ones. My password was strong and long enough to resist even a very clever dictionary attack run on very powerful machines.
hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts
"Only" ?? Uh, this is ebay we're talking about here, and they're not alone. It happened to some other big names. It happened to Ubuntu Forums a while back. I recently saw confirmation that our ISP (a name you would recognize) uses plaintext password storage. it appears that the industry standard practice with websites is to use plaintext password storage. Am I wrong?
It makes zero sense as part of a websites arsenal against attacks.
Well, first off it makes sense because you, the client side guy, can fix things even if the backend guy can't/won't. More importantly, it's important because it's user-visible and auditable, so everyone will know whether or not your site uses it. If enough of a stink can be raised--"Don't use gmail! They use incorrect security procedures that allow your password to be easily stolen and used on other websites! Use [x]mail instead." (this being the simplified version you tell non-technical people) then enough corporations might be pressured into adopting the standard to make it a de facto industry standard, at which point we can dispense with the canard that the user needs to memorize a different password for every single website they visit. In the future, any website not using a salted client side hash should prompt security alert emails, and your browser should give you big red popups strongly advising you against creating an account with the website (or at least to make sure to use a completely different password.)
There are slight negatives in the sense that the backend guys may no longer feel any need whatsoever to do further hashing (which would be unfortunate, since a server-side hash can prevent many database breaches from translating into instant account access), but I think on net this would be head and shoulders above the current situation, where casual users (people who aren't going to use special password management tools) are completely and totally fucked because there is no way they are going to be able to memorize a totally different and robust password for every site they use.
I'm not sure how many different ways I can say this, but here goes: "I don't wish to be cruel, but you really should take the time to understand how cryptographically secure hashing works, and also maybe re-read the specifics of my issue." It was a good, strong passphrase. If I had two client side hashed versions of this passphrase, one with "ebay.com" and the other with the email provider, and I sent each to the appropriate server to act as my server-stored passwords... please, explain to me exactly how an eBay breach could result in my email being collateral damage?
Answer: It can't happen without a massive break in the hashing algorithm. And the fact that this could be all client-side means it's very easy to spot weak or cheating implementations. It could also mean that someone could write a browser extension to do it without the cooperation of the sites, but since it seems like the majority of people here don't even understand how a known salt hash could help, I'm a bit pessimistic about the prospects of it attracting a decent-sized user base.
Well, this is something that can be easily verified on the user's end. So there remains a glimmer of hope that with enough fuck yous and making noise that people could be shamed into adopting at least a client-side fix (there are important server-side bits as well, but we have to take your word for those things.)
The other possibly, that I'm currently thinking very hard about, is to write a suite of free (with premium upgrades and management available) tools to allow the users to add this layer themselves. I'm currently not sure the free version can be made interesting enough or easy enough for most people to bother with (especially vs. the solution of just having random passwords for everything and storing it in an existing password manager), and the premium versions, while interesting, could only accomplish so much without the user actually trusting them with all their passwords, which isn't a general trend I would like to see in the realm of computer security.
You store the salted-hashed password on the server. The server never gets to know your "real" password.
Your "real" password, if it's a good one (i.e. long and unusual enough to resist the cleverist brute force cracking systems out there), can be freely reused with any website you wish (as long as all websites use this scheme) and each site breach will be completely contained--knowing your hashed version on site A doesn't get the attacker anywhere with site B, because a completely different salt was used. It doesn't matter that both salts are publicly known; that doesn't make reverse engineering easy if the password is strong and the hashing algorithm a sound one.
Sending a plaintext password over https also achieves a similar result.
Am I really that bad of a storyteller or are you people really that ignorant about crypto? Jesus fucking Christ...
No, he is completely wrong. Salted client-side hash would have completely prevented my email account breach, because the passphrase in question was a good one. Pre-computed rainbow tables do not help you crack a *good* passphrase. The whole point of my scheme is to prevent a stolen password from being used with an account on another website, utilizing a transparent system requiring no active work on the part of anyone.
Protecting *bad* passphrases from being discovered is completely beyond the purview of my scheme and is ultimately impossible to do without requiring the user to do something different ("you can't fix stupid.")
There's also an argument for the server doing its own hashing (and not permanently storing the pre-server-hashed passphrase it receives), since this would prevent certain types of database breaches from immediately translating into full account access.
Holy crap. The ignorant ACs are really out in force today. I don't mean to be unpleasant, it's just... depressing.
The salted hash is to prevent a GOOD password from being discovered even if a site is compromised. If that same GOOD password is being used with a different site (and thus with a different salt, but all salts and the hash algorithm can be entirely known to the attacker) then the attacker can... what? Good cryptographically secure hashes are one-way things. He can't use the stolen hashed passphrase to retrieve your original passphrase, which is he needs in order to re-salt/hash it for the different (unbreached) site.
I'm not concerned with protecting bad passwords that can be cracked. Go use a secret keyfile if you want to protect your bad password.
Because it allows the safe reuse of a GOOD passphrase (not a bad one) on multiple sites without a reduction in security--if one site is compromised, it doesn't take down the rest.
HTTPS serves a different purpose.
No. Look, this MIGHT be a confusion of terms (there's something called a "nonce", for instance, that's like salt but used in a different way. And then there are IVs...), but the fact is it's OK if the salt is known--as per my sob story, I'm talking only about protecting good passphrases, not bad ones. Bad passphrases can only be protected with what I usually term a "keyfile", which should be guarded the same way that the password is guarded, but you can achieve quite a lot with known salt hashing on both client and server sides.
By good passphrase, I mean one that can survive all brute force attacks using all of the common known behavioral tricks.
As per my little sob story, I am talking about protecting GOOD passwords from discovery (and thus allowing their safe refuse), nothing more. And I specifically said I was much more interested in client-side salt (although there is an argument for server-side as well.)
This was about good passphrases, not bad ones. If you don't understand how using a cryptographically secure hash function with salt (even known salt) accomplishes this goal, then "I am sorry" but you do not understand the first thing about cryptography.
To clarify 2-4, which I mangled a bit (it's 9am, so sue me), yes you can and should have the server do its own private hash because that brings a few advantages to the table, particularly in the rather obvious case of using a stolen hash with the very site you stole it from; however, overall the client side hash is much more important for the basic reason that the client is already trusted. It HAS to be trusted. And if the only practical way to standardize such a system is through JS, then that's a small price to pay, and those scripts can be whitelisted. If you hate JS to the point of not even being willing to whitelist stuff using extensions... well, good luck with that.
1) It explicitly requires JavaScript on the client browser to be enabled. 2) Where do we store the salt? On the server? Well, that means we have salt+hash on the server which is what you wanted to replace in the first place (we'd also need to send it back to you without really knowing who you are, which doesn't seem secure). So we'll store it on the client! Which means it will be unique to the browser. Sucks to be you if you ever want to log in from a different device or clear your cookies, your password wont be valid. 3) Since we can never really trust that the client is actually doing what it should be doing - it may well still just be sending us a plaintext password - to be secure we're still gonna have to salt and hash it on the server anyway. 4) Hopefully the above points demonstrate that the security gains are, realistically, utterly minimal if salting/hashing is done server side PROPERLY. Sure, ebay wouldn't have lost your password if they followed this scheme (usability be damned of course) but likewise they wouldn't have if they were salting/hashing server side in the first place.
1. I'll take that risk. Better yet, get one third party source to provide the script and box for everyone and I'll whitelist only that source in uBlock. Better yet, put this in HTML6 or something. Implement some highly specific DSL stuff that hopefully can't be exploited. (Protip: Offer $100k reward during draft phase to the first one to publish an exploit.)
2. Storing it on the server is fine. You obviously need some salting, prior to it being stored in the database, or else a break-in would be trivial with a stolen hash (just modify the client side JS.) But the salt doesn't need to be kept a secret--that's the great part about (some uses of) salt.
3. Uh, no. That's dumb. The server just stores the salt. The server doesn't perform the hash. If the client is responsible for the hash then it makes it easy to audit and make sure they aren't screwing you over. If someone gets infected with something that stealthily replaces the site's JS with some other JS that doesn't properly hash it... well, if an attacker can do that then there are a lot of very nasty things they can do anyway, and having the server do your hashing for you isn't going to change anything. Use HTTPS and pay attention to your certificates, but that has nothing to do with what I'm talking about here.
4. No. Heck, the server doesn't even need to store the salt--the salt can be the root domain name--ebay.com. Years ago, I was tempted to write a browser extension that would do just this... but it seemed like a fair bit of effort to do it properly and I never got around to it.
Lastly, I find it difficult to be sympathetic to someone who never changed his email password since they were twelve. What was the point in transitioning to a randomized password if you used it everywhere?
I didn't say that. The email account had its password changed several times over the years, and the last password I'd changed it to was very secure and wasn't used for anything other than other important accounts, not random forum stuff. I let myself slack off changing it to something unique (and totally random, although what I had was very strong) for that very reason, since all of my bank accounts and such were by then changed to something unique and at the time the breach happened there were only a couple big name accounts (but not the ones I generally used a lot) that still shared that same robust (but shared) password.
Here's the golden rule of internet security: Your email account is the single most important account you have.
It wasn't my main email account any more, but there was a lot of legacy and nostalgic stuff of lesser importance that I didn't yet have the time to manually transfer over to the new address. Do you have kids? You sound a tiny bit like someone who does not have kids.
You don't need to c
*breaches. In before the pantaloons wisecrack.
To clarify, what this would do is allow people to reuse a quality password with all websites and apps that adhered to this standard. If any one site was subject to a data breach, this would only give the attackers access to the hash and the salt; they wouldn't be able to reconstruct your password (as long as it was a good password), thus they wouldn't be able to log in to any other website you used the same password with as long as the hashing algorithm remained secure (e.g. as long as collisions couldn't be engineered with arbitrary salt values.)
If a hashing algorithm is ever compromised such that chosen collisions with arbitrary salt values become feasible, someone immediately issues a bulletin and hash security upgrade. All sites that upgrade their hash algorithm immediately become invulnerable to collision attacks (after the user logs in at least one time, post-upgrade), even if a data breach happens on a server that hasn't yet upgraded their hash. This upgrade could happen in the background, without forcing the user to change their password. The only action the user would need to take is to log in to all websites or apps they have an account with as soon as possible (but neglecting to log in to one site, post-upgrade, would not compromise the security of the others.)
And none of this would prevent client-side scripts from running during password generation to inform the user that their chosen password is too short/weak.
The sane fix would be to push web standards that require all passwords be hashed with server-provided salt on the user's side prior to being sent over an HTTPS connection to the server.
Websites meeting this standard could have fancy little badges of honor to display on their homepage.
Websites failing to meet this standard should be regularly listed in security advisories, companies could discourage or forbid their employees from using these websites, your web browser should warn you that your password on this site should not be considered safe, etc.
This solution to password compromise occurred to me a very long time ago, almost immediately after I learned about hash functions. It seemed so obvious and easy to implement that I was certain it would come about within a year or two. But what have we received instead? Sites that still transmit and store your password in cleartext, but now they send you little verification emails every time you try to log in from a new browser (or the same browser with the cookie deleted).
It's bulletproof!
Six months? Luxury. The places I've worked at all required monthly or 60 day changes, which means that virtually everyone ends up simply appending a number matching the current month to the end of the password. What they don't bother to do is inform you when your credentials have been used to log in at 3am. Or from someone else's workstation. Or from a Hong Kong IP address.
Call me cynical, but most user security policies don't make much sense except from a job security standpoint.
I forgot to include the obligatory xkcd on dicewords: https://xkcd.com/936/
I recently lost an email account I've had since I was twelve apparently due to one of the eBay breeches. Yes, I used the same password for both (never got around to changing them after I made the transition to randomized passwords) so it's my fault, right?
How about great big "fuck you" instead? How about a wall of shame for every website that does not hash passwords, with salt, prior to transmission over the internet? This is kiddy level shit here. The slowest smartphone in the world should be able to do this in its sleep.
And the majority of sites still have incredibly stupid password policies, almost all forcing you to use special characters and numbers instead of long passphrases which, if properly constructed (such as via dicewords), can be considerably more secure than the average "unicorn16!" type password. Some sites even impose a ridiculous maximum length policy, and some sites also forbid certain special characters, probably for some horribly depressing reason like they can't be bothered to make sure the password field can't be used for SQL injection or overflow attacks.
Work passwords aren't much better. The constant changing is completely pointless; everyone either uses a very simple incrementing number system (often tied to the current month) or they use Post-Its. A sane alternative would be to track logins and alert the user and/or security admins of unusual times or locations and to use keyfiles on smartcards or regular USB drives.
I've checked the literature and these ridiculous practices are still being taught to people studying for CompTIA certifications. Can't someone please... I don't know, do something about this? Can't we have some industry leaders say that they're no longer recognizing CompTIA Security+ or Network+ certifications as worth anything? This shit has been going on for far too long, and in an effort to made up for their shitty password infrastructure many places are adopting painfully annoying supplementary security systems.
assuming the switching speed remains roughly constant, I suppose.
I meant more in terms of existing and widely deployed products seamlessly supporting these alternate keying methods, though I guess I should dig through the details of the TLS standard sometime to see what can be done, at least in theory.
By the time we know for sure it's feasible, I suspect we'll be pretty darn close to having something real to worry about. A lot of people used to claim that Van Eck interception was infeasible in real world conditions but, uh... it's not. Seeing as how it not only allows for unlimited interception of encrypted data but also unlimited spoofing, it's not unreasonable to say that if they can ever figure out a way to do it in a less than 10 figure budget, they will. And they won't be in any hurry to hint at the fact that they can until other world powers begin to develop the same capabilities.
Maybe someone out there could crunch some back of the napkin numbers to estimate how many qubits would be needed for reasonably fast break of a 2048 bit RSA key?
And ECC. Probably not with this generation, but it's entirely possible three letter organizations are close to having a machine that can at least break smaller key sizes. Which in and of itself isn't especially worrying, except that the more sophisticated and rogue state-sponsored criminals won't be lagging very far behind.
There's no good reason why our web security infrastructure shouldn't immediately begin upgrades to support multiple, extensible and arbitrary methods of key exchange, including but not limited to stateful solutions using out of band preshared keys. Given it would only costs a few bucks to buy a gigabyte of key material stored on redundant robust flash memory, and each symmetric key wouldn't need to be more than a kilobit at the most, and in principle one would only need a couple keys to securely receive keys generated by trusted session key providing servers...
But what am I saying, this is an industry that had to scramble when somebody realized that the year 1999 was going to be followed by the year 2000. So it's probably far too optimistic to hope for an 'ounce of prevention' approach here.
I see you conveniently replied only to the above post, instead of the one where I did cover the specifics. You also appeared to ignore some other posts were other people mentioned the specifics. On top of this, you've completely ignored my attempts to explain how little fuel waste there need be, in principle.
So no, I don't particularly feel like providing you with an in-depth, blow by blow, thoroughly sourced analysis unless you pay me. However, I am still curious what it's like to be a grown man who would rather believe that the science and the numbers lie instead of considering the possibility that people simply suck.
Maybe this is just a German thing?
Any state not having a verifiable paper trail as a backup is insane.
Yes, and this is a pretty big indictment of the laziness (...or cynical job protection) of IT experts. They've had 16 years to explain to people that the best way to secure and streamline the infrastructure is also the cheapest: optical scanners backed by random double-checking with hand counts, with a few statisticians on hand to flag any suspicious-looking results that should be audited. Black box systems that don't involve a paper trail are more expensive, incur additional expenses in auditing and hardening, and inevitably turned out to be much less reliable than the old methods... now we're seeing hints that these things are actually being networked? If each individual vote-counting machine were kept separate and offline then the attackers' job becomes completely impractical, as they would have to successfully attack a large proportion of the machines involved in an election in person in order to change the outcome.
In case you're still convinced the nuclear industry report drafters know what they're talking about, other posters have already replied to you with some specifics: apparently fuel is being thrown away while it's still useful due to structural heat-induced changes in the ingots, and it's also apparently the case that "spent" fuel (which in its original state is really something like 95% non-fuel blended with ~5% fuel) is currently tossed aside instead of being re-enriched with active isotopes. There are probably hundreds of economically feasible ways to address these problems. Non-fuel waste is similarly mitigatable by using materials less vulnerable to neutron embrittlement, using more durable parts and machines in general, and decreasing the amount time that certain bits are exposed to intense neutron radiation.
Probably what happened was older techniques and designs assumed that it wasn't going to be too big a deal to simply throw this stuff away (because people threw away non-nuclear highly toxic waste all of the time, so they weren't anticipating anti-nuclear hysteria leading to the government demanding the use of super secured dump sites), and out of stubbornness or sloth or subsidy they've continued doing what they originally planned on doing, but there's no compelling reason why the plants have to produce much waste.
Stupidogenesis is not something I research for fun. Pay me money for my time and I'll examine the plans, crunch the numbers and explain to you precisely how this issue of too much waste came about and how it could easily be solved... but that wasn't what this thread was originally about. It was about the intrinsic expenses of nuclear power.
Your deference to reports drafted by incompetent people probably using outdated designs is unbelievable.
I don't know or care how much waste the assholes are producing now. I am saying that any competent engineer could easily produce a design that could store all of its waste on-site, because the mechanics of basic nuclear power generation do not generate much waste. This thread has been about refuting claims that nuclear is intrinsically more expensive than other options, which it is not.
I have no desire whatsoever to prove that people currently running the nuclear industry in this country are competent. If this industry is like most industries older than fifty years then the answer is no, probably not.
They are not 'wacky' beliefs; they are scientifically literate ones. If they are producing so much waste that it cannot physically remain on-site then someone has fucked up, period. The fuel waste alone should be very, very, very small. The non-fuel waste can and should be minimized. If you're producing so much non-fuel waste that it won't fit on the lot then either the designer or the operator(s) of the plant has been moronically reckless.
Clear thinking and scientific literacy should never take a back seat to the reports produced by bureaucratic incompetents.