We hash the password using pbkdf2. The actual code looks like this:

crypto.pbkdf2(text, salt, ITERATIONS, BYTES, function...

ITERATIONS is 1000, and BYTES is 32.

Our code is descended from the code on this page: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mob...

That's great; it's the answer I quietly predicted I'd get. If you're communicating to laypeople, you can say something like "we use a modern secure password hash".

Note, if your crypto.pbkdf2() is using SHA1 underneath, then 1,000 interations of SHA1 is very little computation for a GPU, which can do billions of SHA1 per second.

Also, asking for 32 bytes from PBKDF2-HMAC-SHA1 has some bad side-effects, particularly if you are splitting up the result. (1Password got bitten by this, and wrote up the issue here: http://blog.agilebits.com/wp-content/uploads/2013/07/playing...)

If by "bitten by this" you mean "had their security reduced by 1 bit", then sure.

I remember it feeling like a bigger deal reading about it at the time, but as you say, you're just throwing away half of the stretching, reducing attack cost by half.

That's a fair complaint. The PBKDF2 answer is quite satisfactory (though I think that these days 10k iterations is warranted).

What I'm much more concerned about though is the server-side encryption of the notes[1]. Having the notes encrypted with a key that's kept on the same server, however frequently changes, adds barely any security. It gives the illusion of security: they can now truthfully say "your notes are encrypted on the server, yay!" But that's disingenuous, because the keys are stored on the same server.

A much better system would be to encrypt the notes on the device, using a key derived from the password. That way, the server can never see the plaintext of the notes, except for during login and when the password is being changed[2].

[1]: http://inessential.com/2014/04/17/vesper_sync_diary_14_keys

[2]: This is actually pretty easy to get around, by not sending the plaintext password to the server for login, but rather a different password-derived key. But if it were built that way it'd make it a little harder to update all the notes when changing passwords. But again, you could fix that by simply storing an encrypted version of a randomly generated encryption key on the service, and simply re-generating that when the password is changed, without having to chain the note ciphertexts. Kind of like how OS X full disk encryption works.

I actually touched on this by mentioning it to Brent via twitter the other day: https://twitter.com/kob/status/471152663384440832

If they don't feel like they know exactly what they're doing with cryptography, I'm glad they opted to be candid about their limitations rather than bragging about their military-grade encryption.

> There's no OS X app for this yet, is there? I'd use it for personal stuff if there was.

I haven't fully committed to Vesper b/c it lacks a desktop client. I'm glad it is on the horizon. Now I'm hoping this client will somewhat resemble NVAlt (Notational Velocity).

If it's not too big a topic, could you expand on the appropriate cryptography for this use case? How 'bout without a central server? (Not interested in web clients.)

No OS X version yet, but it's what they're working on next according to the last part of http://vesperapp.co/blog/vesper-2-0-and-vesper-sync/

It's incorrect that salted hashes are obsolete or quickly attackable per se. Password hashes are a subset of all hashes. Therefore they are hashes. bcrypt uses an internal salt (as it says in the first two sentences of its Wikipedia page).

Salted hashes have been irrelevant for at least 5 years, possibly more. It was a big deal in 1995-2004, back when "Rainbow Tables" were a thing. It just doesn't matter any more, and hasn't for a long time.

Don't be misled by the fact that bcrypt/pbkdf2/scrypt both use hashes, and have salts on the front - that's just a property of them, not their primary essence.

I think the right thing to say is that password hashes are all randomized, just like a salted hash --- but that when you say "salted hash", you are evoking SHAx(password, salt).

So what is their primary essence?

Selectable time and memory difficulty of calculation.