On cryptography and dogmas

This is moronic. Cryptography is very hard and one tiny mistake can ruin everything. In that kind of situation, do you want to do something clever and new that you just thought up or do you want to go with what's been tried and tested by many?<p>Anyone can invent a cryptosystem that they themselves can't break. That's why you need a community, over a long period of time, searching for flaws. Going with the herd is exactly the right thing to do here.

"It is very important to force users to add non alphanumerical characters and a few capital letters in the password IF security is very important for your application. "<p>Not it's not. What's important is that users pick a password randomly from a large pool. For example, there's nothing wrong with a long password all in lowercase if the characters are picked randomly (see, for example, how Google 2-factor authentication handles application specific passwords).<p>"But guess what? This morning I discovered that actually the algorithm PBKDF1 described into RFC2898 does exactly what I proposed."<p>Actually PBKDF1 has been deprecated since 2000 and replaced by PBKDF2 which doesn't use SHA1 (it uses HMAC-SHA1 instead). And PBKDF1 is a key derivation function, it's not designed to be slow (as is, for example, bcrypt).<p>Nevertheless, you could iterate SHA1 if you wish.

I think it's important to not confuse "dogma" with "development best practices," a lack of which is one of the problems that is hurting software development. People go off and do their own versions of password hashing because they don't know what's the best practice or think they'r e being safe.<p>Is it important that you know <i>why</i> brcypyt is a best practice? Yes. I understand that it (tunably) is slow and uses a random salt, which I also know is a best practice for hashing passwords. Is doing repetitive sha1s going to work well enough? Probably, but I don't know enough about cryptography to know fo sure. So when smart people say, "use bcrypt," I do just that.<p>Programming is too big of a topic for everyone to understand everything about what they're using. We have to trust others.

This comment from Coda Hale is worth a look: <a href="https://github.com/antirez/lamernews/pull/8#issuecomment-2481391" rel="nofollow">https://github.com/antirez/lamernews/pull/8#issuecomment-248...</a>

Be careful. Tptacek may show up soon to explain in more detail why this is a dangerous direction to go, but the fact that PBKDF2 is a reasonably well-studied key stretching algorithm is the only reason I'd be comfortable iterating SHA1.<p>To put it simply, there's just so many incredibly subtle ways to introduce weaknesses into crypto that even if you really do understand everything that's going on, you'll still break things by building it yourself.

When I saw SHA1(password|salt) in the readme of <a href="https://github.com/antirez/lamernews" rel="nofollow">https://github.com/antirez/lamernews</a> I knew a flame was coming, and that "use bcrypt" and "cryptography is hard" will popup, but not really exactly why?<p>Thanks for this post antirez, because after diving a little, now I know better the reason, the risks, that tarsnap creator uses scrypt (<a href="http://www.tarsnap.com/scrypt.html" rel="nofollow">http://www.tarsnap.com/scrypt.html</a>), that really "cryptography is hard", he also makes bugs (<a href="http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html" rel="nofollow">http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...</a>)<p>And this funny little gem: <a href="http://xkcd.com/538/" rel="nofollow">http://xkcd.com/538/</a>

