Input type="password" Needs to Grow Up
blog.yafla.com
blog.yafla.com
* 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.
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."
On the off chance that anyone thought this was a graceful way to end a pointless argument: no. It's cowardly and rude.
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.
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.
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.)
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.
http://groups.google.com/group/comp.security.unix/browse_thr...
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.
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).
Found in the code of most HNers brains:
if (poster=="tptacek" && subject=="security") upvote();
It helps to be right, though.
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).
<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.
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
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.
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.
Well, if Google'll fix Chromium to play nice with them.
All accounts will go poof...
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.
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
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.
SRP is a secure password-based authentication and key-exchange protocol.
Even if all password inputs were always hashed, phishers could write their own plaintext-stealing imitations in JavaScript.
if there's something that i'm missing here, can you please elaborate on it?