Hacker News new | past | comments | ask | show | jobs | submit login

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/




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.


First sentence of "What is SRP?":

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: