There's so little payoff to this scheme that we can safely assume it will never happen, as opposed to bickering about its merits. Here's a couple issues:
* The hashes are themselves password-equivalent, so we've changed browsers and introduced a random crypto dep to arrive at a solution that doesn't improve the security of the app itself (anyone who can see the hash can log in).
* A Gawker-style breakin under this scheme is exactly as bad --- perhaps even worse † --- as it was before, because these hashes are also trivial to crack with an iterative password cracker (of the kind that have been the industry standard since 1990).
* It's now that much trickier to implement a real password storage scheme like scrypt.
There is already a cryptographically sound proposal to improve password-based authentication on the web: SRP. I believe it's RFC 5054. SRP systems don't store trivially cracked passwords on the server and never pass the password in the clear. I don't anticipate widespread adoption anytime soon, but that's the horse to bet on if you have to bet.
† I'm not totally sure whether DES crypt(3) is faster or slower than SHA1(salt, password), but if I had to guess, I'd guess SHA1 is faster --- speed being one of its primary design goals. Speed kills in password hashes.
The author suggests that this solves the phishing problem. Is that true, and if so, is that worthwhile?
UPDATE: I wonder if the author is wrong about this. If we start with the presumption that a user is susceptible to phishing, what can be done to prevent them from entering their password into a text field that uses JS to change their characters to little black circles? Now you'd have to create some sort of browser feature like a "key" icon that appears somewhere outside of the page when you are in a "hashed" password box, and you'd have to teach users not to put passwords in a field that doesn't display the key. If you can teach them all that, you can teach them not to be phished.
And oh yes, while you're trying to teach them that, Facebook is busy teaching them to enter their passwords into a plain text box so they can "find their friends."
In a perfect world, it would lessen the impact of phishing by disclosing only a crackable password hash to a phisher. In the real world, phishers will just construct phishing sites that appear to use the "secure" password type but actually don't.
How about this: if focus is in a password field, then you get a visual signal somewhere in the chrome--e.g., the color of the location bar changes. Something that HTML+JS just can't do.
We can't train users to look for a lock icon to see if they're SSL encrypted, so I'm not optimistic that something as subtle as a URL bar change is going to guide them to secure password inputs.
Consider this, then: a secure password box is put at the very very bottom of the page in an obscure location. JS is used to make a fake one that is prominent. How will you deal with that?
Our failure to connect on this point seems to be getting militant.
I'm not suggesting that nothing should be done to solve the plaintext password problem.
I'm suggesting that your proposed solution does very little to address the incident that motivated you to post it (the Gawker compromise).
Instead of advocating for your solution, I'm encouraging you to advocate for a much, much better solution. The only downside I can see to my suggestion over your suggestion, apart from the fact that it requires approximately 50 lines more code, is that you didn't come up with it.
Are we looking at different RFC 5054's? I got mine off Trevor Perrin's site, and it specifies SRP, not SHA1. My point is SRP; it's not the specific RFC number.
I think you're missing my point. I'm saying: if you're going to introduce a traumatic change to HTTP/HTML, you'd expect to use a real password authentication scheme, not a half-measure.
I think you're wrong about the extent of the Gawker password breach, but I haven't been following that closely. If they lose a database with hundreds of thousands of DES crypt(3) passwords, it's safe to assume that many many tens of thousands of passwords were compromised; this is the real problem with the Gawker incident (as it's being reported).
My point regarding that incident is, the incident would be exactly as bad under this proposal.
You propose a change that requires every browser to cut a new release, requires the publication of a new standard definining a new input type, and requires browser vendors to agree on a new crypto protocol to run with servers. All involved parties will have to figure out the backwards-compat bits of this. Then everybody who builds webapps will need to be educated about it.
That's expensive. It's very, very expensive. So if you're going to advocate for something like it, advocate for SRP, a well-studied, cryptographically sound construction designed for exactly this problem statement.
"This is a plaintext-equivalent authentication system that is literally faster to crack than the password hashes Gawker already gave up" is not the same thing as "Get off my lawn".
If you had used the word "debatable" I'd have agreed with you, but you said "ludicrous", which tells me you don't understand how password cracking works.
You might not have been aware of this, but DES crypt(3) is not that much different from SHA1(salt, hash). It takes a salt parameter that is adequate to the task of stopping "rainbow table"-style procomputation. It uses your password as the key to the DES cipher, meaning that every password hash is key-scheduled differently --- one of the reasons why continuously re-hashing DES passwords might be slower than SHA1. It is by no means a strong password hash function, but it avoids some (not all) of the most amateurish design mistakes people make with these functions.
I'm a browser implementor and I agree, this proposal doesn't have enough value to be worth doing. Inventing a password field UI that is unforgeable is hard, users will stay used to normal password fields, and it is easy to forge a regular password field using JS. Therefore this proposal won't help with phishing, and that seems to be the only area where it has a hope of helping.
> with some sort of visual, non-spoofable indication by the browser, such as the titlebar blinking green or some such thing
Then I'd put some secure password box 500 pixels above the top of the page to make the titlebar blink green, and then make the input box the user is typing in be a normal one.
Instead make the text box blink green and I'd fake that with javascript. In fact, anything that shows up on the page and you can fake it with images and javascript. Or flash. Or a canvas tag.
Sure, the people who really know what they're doing could view the page source or confirm through other methods that this is the real password box -- but those guys are already using passwords better than "password123". I'm not saying it's impossible, but you have to realize how difficult it is to get the average user to recognize 'this is a real secure password box' versus 'this is a fake one that looks real.'
The stakes for "hard-to-phish login UX" are immensely high: banks are spending tens of millions trying to roll out advanced authentication. It's not like nobody ever thought of "unspoofable login page" before; it's that "unspoofable login page" is the problem statement, not the solution.
Arguing with everyone who disagrees with you, questioning their motives, and then deleting all your comments is troll behavior. I actually took the time to write the little C crypt(3) loop to make sure I wasn't crazy before making my points; the person who instigated this thread couldn't even bear to stand behind his own words.
On the off chance that anyone thought this was a graceful way to end a pointless argument: no. It's cowardly and rude.
How utterly boorish. If I could delete the submission I would because I see zero productive value in it, and I'm a bit shocked at the stunning narrow mindedness of so many.
My motive was simply to have a discussion about web security as it's a recurring topic and element fraught with peril on a rapidly changing web platform.
It's telling enough that you keep pounding on the SHA1 thing (despite the fact that I repeated, time and time again, that the computational complexity of the algorithm is of course open because the implementation doesn't exist. 128 rounds of blowfish if you prefer), that you keep misrepresenting the Gawker attack, that you pretend that it's a proposal to replace SSL (no), and so on. "Argument" to you is disagreement with Thomas Ptacek, who time and time again bizarrely gets upvoted without merit or regard for accuracy.
128 rounds of Blowfish would still be a password-equivalent hash. You should read up on SRP. Smart people who have spent much more time thinking about this problem than we did have been studying it for over a decade. It's very elegant, it addresses exactly the problem you're talking about, and it's a standards-track technology.
It's true, by the way. "Argument" to me is "disagreement with Thomas Ptacek". It would be pretty weird if argument meant something else to me.
A long time ago, I was on a comp.security.unix thread when Daniel J. Bernstein said something that has been stuck in my head ever since. Responding to "You appear to be absolutely incapable of realising that there are people in this world who can see more than one side to a question...", he wrote:
On the contrary. I see both sides, and I have evaluated both sides, and I have found that one side is vastly superior to the other. This may seem ruthless, but that's how engineering works.
Incidentally, that's a thread that includes Tim Newsham, Wietse Venema, Daniel Bernstein, and Theo de Raadt. Read it! I do not acquit myself well on it. I miss Usenet, but I have gotten much less obnoxious in the intervening decade.
>"You appear to be absolutely incapable of realising that there are people in this world who can see more than one side to a question...",
Cf. my PayPal discussion. I was fully aware before he decided to come barging in what kind of pressure and legal strictures payment companies and banks must endure in order to do business. I am even a libertarian.
That doesn't mean PayPal's conduct is excusable or required by said law, hence my stance in that particular matter.
I can be argumentative, but he takes it to a level that leaves me with the impression that he has disregarded the tone we try to maintain here.
He's even seen fit to effectively deface the comment thread by deleting his comments without leaving behind a retraction or explanation as to why. (I have in the past deleted or edited comments according to feedback, and a left note of retraction so that people didn't get lost.)
I was fully aware before he decided to come barging in
Do you mean the thread having nothing to do with you where you responded to my post with-
"Stop pretending there isn't something horribly wrong with the company just because it suits your rhetoric."
I think your perception of reality is a little skewed, and your unmerited, hostile, trollish response has no place on HN. Also your business savvy is, well, non-existent, which was why it was time for that discussion to end. It was another thread where in the end my feelings of PayPal just improved because I saw the class of individual loudly airing their paypal gripes.
Right now, you're up 116 points from this page alone, with an average of 6.4. It also helps when you're active (which debates/battles tend to encourage).
Having made a comparable post a few days ago (which, thankfully, didn't receive as much attention), I can understand where you're coming from. Many people view this as "I'm proposing the panacea of web security" rather than "Can't we design something better? Here's my proposal".
There are many things you can do to make authentication more secure, and all of them are public. A good way is HTTP digest access authentication, but that won't work for a web app because you have to pass the state yourself, and it can be faked. Therefore, the best way I've found so far is to use SSL, although that SRP RFC might be interesting (I'm reading it right now).
<em>The password is automatically salted with the domain and username</em>
...which is exactly as secure as Gawker.com themselves doing a salt+hash.
Let's for a minute assume what you're proposing is what's being done. Gawker has been attacked. The hacker has the columns "password" and "username". Hacker knows the domain name. You're exactly where you left off!
Even if the password has been again hashed and salted on the server - that's just an extra round of cracking (or, more realistically, rainbow-table matching).
What you _should_ be doing is using a single, trusted and very much secure password provider (a la OpenID). Hacker attacks your site, gains nothing. And if you must do the authentication yourself, or the nature of your userbase prevents you from outsourcing the authentication (perhaps <em>you</em> are the OpenID provider we're talking about earlier), you need to be using something more complex than a silly MDx or even SHAx to do the hash - these are made for boiling down huge amounts of data into a small field of not more than ~256-4096 bytes - which is NOT what you want. Look at bcrypt - it's DESIGNED for this. It's a solution waiting for more and more attacks like Gawker.com so lazy and incompetent developers worldwide will use this existing, plug-and-play, simple, direct, and safe alternative to what they're currently doing.
EDIT
Regarding rainbow tables - I'm predicting that with todays resources and cloud super-computing, etc. (just look at the new EC2 GPU instances!) we're going to see a new type of rainbow tables that actually precompute the hashes for different salts as well. It's an order of magnitude larger data and more computation than last generations rainbow tables, but todays tech is more than an order of magnitude more available.
I think that's not true - you'd have to generate new rainbow tables for each user for gawker. So this method would indeed make rainbow tables impractical.
edit: but I think the rest of what you said is fine.
In addition to tptacek's comment off yours, rainbow tables aren't remotely necessary to check the most common passwords, gaining thousands of them in seconds. The salt's there. Just hash "password1" against all the salts in the database - you're nigh-guaranteed to get a bunch, associated with their username. Viola, you've likely got their email account.
Similarly, any sufficiently-complex-and-long (at best: random) password in those hashes is effectively secure. Rainbow tables typically only handle up to a dozen-ish characters long, and specific common passwords, frequently only alphanumeric values to limit the problem space. You're stuck brute-forcing each one effectively separately because you don't have enough storage on the planet to rainbow-table my 30-character random-ascii password. For instance, freerainbowtables.com recently cracked "racsivrv" and their table is 232GB. [1]
And even if you do find a match, it's simply a hash-collision. There are an infinite number of those. You might have my password, you might just have a random string that behaves like it with that salt. If it's random, you can't tell until you try it on other sites that I use the same password on. If it's a word, there's probably just the one (of reasonable length).
Rough sizes and overall idea (though I don't tend to link to codinghorror for accurate details, it's a pretty readable overview): http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracki... Very specifically from that link, "You'll also note that that passphrases, which I am a big fan of, are immune to this technique due to their length."
The reports I've seen have been that the password hashes were crypt(3) hashed; I've literally seen reports of people checking their hashes with crypt(3) to verify that they lost their real password.
That being the case, it feels reasonable to respond to your argument about "no evidence of brute-force cracked passwords" by saying that the tool that brute forces these passwords has been open sourced since NINETEEN NINETY. I was in 8th grade when the tool that breaks these passwords was published. "Love Will Never Do Without You" by Janet Jackson was a hit single.
I think --- it's hard to prove, since you'd have to get into a long involved conversation about how easy things are to parallelize in CUDA or FPGAs --- that the scheme you've provided is actually faster than that: like, De La Soul or Run-DMC easy instead of Janet easy.
>To compare this to the incredible magnitude of computation required to do that for a truly distinct per-row large entropy salt is extraordinary.
But the salt is based off a static, known set of data per user: username and domain. The salt is known, even though it isn't stored.
So run `shasum (salt + "password")`, or however they mangle it. It's precisely the same thing. There can't be a more-complex salt, because all browsers have to replicate it, or you could only use your login info from a single browser - lose that, and you lose your account.
Look, the reason I use a single password for most of the sites I visit is that I don't care if you figure out my password for those sites.
So yes, if you run a site that wants to steal my password, you can do all sorts of things pretending you're me, such as downloading copies of mysql, posting to a few random message boards, watching my Hulu favorites, etc. None of which are things I care about. That's why they all get the same user/pass. Because I don't want to spend even one second dealing with user/pass stuff for sites where security is not an issue.
Now, if you did somehow manage to get my Techcrunch password or whatever, you still wouldn't be able to log into my Gmail account, Bank, or anything I care about because I have strong passwords for those.
Notice how there is no technical solution to the above because there is no technical problem above. For 90% of the sites you need credentials for, those credentials just are not worth bothering to secure.
Right, because we've never had to upgrade our security measures, so browsers should have a set of measures built-in that can't be easily upgraded. That's a great solution.
I think it would be a LOT more useful to have a site that discusses security and the current best-practices for dealing with it. Instead of everyone taking their best guess, let most people follow along until they have an idea to make security better than standard. And if it really is better, it can be promoted to the new standard.
i assume the obvious issue with this is browser support? and what about mobile platforms? and then having everyone agree on a standard method for the salt/hash? sounds nice in theory though.
And how do you handle subdomains? Different hash, or same? They could be different sites entirely, but they're also more likely to change, so you've got the same domain-change problem.
This scheme would break down as soon as you need to use the password not only through your browser, but also through say SSH, sudo, or Thunderbird. Also, just use a random password + your built-in password manager for the browser with a master password. No yelling into the voids of the internet required.
Producing domain dependent hashes is a bad idea -- if the hash is properly created (that is, not the way described in the post, proper key-strengthening algorithms should be used) it should already be functionally one-way, meaning that passwords would be completely non-portable.
"that is, not the way described in the post, proper key-strengthening algorithms should be used"
Like what? Please correct the post, becaues it seems to be quite vague about the "key-strengthening algorithms". Secondly, non-portability of the passwords is the entire purpose.
This is my first exposure to Hacker News, after hearing nothing but good things about it, and honestly it has been a shocking disappointment.
I read the article, thought it sounded interesting if incomplete, and felt mildly enlightened.
Since then I've watched as post after post has either misreprented what it actually said, or simply posted something completely wrong. Most of the people in this discussion seemingly don't know what a hash, salt, rainbow attack or dictionary attack are.
It is very disappointing. I will continue my downward cycle of points with this post, so this shall be my swan song, but really this place is no more illuminated, or no less a circle jerk, than Reddit r/programming. Disappointing.
Secondly, non-portability of the passwords is the entire purpose.
Non-portability of the passwords outside of the site is the purpose, but what if you wish to use the same password database on either a varying subdomain or on the same network, well, that wouldn't be possible. For example, Gawker runs a number of different properties and shares passwords between them. This is impossible if passwords are domain-encoded. This also has consequences for sites like Google which also use account sharing across domains (including some of their Same-Origin Policy domains to enable cross-site interaction).
Like what? Please correct the post, becaues it seems to be quite vague about the "key-strengthening algorithms".
You may want to read the Wikipedia article[1] on key-strengthening. If you have mostly been exposed to older cryptographic techniques (e.g. salting and rainbow tables), this will tell you the basics of more advanced (and modern) password cracking. The most important thing that the article screws up is encourages non-standard cryptography usage. Cryptography is ridiculously difficult to get right even if you're an expert so cryptographic recommendations should always be based around a standard written by cryptographic professionals. The RSA standard here would be PBKDF2[2], while Hacker News' own cryptography research Colin Percival wrote a utility called scrypt[3] for the truly paranoid among us. This full category of strong password negotation and verification is embodied in the SRP[4] standard, which uses similar techniques.
Most of the people in this discussion seemingly don't know what a hash, salt, rainbow attack or dictionary attack are.
Eh, some people it seems are misinformed. tptacek, for example, knows what he's talking about. He's correct that SRP is really the relevant standard for the full authentication system here, as well.
Since then I've watched as post after post has either misreprented what it actually said, or simply posted something completely wrong.
The post also spends a tad too much time coming up with "fake" solutions -- that is, solutions which take little effort to get 90% of the way there but a huge amount of effort to take to 100%.
It is very disappointing. I will continue my downward cycle of points with this post, so this shall be my swan song, but really this place is no more illuminated, or no less a circle jerk, than Reddit r/programming.
From my latest browsing in Reddit, r/programming seems to be a congregation of unusually determined morons, but to each his or her own I guess. One of the reasons you may have been downvoted (which has gotten a little excessive here as of late, but I digress) is that your comments actually don't contain a lot of information in them. For example, one of your posts just says "you're wrong." This may just barely get by if you're an established member of the community with public credentials to back up your point but you have no history, no name, and no information. Why should we think you're anything other than an angry idiot with a keyboard?
He's correct that SRP is really the relevant standard for the full authentication system here, as well.
see, this is one of the places where I get confused. i don't read this proposal as being an authentication system. i read it as being an attempt to aid users in creating strong passwords that are not shared across sites. the proposed implementation certainly isn't perfect (i much prefer the implementation provided by https://addons.mozilla.org/en-US/firefox/addon/3282/ , but that also has problems ), but it seems to me that many of the critiques presented so far are trying to measure this proposal against the wrong metrics.
"this proposal" was meant to refer to the article, not SRP. hence my comment that we're measuring it against the wrong metrics: it's no surprise that this proposal doesn't stack up when compared to SRP, since, to my reading, it isn't meant to be compared to it.
I wonder how well client-side SSL certificates could aid in this process. This way servers would only have the public key of a user and as long as the user doesn't compromise their private key they'd be safe.
They're certainly available -- at least, in Mozilla -- but usability is poor. The most obvious issue is that there's no obvious way to copy a client-side certificate to another machine, making it incredibly awkward for users who use multiple computers (or, worse, who only have access to shared computers).
Like others here have mentioned, what the writer is missing is that when a single solution for creating these hashes are implemented, web-wide, browser-wide, the hashes themselves are equal to the passwords. On this merit alone, the proposal fails.
i'm not sure i understand why that's a failure. my understanding is that's the point: every user now has a password that is unique on a per-domain basis. i don't understand this to be an attempt to protect against the kind of attack that gave access to the gawker passwords, but rather an attempt to limit the scope of such an attack to only a single site.
if there's something that i'm missing here, can you please elaborate on it?
* The hashes are themselves password-equivalent, so we've changed browsers and introduced a random crypto dep to arrive at a solution that doesn't improve the security of the app itself (anyone who can see the hash can log in).
* A Gawker-style breakin under this scheme is exactly as bad --- perhaps even worse † --- as it was before, because these hashes are also trivial to crack with an iterative password cracker (of the kind that have been the industry standard since 1990).
* It's now that much trickier to implement a real password storage scheme like scrypt.
There is already a cryptographically sound proposal to improve password-based authentication on the web: SRP. I believe it's RFC 5054. SRP systems don't store trivially cracked passwords on the server and never pass the password in the clear. I don't anticipate widespread adoption anytime soon, but that's the horse to bet on if you have to bet.
† I'm not totally sure whether DES crypt(3) is faster or slower than SHA1(salt, password), but if I had to guess, I'd guess SHA1 is faster --- speed being one of its primary design goals. Speed kills in password hashes.