Hacker News Reader

Comment by paul-sh | Hacker News Reader

Ikkez, you use hash == HMAC-SHA256(CT, SHA256(password)) to check if the password is valid. You should replace the "SHA256(password)" part here with a strong password-based key derivation function (PBKDF2, scrypt, bcrypt) with a decent number of iterations.

SHA256 is blazing fast. While this is a good thing for a hash function in general, it is not for a key derivation. PBKDF2, scrypt, bcrypt and others are slow by design to make an attack much harder.

View on HN

I think it does not matter that much here, as this hash is just used for checking the message integrity. This hash is build from the encrypted doc + the hashed password. if you are about to brute force the HMAC function, you would just get a SHA hash back. It would make more sense to try to break the message directly. I got this trick from http://stackoverflow.com/a/23190781/2038179

I think you use this to validate the password, not to check the integrity of the message. And an attacker gets a password as a result of brute-forcing, not a hash. Look at this snippet in pseudocode:

    // Get the hash and the encrypted text from the encrypted data
    hash = substing(encryptedData, 0, 64);
    encryptedText = substing(encryptedData, 64);

    foreach password in PasswordDictionary {
      if hash == HMAC(encryptedText, SHA256(password)) {
        print "Password found: " + password;
        // Decrypt the message 
        print "Message: " + AESDecrypt(encryptedText, password);
      }
    }

The loop will run fast, and you get a clear-text password as a result, which can decrypt the message. If you replace SHA256(password) with PBKDF2(password, 20000) the loop becomes insanely slower.

that assumes an async pbkdf2 implementation for the browser... most browser implementations for crypto I've seen are synchronous, though I'm uncertain today, I haven't checked for a couple years now. In the case of synchronous, most browser based variants will kill the script before it completes... you could use workers, but that won't work for ie<=9 [1]. Which may or may not be an option here. As it stands, it would be a nice options.

I really like the markdown editor implementation, will look at how they are using medium-editor... I'm working on a similar implementation and was considering going side-by-side, but this actually looks/works better. I did write a sanitization utility[2] for such inputs, but hadn't yet completed the editor.

[1] http://caniuse.com/#feat=webworkers [2] https://www.npmjs.com/package/cc-text-utils

You can also use Blake2 which is 3-5x faster than SHA256. Other projects like miniLock/Peerio also use it.

https://blake2.net/

Are they comparing MACs with a strategy that fails as soon as a byte differs? Hah.

http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote...

The site compares MACs in the client's browser, so a timing attack is not really an issue here.

It's indicative of bad engineering.

Reply on news.ycombinator.com