Hacker News Reader

Comment by tptacek | Hacker News Reader

I'm reading the open source code and this thing is... odd. For instance: it has a "simple", "intermediate", and "advanced" password complexity, and depending on which you choose, it uses SHA1, SHA2-256, and SHA2-512 for the PBKDF2 hash. What does password complexity have to do with the strength of the algorithm used to generate passwords?

Also: it's 2016. Why is this using PBKDF2? If PBKDF2 is what you've got and you're protecting a website, that's fine, but this is a password manager.

Is the "commercial" version of this also Ruby code wrapping OpenSSL?

View on HN

>> What does password complexity have to do with the strength of the algorithm used to generate passwords?

It is not the algorithm only but if you can look a little bit more closely, it is iteration count too. It uses 1.000 times and 10.000 times more iterations respectively.

Plus, depending on complexity, character set range enlarges.

>> Why is this using PBKDF2?

We would like to use more industry-standart way of things rather than individual works.

>> Is the "commercial" version of this also Ruby code wrapping OpenSSL?

Commercial version is purely written C version of it and backed up with OpenSSL on some cases.

I don't think I asked the most important question clearly enough:

Why do simpler passwords get a different construction? What does password complexity have to do with KDF hardness?

It's probably because different understanding of same terms. With "complexity" word we mean hardness to generate. It doesnt adds up more algorithms but character sets and hashing algorithms for PBKDF2 respectively.

Why, exactly, would a user ever want to generate a password with a weaker KDF?

A password with lower levels of string complexity might make sense --- 1Password's strong passwords can sometimes be rejected by crappy websites. A password that sacrifices cryptographic strength in order to save a few tens of milliseconds of KDF, though, makes no sense at all.

Also: really, you should not be using PBKDF2.

I want a password manager with Argon2 configured to take 10 seconds and 1GB of RAM, playing a gratuitous 3D animation of a vault slowly opening alongside CPU and bandwidth utilization graphs.

Or if your attack model allows that reading protected files off a user's device is less likely than the cloud-synced database being compromised, you might derive the master encryption key as KDF_fast(KDF_slow(password)+password)), where KDF_slow takes 5 minutes and is stored on disk, but KDF_cheap takes 5 seconds.

Honest question: what's wrong with PBKDF2?

It's much weaker. Only reason for a password manager to use it is laziness or ignorance.

It would be better to use more hashing rounds as changing the algorithm itself doesn't require more computational effort from the attacker.

I argued with that since cryptographers first told me about it. Ludicrous concept. The goal is to eliminate brute force attacks by making the process inherently slow. That technique starts with something inherently ultra-fast that everyone is trying to speed up and hardware accelerate then iterates it a bit. Better concept to get a slow process is design an algorithm that is inherently slow and hard to speed up, esp requiring many memory accesses. My hack, aimed at defeating FPGA's, was putting a random stream into no less than 16MB of RAM (SRAM limit at time) that I iterated through randomly with a hash function. All inherently sequential, random, and large. Accelerate that!

Fortunately, Colin Percival came up with a much better solution in scrypt. It's a nice default if you want something battle-tested for a long time. Nobody should be using SHA-1, etc with solutions like scrypt available.

Just pick a real password hash and dial up the hardness as high as you reasonably can for your environment. Don't do anything more complicated than that.

That's what I do these days. Inspired by scrypt or bcrypt. Whichever I saw first. :)

Reply on news.ycombinator.com