Input type="password" Needs to Grow Up(blog.yafla.com)
blog.yafla.com
Input type="password" Needs to Grow Up
http://blog.yafla.com/input_typepassword_Needs_To_Grow_Up/
72 comments
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."
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.
Then a password UI that can't be forged could be used, but I agree if you're going to do it, do it right.
Have you considered how hard it would be to create a password FORM input that couldn't be forged?
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?
Yes: trivial. Have the user type in an area outside the page.
[deleted]
[deleted](1)
[deleted](1)
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.
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.
It's a counterproductive discussion.
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.
It's a counterproductive discussion.
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.
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.
Google Groups link to the usenet discussion in question, in case anyone is interested:
http://groups.google.com/group/comp.security.unix/browse_thr...
http://groups.google.com/group/comp.security.unix/browse_thr...
Ahhhhh, Nick McClaren. Those were the days.
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.
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.
I'm not sure that following djb in all things is the greatest idea ever, though.
It tends to help in matters of systems programming and security.
>"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.)
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.
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.
> " "Argument" to you is disagreement with Thomas Ptacek, who time and time again bizarrely gets upvoted without merit or regard for accuracy."
Found in the code of most HNers brains:
Found in the code of most HNers brains:
if (poster=="tptacek" && subject=="security") upvote();
That definitely does happen. I also get an automatic 30%>N>5% boost for name recognition; you get one too.
It helps to be right, though.
It helps to be right, though.
Just decided to calculate it...
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).
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).
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).
Really pointless. I posted this to the site:
<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.
<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.
> or, more realistically, rainbow-table matching
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.
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.
You already can't use "rainbow tables" on Gawker password hashes.
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."
[1]: http://webcache.googleusercontent.com/search?q=cache:ICSor0l...
edit: better yet: http://project-rainbowcrack.com/
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."
[1]: http://webcache.googleusercontent.com/search?q=cache:ICSor0l...
edit: better yet: http://project-rainbowcrack.com/
ntlm_ascii-32-95#1-8 rainbow table
Plaintext charset: space and !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
Plaintext length: 1 to 8
Success rate: 96.8%
Table size: 576 GB
ntlm_loweralpha-numeric#1-10 rainbow table
Plaintext charset: abcdefghijklmnopqrstuvwxyz0123456789
Plaintext length: 1 to 10
Success rate: 96.8%
Table size 396 GB
[deleted](2)
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.
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 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.
There's already solution to phishing, remembering passwords and whatever else. Only three words: client X.509 certificates.
Well, if Google'll fix Chromium to play nice with them.
Well, if Google'll fix Chromium to play nice with them.
Stanford's Dan Boneh has written about this quite a bit:
http://crypto.stanford.edu/~dabo/pubs/abstracts/pwdhash.html
http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr....
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.
This scheme has another fatal flaw: What happens when a site moves to another domain?
All accounts will go poof...
All accounts will go poof...
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.
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?
[1] http://en.wikipedia.org/wiki/Key_strengthening
[2] http://www.rsa.com/rsalabs/node.asp?id=2127
[3] http://www.tarsnap.com/scrypt.html
[4] http://srp.stanford.edu/
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?
[1] http://en.wikipedia.org/wiki/Key_strengthening
[2] http://www.rsa.com/rsalabs/node.asp?id=2127
[3] http://www.tarsnap.com/scrypt.html
[4] http://srp.stanford.edu/
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.
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.
First sentence of "What is SRP?":
SRP is a secure password-based authentication and key-exchange protocol.
SRP is a secure password-based authentication and key-exchange protocol.
"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).
It does not solve phishing at all. Phishers simply won't add secure flag to the input, and will get raw password needed to create hash for every site.
Even if all password inputs were always hashed, phishers could write their own plaintext-stealing imitations in JavaScript.
Even if all password inputs were always hashed, phishers could write their own plaintext-stealing imitations in JavaScript.
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?
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.