7 ms·

Input type="password" Needs to Grow Up

80 points by ergo98 16y ago

mattberg 16y ago
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.
- pygy_ 16y ago
  This scheme has another fatal flaw: What happens when a site moves to another domain? All accounts will go poof...
  - Groxx 16y ago
    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.
tptacek 16y ago
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.
- deleted 16y ago
  [deleted]
  - tptacek 16y ago
    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.
    - deleted 16y ago
      [deleted]
      - tptacek 16y ago
        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.
        deleted 16y ago
        [deleted]
        tptacek 16y ago
        "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".
ComputerGuru 16y ago
Really pointless. I posted this to the site: The password is automatically salted with the domain and username ...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 you 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.
- user24 16y ago
 > 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.
 - tptacek 16y ago
 You already can't use "rainbow tables" on Gawker password hashes.
 - 16y ago
wccrawford 16y ago
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.
hackermom 16y ago
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.
- joh6nn 16y ago
  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?
pixelcort 16y ago
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.
- andfarm 16y ago
  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).
drdaeman 16y ago
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.
IgorPartola 16y ago
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.
jasonkester 16y ago
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.
tptacek 16y ago
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.
- ergo98 16y ago
  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.
  - tptacek 16y ago
    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.
bhickey 16y ago
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/pwdhash.html http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr.html http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr....
Locke1689 16y ago
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.
- goran 16y ago
  "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.
  - Locke1689 16y ago
    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 http://en.wikipedia.org/wiki/Key_strengthening [2] http://www.rsa.com/rsalabs/node.asp?id=2127 http://www.rsa.com/rsalabs/node.asp?id=2127 [3] http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html [4] http://srp.stanford.edu/ http://srp.stanford.edu/
pornel 16y ago
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.

80 points by ergo98 16y ago

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.

pygy_ 16y ago
This scheme has another fatal flaw: What happens when a site moves to another domain? All accounts will go poof...
- Groxx 16y ago
  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.

tptacek 16y ago

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.

deleted 16y ago
[deleted]
- tptacek 16y ago
  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.
  - deleted 16y ago
    [deleted]
    - tptacek 16y ago
      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.
      - deleted 16y ago
        [deleted]
        tptacek 16y ago
        "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".

ComputerGuru 16y ago

Really pointless. I posted this to the site: The password is automatically salted with the domain and username ...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 you 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.

user24 16y ago
> 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.
- tptacek 16y ago
  You already can't use "rainbow tables" on Gawker password hashes.
- 16y ago

wccrawford 16y ago

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.

hackermom 16y ago

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.

joh6nn 16y ago
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?

pixelcort 16y ago

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.

andfarm 16y ago
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).

drdaeman 16y ago

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.

IgorPartola 16y ago

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.

jasonkester 16y ago

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.

tptacek 16y ago

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.

ergo98 16y ago
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.
- tptacek 16y ago
  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.

bhickey 16y ago

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/pwdhash.html http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr.html http://crypto.stanford.edu/~dabo/pubs/abstracts/passwordmgr....

Locke1689 16y ago

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.

goran 16y ago
"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.
- Locke1689 16y ago
  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 http://en.wikipedia.org/wiki/Key_strengthening [2] http://www.rsa.com/rsalabs/node.asp?id=2127 http://www.rsa.com/rsalabs/node.asp?id=2127 [3] http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html [4] http://srp.stanford.edu/ http://srp.stanford.edu/

pornel 16y ago

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.