It seems it started a flamewar about sha1 and bcrypt.<p>First: scrypt (<a href="http://www.tarsnap.com/scrypt/" rel="nofollow">http://www.tarsnap.com/scrypt/</a>) is far better than bcrypt.<p>Second here is the general idea behind the scrypt algorithm (from the scrypt slides):<p>Algorithm ROMix:<p><pre><code> Given a hash function H, an input B (the user password), and an integer parameter N (computational hardness), compute:</code></pre>  V_i =H^i(B) (0 &#60;= i &#60; N) and X = H^N(B), then iterate<p><pre><code> j ← Integerify(X ) mod N X ← H (X ⊕ Vj ) N times; and output X. </code></pre> The function Integerify can be any bijection from {0, 1}^k to {0...2^k −1}.<p>Theorem:<p>Under the random oracle model, the class of functions ROMix are sequential memory-hard.<p>More intuitively,<p><pre><code> V_0 = H(B) V_1 = H(H(B)) ... X = V_N = H(H( ... H(B) ...) ) </code></pre> V_i are filled with pseudo random values.<p>Then the algorithm access them in pseudo random order.<p>Which means that is is not only very long to compute but also need a lot of memory.<p>Now zealot should say _use scrypt_! not bcrypt. And also, even if cryptography is difficult, the idea behind is not so difficult.

I couldn't be bothered to read the article entirely, but what he proposes at the end (iterating SHA) is likely broken:<p><a href="https://groups.google.com/group/sci.crypt/msg/92fe3e4e1edf0d0f?hl=nl" rel="nofollow">https://groups.google.com/group/sci.crypt/msg/92fe3e4e1edf0d...</a>

You need to salt each round of SHA-1 otherwise you don't add much security.<p>You may also want to use SHA-256 instead of SHA-1 and that doesn't add any new dependency AFAIK. Ideally you should use SHA-3 as soon as it's available. SHA-1 is becoming weaker each day...<p>You may want to offer the possibility to easily replace the password hash algorithm via a snapin (so people who like bcrypt can use it).

<i>"It is very important to force users to add non alphanumerical characters and a few capital letters in the password IF security is very important for your application."</i><p>This is a mistake. Virtually all users respond to these requirements using one of a small number of tactics. The requirements add little to no entropy, which makes them very dangerous, because that leads to the mistaken belief that "all our passwords are strong".<p>The only secure password is a randomly generated one. You can use words/phrases a la diceware or xkcd if it's easier to remember.

In case you haven't seen the long thread of comments on the pull request that lead to this blog post: <a href="https://github.com/antirez/lamernews/pull/8" rel="nofollow">https://github.com/antirez/lamernews/pull/8</a>

Regardless of who is right or wrong on this issue, I have to say I'm pretty impressed with antirez for keeping his cool and being up for genuine dialogue in the face of some pretty brutal and abusive comments from Coda Hale and others.

I am the creator of YPassword, and each time I asked if my algorithm was secure I stumbled upon a lot of people not understanding anything about cryptography that claimed to me:<p>"Hey! sha1 is sooo absolutely insecure! Use bcrypt!" :-/<p>"Hey! bcrypt is sooo incredibly insecure! Use scrypt!" (only implemented in C).<p>You know what? I finished to read the scrypt paper. In fact _theoretically_ scrypt is far more secure than bcrypt, himself (AFAIK) better than PBKDF1. And the general algorithm behind scrypt is _simple_. Not as simple as sha1^n but almost as simple.<p>I tried to answer my theoretical question two times now. Each time I never meet any real security expert, only a bunch of zealot. And I know they are all zealot because I discussed with a lot of security expert (searchers) during my Ph. D. And I know far more about security than people reading my question might think. Even if it feels like, my question is _not_ a newbie question. But I am not an expert either.<p>I try my chance with you dear HNers. Here is the question:<p>Let<p><pre><code> sha1(salt|pass)=S </code></pre> Knowing "salt" and "S", is there a known attack better than brute force to discover "pass" or sha1(salt2|pass) where salt2 is known and dependent only of salt (for example salt2 = salt + 1)?

Can someone explain to me how salts help a hashing algorithm secure itself against a rainbow table? For example, let's say my password is "justinbieber", which then has a salt prefixed to it which turns it into "iheartjustinbieber". If an attacker is unfortunately able to gain access to the hash of my password and the rainbow table he uses has an entry for hash("iheartjustinbieber"), how is that any more secure than the original?<p>Edit: changed "iheartjustinbieber" to hash("iheartjustinbieber") in the last sentence.

Obligatory: <a href="http://xkcd.com/936/" rel="nofollow">http://xkcd.com/936/</a>

Twitter: the worlds premier platform for sanctimonious whining from people who don't know you.