You've yet to give a single concrete criticism of my ideas except that I said "cryptographically secure hash" instead of "iterated hash." You know why I said that? Because I don't KNOW what the most secure hashing method is, the precise details of its operation, or what it is officially named! It's your job to know that shit. You. The alleged professional.
This is just pitiful. A 5 digit ID and an alleged professional and the best you can do is a hand-waving appeal to your alleged professionalism. You can't haven't come up with a single relevant criticism of the substance of my ideas, even after I sincerely offered a $1000 reward for doing so. Here, I'll get you started.... here are some SAMPLE criticisms you might conceivably put forth:
1. Do you think the hashed passwords can be reverse-engineered so quickly as to make the protection irrelevant? (If so, you know clearly something about modern hashing algorithms that the rest of us don't, and I'd be very interested to hear it. Or would you have to kill me if you told me?)
2.Do you think that a secure-enough hashing algorithm would be too computationally expensive, even though I explicitly said we were talking about situations where HTTPS was being used?
3. Do you think that there is some other huge advantage to having passwords stored in plaintext on the server? (I really can't think of any)
4. Do you dispute that Yahoo was storing passwords in plaintext in this case? (I haven't looked at the details here but the article summary clearly implies that this was the case, as all offline users with strong passwords should be unaffected by any database leak if hashing were properly implemented, because their pre-(server) hashed passwords could not be known.)
5. Do you think compliance will be too hard to enforce? I've already conceded this is tricky for the server hash, but I also made clear that was one of the biggest reasons to also use a client-side hash. I explicitly said that this could in principle be audited and pressure put on anyone who refuses to use client-side hashing.
6. Summarize your defense of yahoo's security practices at the time of this breach.
7. Summarize your ideal solution or mitigation for database leaks, preferably one that does not require that the users jump through any hoops (Since I acknowledged that these solutions, while obviously stronger in principle, are harder to convince people to implement or correctly follow.)
8. You might complain that there is prior art or what I'm suggesting is non-optimal. This objection has already been raised and conceded on my part, but that doesn't mean my idea is "broken", merely that they're not completely novel and they could be improved with further tweaks. And I'm not at all surprised about either of those things. I never claimed to be original or definitive. This was a ten minute post inspired by some drunken brainstorming I did two nights ago, and I'm not a crypto professional.
But you don't need to be an attack dog expert to realize that Chihuahuas make shitty attack dogs. "You should buy a bigger dog" is the correct solution, even if I can't tell you the exact breed to buy because I'm not a dog expert. I might even be wrong about it being a Chihuahua. I might be such a ignoramus when it comes to dogs that I call it a Pug. But you know what? That doesn't mean my solution to buy a bigger dog is "broken".
And you're a twat for attacking me instead of the incompetents over at Yahoo. Not because I'm thin-skinned, but because it is a travesty that total incompetents are put in positions of power and allowed to severely inconvenience (sometimes even ruin the lives of) millions of people and as an alleged security professional this should be the only thing you care about here.
Also, as I stated in one of my early clarification posts, by "cryptographically secure hash" I was referring to the most secure hashing functions available regarding leakage or collisions. If the most secure hashing function is a form of iterated hashing than that's the one I was referring to.
This is like me criticizing someone for using a longhaired Chihuahua as an attack dog, and your response is that I'm a moron and my suggestion is "broken" because that's really a Pomeranian, not a Chihuahua. Congratulations, but that's not what the discussion is about. I've already conceded that I'm probably not using perfect terminology, but my intent is clear. People are doing dumb shit that is severely inconveniencing millions of people. Here is *a* fix. You, the professional, go make my fix better by fleshing out the details or finding an existing concept that does something similar.
Or stand here and argue my ideas are inherently broken, and keep arguing that every idea for reform is broken when it comes out next month that Amazon was storing all of *their* passwords in plaintext in a database, which has just been leaked.
I proposed a fix for an existing problem. You said my fix was broken.
If you, the alleged professional, want to improve on my fix then I'm sure you could. That does not change the fact that my fix is in fact a fix that is objectively superior to the way these assholes are currently conducting things. And it doesn't change the fact that my fix is not actually broken, merely that it requires fleshing out.
And I never said it didn't. This was obviously a 5000 foot proof of concept thing that I literally bashed out as I was eating a sandwich. If you want me to do the research and write you a fucking dissertation with 100% correct terminology and proper usage of every single crytographic technique, I require prepayment for my time.
Your claim that my fix (for the still-prevalent practice of plaintext password storage) is broken is clearly false, but you still can't admit it.
I don't come to slashdot to suck up to people by pretending bad ideas aren't bad. Storing passphrasses as plaintext, as many sites are clearly doing, is an objectively horrible idea that my easy-to-implement solution fixes.
It may not be the optimum solution, but it is easy, cheap and effective for the purposes I've described. People who think that extreme politeness should come before correctness are a major scourge in this world.
I haven't had time yet to digest it in detail but it is indeed interesting.
The one valid criticism of my ideas are that they don't go far enough; the instant I read 'challenge-response' in the article title I said to myself "oh, well, that's going to be even better." I don't claim to be the final word in these matters; I don't do this shit for a living. That doesn't change the fact that my recommendations are dirt-simple, low overhead, powerful and require nothing extra from the user (although they should still be using strong passphrases for maximum benefit.) If this basic idea can be made even better with a challenge response then by all means, let's do that instead.
This is like me noticing that firemen lined up using thimbles to ferry water to the scene of a crash. My suggestion to use buckets instead may not be the global optimum solution, but it is clearly a huge improvement.
I never claimed it was novel. It just isn't being used and it should be.
If people want to pay me to search for prior art for every single post I make, I'd be happy to. The point isn't that I'm the first one to think of what is, at root, an extremely obvious idea once one-way hash functions were developed for cryptographic use. The point is that the vast majority of industry leaders are not properly using these functions, even though they would require very little overhead, no changes that the user would notice and yet would offer a TON of mitigation for these types of breaches for users of strong passphrases. There would also be moderate mitigation for users of weaker passphrases--they may have enough time to change their passphrase before the attack can get around to cracking their hash (in this case, out of the hundreds of millions that have been stolen.)
I also require prepayment if you want me to take the time to phrase everything in extremely polite or modest terms. People are doing stupid things and it's fucking up the lives of millions of people. Here's a fairly effective solution, not 100% effective but it's very easy to implement and makes life a lot more difficult for the attacker. Go use it. Refuse to use it, and I will call you a dumbass the next time one of these breaches happen and they one again imply that login credentials were stolen even for users who were not logged while the attack was in progress.
If at that point you want to call me an arrogant jerk for my criticism, feel free. But they'd still be dumbasses for not taking these simple measures.
I'll put it to a slashdot vote. If they vote that you've rebutted the core of my argument (not quibbled over about individual sentences from a hastily written post that was never intended as a doctoral dissertation), you get the money.
Come on, you old-timer fraud. Put up or shut up. You're either too lazy to read what I've said in detail or you know I'm right and you're continuing on out of stubbornness.
A thousand dollars if you can back up your bullshit with sound rebuttals. I'm serious.
Typos and misparsing of sentences from my original very quickly written post do not count--I've already given you multiple clarifications of what I'm intending here and what the benefits would and would not include.
I don't care about terminology quibbles. I've already repeatedly stated elsewhere that I'm not a professional. If you do know anything at all about cryptography, I am assuming that you understood what I mean. Hashing functions can more either more or less secure when it comes to collisions or leaking information about the information being hashed. In my post, I was referring only to the most secure hash functions available.
The fact is that passwords are being routinely being stored in plaintext and this is causing tons of problems for people using and/or reusing STRONG passphrases. Proper hashing should in principle remove these concerns, make it much harder to log into the account of someone who uses a strong passphrase even after a database breach, and make it much, MUCH harder to break into another account elsewhere that uses the same password (but different salt.)
At no point did I argue that my solution was a comprehensive one; I explicitly noted that I was taking HTTPS for granted. I also said that certain supplemental pieces like secret keyfiles would be beneficial, though they require more effort on the part of the user and thus are less likely to be widely implemented.
Furthermore, there are time delay benefits even for users of weaker passphrases, particularly in mass leaks like this where the attacker can't possibly crack hundreds of millions of passwords in a short time frame. This time delay allows more people to change their passphrase in time.
If you disagree then explain yourself. Or you can keep on making an ass of yourself; it's your choice.
Yup. I just offered $1000 to the first person to prove me wrong on my main points here (with some caveats.) I mean it, too.
I'm not a security professional or even an IT professional; I just understand things. That unfortunately puts me at a disadvantage in these sorts of conversations. The world doesn't need more false modesty. I may not have used the precisely correct or most common terminology, or laid it out in exacting detail with every single sentence double-checked (because this was a 10 minute slashdot post, not a whitepaper or a doctoral dissertation) but my analyses and arguments here are fundamentally sound.
Nothing? No response at all? How's this then: $1000 to the first one to show how my primary claims here are wrong.
Before attempting this, please be sure to read all of my clarifications (particularly on the benefits this provides to weak vs. strong passphrases). No reward will be given for typos or any incorrect parsing of individual sentences.
Alternatively, here is a message to other mods: an absence of such explanation should be indicative of the fact that these naysayers have, in fact, no idea what they are talking about. And so you really should mod me up as informative, not because I need the karma (I don't), but because we really need to raise awareness that these sorts of security breaches could be mitigated and minimized with a trivial amount of effort.
These extra protections are primarily for those users who have strong passphrases that can't be brute-forced even with heavy offline analysis, but even users with weak passwords will have a little extra protection in that they will have extra time to change their password before the attacker can get around to cracking their plaintext password (which, in the case of hundreds of millions of accounts, could be a great many weeks later.)
People who've modded this up: Please post AC to explain to me why my system would not work. I look forward to clarifying and/or educating you about how hashing works.
The client also needs updating if the client's hashing algorithm is vulnerable to collision attacks, but assuming we're talking about a widely-adopted standard that uses a single service (preferably built into the browser itself), this would be a one time update that (assuming automatic security updates are enabled) wouldn't require special action on the part of the user.
Second clarification: A collision attack on the hashing algorithm does present a problem under this scheme, but it is not a problem that results in the plaintext password from being known. The moment a feasible collision attack with known salt becomes known, the server can safeguard themselves by simply change their hashing algorithm and urges all users to log in as soon as possible, but note two things here:
1. The users do not need to change their password (particularly if it's a strong password, or if there has been no known database breach.) The upgrade can happen transparently and silently and happens entirely server-side, the very next time the user logs in.
2. As implied by #1, a collision vulnerability alone is useless without a database breach also being present.
FYI, I've never worked in IT security in my life, yet I'm pretty sure that half of what CompTIA teaches in Security+ is (at best) snake oil.
To clarify: this offers only weak (time-delay) protection for bad passwords. Bad passwords (ones that can be brute forced with offline analysis) would still need to be updated as soon as possible if a database breach happens whilst using this system, but it should still buy some time for people to do this. The only strong protections that can be offered for bad passwords are online delays (which immediately becomes useless once the database is compromised by an attacker) or secondary verification steps (secret keyfiles, biometrics, whatever).
But the protection this scheme offers to users with robust passwords are massive. As it currently stands, users with good passwords are routinely getting screwed by huge companies that really, really should know better.
So, here is the way to fix this sort of thing using very old, very simple, freely-available tech:
First, all passwords are hashed with salt on the client. If you want to protect a bad (brute force-able) password, you could use secret salt (i.e. a keyfile) hashing layer separately but for maximum portability known salt (like the base domain, "yahoo.com") should be used. This will protect good passwords from being brute-forced without something on the client being compromised, and offers strong protection for password reuse (regardless of whether or not reuse with different services is ill-advised, it will always happen.)
Ideally, this needs to happen via a special API call to the browser itself and not by scripting on the website. The browser is already aware of password fields (this is how it offers to remember logins for you) and thus can in principle alert you whenever an insecure passfield field (or whenever 'no legitimate password field') is present. This would prevent all but the most careless users from having a spoofed website discover their plaintext passwords. I would much prefer that the browser itself handle this hashing but even a javascript implementation of client-side hashing would be a huge improvement over the status quo, primarily because the presence of client-side hashing can be easily detected and audited whilst we have to take them at their word if they claim to be doing this all securely on the backend. (And also because a client-side hash reduces the attack surface such that a database breach or HTTPS attack alone is insufficent--with JS client-side hashing, only a successful website spoof that is undetected by the browser would reveal the plaintext password.)
Next, on the server side, the already client-hashed password is hashed a second time prior to being stored in the database. What does this accomplish? I'm glad you asked! What this means is that a simple read-only database breach does not allow an attacker to log into anyone's account. This is because if they try to use the value stored in the database (post server-hash), it will be hashed a second time prior to being compared to the value in the database, and this second hashing will result in a mismatch. Thus, a successful attack would need to either intercept the pre-server hash value in memory (a much more difficult feat, and one that will only reveal users that log in while the attack is in progress), or they need write permission to the database to overwrite the password, which should sound the alarm in two ways: one by (hopefully) causing database integrity checks to fail, and another by locking users out of their accounts.
The upside of all of this: Good passwords remain safe to reuse on other websites (so long as everyone uses these standards. Websites and apps refusing to use these standards should be aggressively warned against.) Even with bad passwords, it's much harder for attackers to gain access to accounts, and the number of accounts compromised should be reduced. And the CPU load of doing this hashing should be minimal compared with the overhead that HTTPS already imposes.
Now tell me, can anyone explain why this isn't happening yet? This sort of thing would allow us to stop insisting that the most important thing users need to do is memorize a different quality password for every single account they have (impossible for most people.) The elbow grease to do this is minimal and with enough of an outcry, we could easily shame these big name companies into adopting these standards.
(And please, for all you anonymous cowards who want to tell me that hashing with known salt values are useless... go educate yourself on the properties of cryptographically-secure hash algorithms. I don't care about pre-computed rainbow tables. This isn't about protecting weak passwords from brute force attacks. Once offline attacks become possible--which happens whenever a hashed value becomes known, provided the hashing algorithm and salt are both k
And once again, I'm only talking about protecting good passwords. Protecting bad passwords that can be broken by brute force is impossible without introducing another verification system that essentially replaces the password as the main point of failure, but it becomes much easier to convince users to use good passwords if we can allow them to reuse them (and also not have to change them every month.)
I know I earlier said that I wouldn't mind seeing this implemented in JS, but on reflection I think this should become a deep and universal standard such that it is handled by a special api call to the browser itself. Thus, only a compromise of the browser itself (and not merely the website) should reveal the original plaintext password. All secure password fields should be colored or highlighted by the browser in an un-spoofable way by the browser. However, I still believe that even a JS implementation (assuming the site in question already requires JS) would be an improvement over the status quo for auditing and reduced attack surface reasons, though a server-side hash should always been used to reduce the usefulness of database breaches (see my reply to wagnerrp below for a full description of how that should work.)
(Speaking of unspoofable GUIs, Joanna Rutkowska, the lead dev for Qubes, has some interesting ideas about display security and points out that for all of its flaws, Windows 7's UAC actually is superior to most implementations of sudo on Linux because the display-darkening prompt is much harder to spoof and doesn't reveal a superuser password even if it is spoofed.)
I don't know or particularly care how yahoo did things. From your brief description, it sounds like they did things fairly moronically. Both clientside and serverside hashing have a function: client-side reduces the attack surface to the least possible extent for discovering the plaintext passphrase, whilst proper server-side hashing can prevent a read-only database breach from being used to break into an account.
Client-side is the most easily auditable version and as I said, offers the maximum protection against the actual password being found out. If the hashing is handled by a website script, then only a compromise of that website could reveal the pre-hashed password. If the hashing could be handled by the browser itself prior to passing to the website, then only a compromise of the browser itself would reveal the pre-hashed password. Concealing the pre-hashed password is important because it encourages and allows people to take the time to memorize a really strong one and re-use it, which is something that currently isn't viable due to the fact that many big name places store passwords in plaintext.
Serverside hashing has its uses as well. If handled correctly, then it can prevent an attacker with simple database read access (but no write access) from being able to access arbitrary accounts. The server should hash all incoming passwords (which have already been hashed with salt on clientside) with different salt. This salt can be known or not; it doesn't really matter. The passphrase stored in the database will be the doubly salted-hashed password (once on client, once on server.) So, let's say the entire contents of the database is read by an attacker. That means they can access any account they want, right?
Wrong. Read-only access buys the attacker NOTHING, assuming it is a strong password. (I do not care about protecting weak passwords that can be cracked with brute force here.) He needs the pre-hash value in order to log into an arbitrary account. If he tries to use the server-hashed version of the password (which is the only one permanently stored on disk), it will be hashed AGAIN by the server before it is compared to the one in the database, and thus will not match. So, the attacker has to do more than just access the database; he has to either be able to write to it (to overwrite the server-hashed value with something of his own choosing, which should have the undesirable side effect of spoiling database integrity checks and locking the rightful owner out of his/her own account, thus raising the alarm) or he needs to be able to intercept the pre-server hashed password in memory, since the pre-server hashed password should never be written to disk.
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.
reply to your other post*. Sorry, 'email' on the brain. Nothing of vital importance was lost with either the eBay account or email address, mind, but there were thousands of nostalgic emails in there that I'll never see again, some of them from people I'll never see again.
Yes, I've since clarified ad nauseum that the password was a strong one. Protecting bad passwords is intrinsically impossible. You can use a keyfile but that's basically akin to having a strong password and then writing it down in notepad.
See my reply to your other email for my response on the "this wouldn't add to security." I think the big takeaway is it's visible and auditable and it would thus in principle be possible (with enough of an outcry) to force an industry standard to be adopted and aggressively shame and warn against sites that refuse to adopt it. "But we do it all perfect on our server!" just doesn't cut it, sorry. I. don't. believe. you.
You're also wrong to imply there's no theoretical advantage whatsoever to a client side hash. HTTPS is very important but successful attacks aren't unheardof. Client hashing would prevent collateral damage in such cases (assuming the client hash scripting runs and transmits correctly--I'm not talking about successful whole-website spoofing that uses a different script entirely.)
Furthermore, putting this on the client reduces the attack surface of the server, since only a website spoof would suffice (if you could only gain access to the back end, you would have no way of forcing it to start recording plaintext passwords if hashing were being done on the client.) I do support the idea of a second hash prior to database storage, but it doesn't and cannot replace the client hash stage.
Slashdot Mirror
You've yet to give a single concrete criticism of my ideas except that I said "cryptographically secure hash" instead of "iterated hash." You know why I said that? Because I don't KNOW what the most secure hashing method is, the precise details of its operation, or what it is officially named! It's your job to know that shit. You. The alleged professional.
This is just pitiful. A 5 digit ID and an alleged professional and the best you can do is a hand-waving appeal to your alleged professionalism. You can't haven't come up with a single relevant criticism of the substance of my ideas, even after I sincerely offered a $1000 reward for doing so. Here, I'll get you started.... here are some SAMPLE criticisms you might conceivably put forth:
1. Do you think the hashed passwords can be reverse-engineered so quickly as to make the protection irrelevant? (If so, you know clearly something about modern hashing algorithms that the rest of us don't, and I'd be very interested to hear it. Or would you have to kill me if you told me?)
2.Do you think that a secure-enough hashing algorithm would be too computationally expensive, even though I explicitly said we were talking about situations where HTTPS was being used?
3. Do you think that there is some other huge advantage to having passwords stored in plaintext on the server? (I really can't think of any)
4. Do you dispute that Yahoo was storing passwords in plaintext in this case? (I haven't looked at the details here but the article summary clearly implies that this was the case, as all offline users with strong passwords should be unaffected by any database leak if hashing were properly implemented, because their pre-(server) hashed passwords could not be known.)
5. Do you think compliance will be too hard to enforce? I've already conceded this is tricky for the server hash, but I also made clear that was one of the biggest reasons to also use a client-side hash. I explicitly said that this could in principle be audited and pressure put on anyone who refuses to use client-side hashing.
6. Summarize your defense of yahoo's security practices at the time of this breach.
7. Summarize your ideal solution or mitigation for database leaks, preferably one that does not require that the users jump through any hoops (Since I acknowledged that these solutions, while obviously stronger in principle, are harder to convince people to implement or correctly follow.)
8. You might complain that there is prior art or what I'm suggesting is non-optimal. This objection has already been raised and conceded on my part, but that doesn't mean my idea is "broken", merely that they're not completely novel and they could be improved with further tweaks. And I'm not at all surprised about either of those things. I never claimed to be original or definitive. This was a ten minute post inspired by some drunken brainstorming I did two nights ago, and I'm not a crypto professional.
But you don't need to be an attack dog expert to realize that Chihuahuas make shitty attack dogs. "You should buy a bigger dog" is the correct solution, even if I can't tell you the exact breed to buy because I'm not a dog expert. I might even be wrong about it being a Chihuahua. I might be such a ignoramus when it comes to dogs that I call it a Pug. But you know what? That doesn't mean my solution to buy a bigger dog is "broken".
And you're a twat for attacking me instead of the incompetents over at Yahoo. Not because I'm thin-skinned, but because it is a travesty that total incompetents are put in positions of power and allowed to severely inconvenience (sometimes even ruin the lives of) millions of people and as an alleged security professional this should be the only thing you care about here.
Also, as I stated in one of my early clarification posts, by "cryptographically secure hash" I was referring to the most secure hashing functions available regarding leakage or collisions. If the most secure hashing function is a form of iterated hashing than that's the one I was referring to.
This is like me criticizing someone for using a longhaired Chihuahua as an attack dog, and your response is that I'm a moron and my suggestion is "broken" because that's really a Pomeranian, not a Chihuahua. Congratulations, but that's not what the discussion is about. I've already conceded that I'm probably not using perfect terminology, but my intent is clear. People are doing dumb shit that is severely inconveniencing millions of people. Here is *a* fix. You, the professional, go make my fix better by fleshing out the details or finding an existing concept that does something similar.
Or stand here and argue my ideas are inherently broken, and keep arguing that every idea for reform is broken when it comes out next month that Amazon was storing all of *their* passwords in plaintext in a database, which has just been leaked.
I proposed a fix for an existing problem. You said my fix was broken.
If you, the alleged professional, want to improve on my fix then I'm sure you could. That does not change the fact that my fix is in fact a fix that is objectively superior to the way these assholes are currently conducting things. And it doesn't change the fact that my fix is not actually broken, merely that it requires fleshing out.
And I never said it didn't. This was obviously a 5000 foot proof of concept thing that I literally bashed out as I was eating a sandwich. If you want me to do the research and write you a fucking dissertation with 100% correct terminology and proper usage of every single crytographic technique, I require prepayment for my time.
Your claim that my fix (for the still-prevalent practice of plaintext password storage) is broken is clearly false, but you still can't admit it.
I don't come to slashdot to suck up to people by pretending bad ideas aren't bad. Storing passphrasses as plaintext, as many sites are clearly doing, is an objectively horrible idea that my easy-to-implement solution fixes.
It may not be the optimum solution, but it is easy, cheap and effective for the purposes I've described. People who think that extreme politeness should come before correctness are a major scourge in this world.
I haven't had time yet to digest it in detail but it is indeed interesting.
The one valid criticism of my ideas are that they don't go far enough; the instant I read 'challenge-response' in the article title I said to myself "oh, well, that's going to be even better." I don't claim to be the final word in these matters; I don't do this shit for a living. That doesn't change the fact that my recommendations are dirt-simple, low overhead, powerful and require nothing extra from the user (although they should still be using strong passphrases for maximum benefit.) If this basic idea can be made even better with a challenge response then by all means, let's do that instead.
This is like me noticing that firemen lined up using thimbles to ferry water to the scene of a crash. My suggestion to use buckets instead may not be the global optimum solution, but it is clearly a huge improvement.
I never claimed it was novel. It just isn't being used and it should be.
If people want to pay me to search for prior art for every single post I make, I'd be happy to. The point isn't that I'm the first one to think of what is, at root, an extremely obvious idea once one-way hash functions were developed for cryptographic use. The point is that the vast majority of industry leaders are not properly using these functions, even though they would require very little overhead, no changes that the user would notice and yet would offer a TON of mitigation for these types of breaches for users of strong passphrases. There would also be moderate mitigation for users of weaker passphrases--they may have enough time to change their passphrase before the attack can get around to cracking their hash (in this case, out of the hundreds of millions that have been stolen.)
I also require prepayment if you want me to take the time to phrase everything in extremely polite or modest terms. People are doing stupid things and it's fucking up the lives of millions of people. Here's a fairly effective solution, not 100% effective but it's very easy to implement and makes life a lot more difficult for the attacker. Go use it. Refuse to use it, and I will call you a dumbass the next time one of these breaches happen and they one again imply that login credentials were stolen even for users who were not logged while the attack was in progress.
If at that point you want to call me an arrogant jerk for my criticism, feel free. But they'd still be dumbasses for not taking these simple measures.
I'll put it to a slashdot vote. If they vote that you've rebutted the core of my argument (not quibbled over about individual sentences from a hastily written post that was never intended as a doctoral dissertation), you get the money.
Come on, you old-timer fraud. Put up or shut up. You're either too lazy to read what I've said in detail or you know I'm right and you're continuing on out of stubbornness.
A thousand dollars if you can back up your bullshit with sound rebuttals. I'm serious.
Typos and misparsing of sentences from my original very quickly written post do not count--I've already given you multiple clarifications of what I'm intending here and what the benefits would and would not include.
I don't care about terminology quibbles. I've already repeatedly stated elsewhere that I'm not a professional. If you do know anything at all about cryptography, I am assuming that you understood what I mean. Hashing functions can more either more or less secure when it comes to collisions or leaking information about the information being hashed. In my post, I was referring only to the most secure hash functions available.
The fact is that passwords are being routinely being stored in plaintext and this is causing tons of problems for people using and/or reusing STRONG passphrases. Proper hashing should in principle remove these concerns, make it much harder to log into the account of someone who uses a strong passphrase even after a database breach, and make it much, MUCH harder to break into another account elsewhere that uses the same password (but different salt.)
At no point did I argue that my solution was a comprehensive one; I explicitly noted that I was taking HTTPS for granted. I also said that certain supplemental pieces like secret keyfiles would be beneficial, though they require more effort on the part of the user and thus are less likely to be widely implemented.
Furthermore, there are time delay benefits even for users of weaker passphrases, particularly in mass leaks like this where the attacker can't possibly crack hundreds of millions of passwords in a short time frame. This time delay allows more people to change their passphrase in time.
If you disagree then explain yourself. Or you can keep on making an ass of yourself; it's your choice.
Yup. I just offered $1000 to the first person to prove me wrong on my main points here (with some caveats.) I mean it, too.
I'm not a security professional or even an IT professional; I just understand things. That unfortunately puts me at a disadvantage in these sorts of conversations. The world doesn't need more false modesty. I may not have used the precisely correct or most common terminology, or laid it out in exacting detail with every single sentence double-checked (because this was a 10 minute slashdot post, not a whitepaper or a doctoral dissertation) but my analyses and arguments here are fundamentally sound.
And compelling.
Nothing? No response at all? How's this then: $1000 to the first one to show how my primary claims here are wrong.
Before attempting this, please be sure to read all of my clarifications (particularly on the benefits this provides to weak vs. strong passphrases). No reward will be given for typos or any incorrect parsing of individual sentences.
Alternatively, here is a message to other mods: an absence of such explanation should be indicative of the fact that these naysayers have, in fact, no idea what they are talking about. And so you really should mod me up as informative, not because I need the karma (I don't), but because we really need to raise awareness that these sorts of security breaches could be mitigated and minimized with a trivial amount of effort.
These extra protections are primarily for those users who have strong passphrases that can't be brute-forced even with heavy offline analysis, but even users with weak passwords will have a little extra protection in that they will have extra time to change their password before the attacker can get around to cracking their plaintext password (which, in the case of hundreds of millions of accounts, could be a great many weeks later.)
People who've modded this up: Please post AC to explain to me why my system would not work. I look forward to clarifying and/or educating you about how hashing works.
You are ignorant of simple cryptographic truths and it is very. very sad (because you are definitely not the only one.)
Go read up on cryptographically secure hashing and explain to me how my system would fail to prevent the attacks I describe.
The client also needs updating if the client's hashing algorithm is vulnerable to collision attacks, but assuming we're talking about a widely-adopted standard that uses a single service (preferably built into the browser itself), this would be a one time update that (assuming automatic security updates are enabled) wouldn't require special action on the part of the user.
Second clarification: A collision attack on the hashing algorithm does present a problem under this scheme, but it is not a problem that results in the plaintext password from being known. The moment a feasible collision attack with known salt becomes known, the server can safeguard themselves by simply change their hashing algorithm and urges all users to log in as soon as possible, but note two things here:
1. The users do not need to change their password (particularly if it's a strong password, or if there has been no known database breach.) The upgrade can happen transparently and silently and happens entirely server-side, the very next time the user logs in.
2. As implied by #1, a collision vulnerability alone is useless without a database breach also being present.
FYI, I've never worked in IT security in my life, yet I'm pretty sure that half of what CompTIA teaches in Security+ is (at best) snake oil.
To clarify: this offers only weak (time-delay) protection for bad passwords. Bad passwords (ones that can be brute forced with offline analysis) would still need to be updated as soon as possible if a database breach happens whilst using this system, but it should still buy some time for people to do this. The only strong protections that can be offered for bad passwords are online delays (which immediately becomes useless once the database is compromised by an attacker) or secondary verification steps (secret keyfiles, biometrics, whatever).
But the protection this scheme offers to users with robust passwords are massive. As it currently stands, users with good passwords are routinely getting screwed by huge companies that really, really should know better.
So, here is the way to fix this sort of thing using very old, very simple, freely-available tech:
First, all passwords are hashed with salt on the client. If you want to protect a bad (brute force-able) password, you could use secret salt (i.e. a keyfile) hashing layer separately but for maximum portability known salt (like the base domain, "yahoo.com") should be used. This will protect good passwords from being brute-forced without something on the client being compromised, and offers strong protection for password reuse (regardless of whether or not reuse with different services is ill-advised, it will always happen.)
Ideally, this needs to happen via a special API call to the browser itself and not by scripting on the website. The browser is already aware of password fields (this is how it offers to remember logins for you) and thus can in principle alert you whenever an insecure passfield field (or whenever 'no legitimate password field') is present. This would prevent all but the most careless users from having a spoofed website discover their plaintext passwords. I would much prefer that the browser itself handle this hashing but even a javascript implementation of client-side hashing would be a huge improvement over the status quo, primarily because the presence of client-side hashing can be easily detected and audited whilst we have to take them at their word if they claim to be doing this all securely on the backend. (And also because a client-side hash reduces the attack surface such that a database breach or HTTPS attack alone is insufficent--with JS client-side hashing, only a successful website spoof that is undetected by the browser would reveal the plaintext password.)
Next, on the server side, the already client-hashed password is hashed a second time prior to being stored in the database. What does this accomplish? I'm glad you asked! What this means is that a simple read-only database breach does not allow an attacker to log into anyone's account. This is because if they try to use the value stored in the database (post server-hash), it will be hashed a second time prior to being compared to the value in the database, and this second hashing will result in a mismatch. Thus, a successful attack would need to either intercept the pre-server hash value in memory (a much more difficult feat, and one that will only reveal users that log in while the attack is in progress), or they need write permission to the database to overwrite the password, which should sound the alarm in two ways: one by (hopefully) causing database integrity checks to fail, and another by locking users out of their accounts.
The upside of all of this: Good passwords remain safe to reuse on other websites (so long as everyone uses these standards. Websites and apps refusing to use these standards should be aggressively warned against.) Even with bad passwords, it's much harder for attackers to gain access to accounts, and the number of accounts compromised should be reduced. And the CPU load of doing this hashing should be minimal compared with the overhead that HTTPS already imposes.
Now tell me, can anyone explain why this isn't happening yet? This sort of thing would allow us to stop insisting that the most important thing users need to do is memorize a different quality password for every single account they have (impossible for most people.) The elbow grease to do this is minimal and with enough of an outcry, we could easily shame these big name companies into adopting these standards.
(And please, for all you anonymous cowards who want to tell me that hashing with known salt values are useless... go educate yourself on the properties of cryptographically-secure hash algorithms. I don't care about pre-computed rainbow tables. This isn't about protecting weak passwords from brute force attacks. Once offline attacks become possible--which happens whenever a hashed value becomes known, provided the hashing algorithm and salt are both k
Aww comeon, give this one more +1 funny! I was hoping for a reply like this.
And once again, I'm only talking about protecting good passwords. Protecting bad passwords that can be broken by brute force is impossible without introducing another verification system that essentially replaces the password as the main point of failure, but it becomes much easier to convince users to use good passwords if we can allow them to reuse them (and also not have to change them every month.)
I know I earlier said that I wouldn't mind seeing this implemented in JS, but on reflection I think this should become a deep and universal standard such that it is handled by a special api call to the browser itself. Thus, only a compromise of the browser itself (and not merely the website) should reveal the original plaintext password. All secure password fields should be colored or highlighted by the browser in an un-spoofable way by the browser. However, I still believe that even a JS implementation (assuming the site in question already requires JS) would be an improvement over the status quo for auditing and reduced attack surface reasons, though a server-side hash should always been used to reduce the usefulness of database breaches (see my reply to wagnerrp below for a full description of how that should work.)
(Speaking of unspoofable GUIs, Joanna Rutkowska, the lead dev for Qubes, has some interesting ideas about display security and points out that for all of its flaws, Windows 7's UAC actually is superior to most implementations of sudo on Linux because the display-darkening prompt is much harder to spoof and doesn't reveal a superuser password even if it is spoofed.)
I don't know or particularly care how yahoo did things. From your brief description, it sounds like they did things fairly moronically. Both clientside and serverside hashing have a function: client-side reduces the attack surface to the least possible extent for discovering the plaintext passphrase, whilst proper server-side hashing can prevent a read-only database breach from being used to break into an account.
Client-side is the most easily auditable version and as I said, offers the maximum protection against the actual password being found out. If the hashing is handled by a website script, then only a compromise of that website could reveal the pre-hashed password. If the hashing could be handled by the browser itself prior to passing to the website, then only a compromise of the browser itself would reveal the pre-hashed password. Concealing the pre-hashed password is important because it encourages and allows people to take the time to memorize a really strong one and re-use it, which is something that currently isn't viable due to the fact that many big name places store passwords in plaintext.
Serverside hashing has its uses as well. If handled correctly, then it can prevent an attacker with simple database read access (but no write access) from being able to access arbitrary accounts. The server should hash all incoming passwords (which have already been hashed with salt on clientside) with different salt. This salt can be known or not; it doesn't really matter. The passphrase stored in the database will be the doubly salted-hashed password (once on client, once on server.) So, let's say the entire contents of the database is read by an attacker. That means they can access any account they want, right?
Wrong. Read-only access buys the attacker NOTHING, assuming it is a strong password. (I do not care about protecting weak passwords that can be cracked with brute force here.) He needs the pre-hash value in order to log into an arbitrary account. If he tries to use the server-hashed version of the password (which is the only one permanently stored on disk), it will be hashed AGAIN by the server before it is compared to the one in the database, and thus will not match. So, the attacker has to do more than just access the database; he has to either be able to write to it (to overwrite the server-hashed value with something of his own choosing, which should have the undesirable side effect of spoiling database integrity checks and locking the rightful owner out of his/her own account, thus raising the alarm) or he needs to be able to intercept the pre-server hashed password in memory, since the pre-server hashed password should never be written to disk.
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.
reply to your other post*. Sorry, 'email' on the brain. Nothing of vital importance was lost with either the eBay account or email address, mind, but there were thousands of nostalgic emails in there that I'll never see again, some of them from people I'll never see again.
It's annoying.
Yes, I've since clarified ad nauseum that the password was a strong one. Protecting bad passwords is intrinsically impossible. You can use a keyfile but that's basically akin to having a strong password and then writing it down in notepad.
See my reply to your other email for my response on the "this wouldn't add to security." I think the big takeaway is it's visible and auditable and it would thus in principle be possible (with enough of an outcry) to force an industry standard to be adopted and aggressively shame and warn against sites that refuse to adopt it. "But we do it all perfect on our server!" just doesn't cut it, sorry. I. don't. believe. you.
You're also wrong to imply there's no theoretical advantage whatsoever to a client side hash. HTTPS is very important but successful attacks aren't unheardof. Client hashing would prevent collateral damage in such cases (assuming the client hash scripting runs and transmits correctly--I'm not talking about successful whole-website spoofing that uses a different script entirely.)
Furthermore, putting this on the client reduces the attack surface of the server, since only a website spoof would suffice (if you could only gain access to the back end, you would have no way of forcing it to start recording plaintext passwords if hashing were being done on the client.) I do support the idea of a second hash prior to database storage, but it doesn't and cannot replace the client hash stage.