Hacker News Reader

timo_hon Cryptographic Best Practices

The same principle applies to SHA-512 just the same (much cheaper to attack non-stretched SHA-512 hash than attacking directly the bcrypt hash).

There are both MD5 hashes and SHA-512 hashes lying around, which makes "hash shucking" possible for both of them.

timo_hon Cryptographic Best Practices

> When using bcrypt, make sure to use the following algorithm to prevent the leading NULL byte problem. and the 72-character password limit:

> bcrypt(base64(sha-512(password)))

Pre-hashing the password, in this context, without a salt, is susceptible to hash shucking: https://security.stackexchange.com/questions/234794/is-bcryp...

Instead, use:

  bcrypt(base64(sha-512(password + global_salt)))

timo_hon Firefox Browser: best for a free web

Firefox is great on desktop, been my primary browser for 15+ years.

Sadly though, the mobile version (still) lacks support for "pull to refresh" gesture. Other than that, mobile FF is great (privacy features, browser addons...).

timo_hon Enough with the Salts: Updates on Secure Password Schemes

This was probably the most notorious misuse of scrypt.

Memory usage of scrypt was tuned to take 128KB, which made Litecoin mining ~10 times faster on GPUs than on CPUs.

timo_hon Authentication Cheat Sheet

Some of this is good advice, but there's a BIG point on the 'Password Storage Cheatsheet' that's linked and referenced by the above article, that I don't think is solid.

I read they recommend to use the both (adaptive hashing and "local parameterization"). As even if you utilize separate device (HSM for example) for encrypting the passwords (I'd encrypt instead HMAC), you should indeed not give up on adaptive hashing.

Here's some good commentary on this by Solar Designer (user solardiz on Reddit): http://www.reddit.com/r/netsec/comments/26d52c/yescrypt_pass...

timo_hon Breaker 101: An intensive online web security course

Before the Breaker 101 course starts, I invite you to take a quick (15 questions) quiz about web application security practices and quirks: http://timoh6.github.io/WebAppSecQuiz/index.html

timo_hon The new Secure Password Hashing API in PHP 5.5

> That's defending against a newly generated rainbow table.

You lost me here. Anyway, the attacker does not need a rainbow table at all to attack against multiple hashes at the price of one.

> That's repeating the first point with different words! It's defending against a pre-generated table. i.e. a rainbow table.

Again, no rainbow tables at all are needed to see if different entries shares a password or not.

About timing attacks, see my earlier comment in this comment chain.

> You should not rely on salts for this. In fact, if your hash is exposed you should assume your salt is also exposed.

I see and agree with your point about "relying on salts", but salts just happens to (as a side-effect probably) mitigate the attack. Remember, your salts are not exposed "as-is" if the attacker manages to fetch the password hash using timing.

timo_hon The new Secure Password Hashing API in PHP 5.5

> I don't understand how salts could help against timing attacks, though.

The salt which is unknown/unpredictable (and contains enough entropy) to the attacker makes his offline attack against the hash unfeasible (after he has managed to fetch the password hash from the server using timing leaks). I'm not sure if it is possible to fetch the (whole) hash using timing, because it is not a direct comparison. But anyway, if the attacker managed to do that, now because of "a proper salt" he would have to crack a hash that was composed of, say, 128 bits of salt and 20 bits of the actual password. It is unfeasible because of that 128 bits of salt alone.

timo_hon The new Secure Password Hashing API in PHP 5.5

At least, testing passwords against multiple hashes (at the price of one) is impossible. And it is not possible to see if different entries shares a same password (or to see if they have a different password). Also, it (probably unintentionally) mitigates timing attacks when comparing if the entered password matches.

timo_hon The new Secure Password Hashing API in PHP 5.5

> But salts don't have to be strictly unique, they only have to be a barrier to rainbow tables.

Rainbow tables are not the only "attack vector" that proper use of salts defeats.