Don't use bcrypt • Hacker News Board

Re: Don't use bcrypt

#191

Post by specialist » Tue, Mar 20, 2012, 4:31 PM UTC

im_dario wrote: post #182

specialist wrote: post #99

Earlier quoted context omitted.

Cryptography is exactingly and excruciatingly hard to do at industrial strength. Related: Which is why I'm against any and all forms of electronic voting. I've done a fair share of crypto (as a user of crypto libraries) and I barely understand how it works. There's ZERO hope for the layperson to understand crypto-based voting systems. One of the central tenets of American style voting is a public vote count. Using cr…

There are crypto-based voting systems that are very simple to understand, although not being entirely electronic: http://www.wombat-voting.com/ By all means, there are different shades of grey. It should not be all black or white.

Crypto-based voting systems are not designed to work for real-world elections. They work fine for contrived academic studies.

They all rely on one's vote being lost within a herd of votes. So if your ballot is one of a million, and the ballots are simple with a few races/issues, it's easy to have a secure one-way hash with collisions. (The collisions make it impossible to work backwards to infer how each person voted.)

Alas, real-world elections in the USA are administered at the precinct level. In my state, that's between 0 and 1000 registered voters.

Further, a general election (November) ballot will have dozens of issues and races.

So it's more than likely that any single ballot will be utterly unique. So with the voting systems I studied, it's trivial to infer how everyone voted.

I could imagine crypto-based voting systems working for certain applications. Like corporate shareholder meetings. Or maybe Australian and British style parliamentary elections. (Don't hold me to the last guess, I only have cursory knowledge of their election systems.)

Edit: I discussed these practical issues with one of the grad student authors of a crypto-based voting system. Being completely ignorant of real elections, he had NO IDEA what I was talking about. He denigrated my input; saying our elections should be easily tailored to accommodate crypto. (Good luck with that.)

Maybe it's just me, but I'm of the opinion that people setting out to solve a problem should probably make some token effort to first understand the problem. YMMV.

Re: Don't use bcrypt

#192

Post by Xylakant » Tue, Mar 20, 2012, 4:39 PM UTC

marshray wrote: post #188

Xylakant wrote: post #185

Earlier quoted context omitted.

> OK, but what if you're a web app that specializes in authentication (like, say, an Oath provider) Then I'd hope that you make extra double sure that your user's passwords are secure. Let's call it the cost of business. > or a database server where the attacker-facing app doesn't use connection pooling? We're talking how to store user-passwords here, don't we? If your database server passwords get lost or cracked, c…

The discussion is about best practices and the relative merits of password hashing functions. So the baseline assumption is that the server-side password database isn't perfectly secure. In practice, the user gets to choose the password and the website at best gets to veto it or accept it without knowing how many other places it's re-used. There aren't too many sites assigning randomly generated passwords right now,…

> The discussion is about best practices and the relative merits of password hashing functions. So the baseline assumption is that the server-side password database isn't perfectly secure.

That's right. So I don't see where database connection pooling is part of the issue and that's what my remark about random generated passwords was pointed at. You should use secure passwords to authenticate your app at the database. You should probably use md5 [1] or similar as password hashing scheme for the database credentials since this is where you really have a valid tradeoff between performance and security that allows any attacker to bog down your database. But this issue is not the scope of this discussion.

It's certainly a valid technical concern to not increase your password hashing work factor to a point where this it is a valid attack vector for DoS attacks, my point simply is that you can go quite far in terms of work factor until you reach that limit. Increasing the work-factor to a point where authentication takes 10ms will in many cases still leave other parts of your application more vulnerable.

And well, turning off authentication should imply denying access to data that requires authentication. This certainly is an option if the majority of your data is available for unauthenticated users. It certainly is not if you only store data worth securing.

[1] as postgres and mysql both do

Re: Don't use bcrypt

#193

Post by SkyMarshal » Thu, Mar 22, 2012, 3:53 AM UTC

_delirium wrote: post #42

SkyMarshal wrote: post #17

TLDR: Use PBKDF2 or scrypt instead. PBKDF2 has had longer public exposure, and also features an adjustable CPU work factor (though with a lower theoretical safety-to-compute-time than bcrypt). scrypt is newer, but features both a CPU and memory work factor (memory-hard algorithm), and is algorithmically superior to both.

> PBKDF2 has had longer public exposure I don't know whether or not it's had more public exposure, but I don't think it's had longer public exposure. Afaik, bcrypt's canonical reference document is the June 1999 Usenix paper ( http://static.usenix.org/event/usenix99/provos/provos_html/i... ), while PBKDF2's is the September 2000 RFC ( http://www.ietf.org/rfc/rfc2898.txt ).

Thanks for the reference, didn't realize that, though I think that's what the article was implying.