2

I read previous posts about the topic of how to encrypt data and login with the same password/key, however the concept still seems unclear to me, especially which data it is safe to store in the database.

This great Post advised the following 2 possibilities:

1: You could derive the encryption key from the password with PBKDF2, and then use a normal cryptographic hash (e.g. SHA-256) of the key as the password hash for logging in.

2: Or, if you want to be extra careful, derive both the encryption key and the password hash from an intermediate key derived from the password using PBKDF2.

I created a diagram of my understanding for the second possibility. Do you think that I have gotten it correctly? Can you maybe think of a better way of implementing it?

N.b.

  1. I replaced PBKDF2 with scrypt here, but the concept is the same.
  2. Salts are 16 random bytes generated with urandom

enter image description here

UPDATE I discovered that the PyCryptodomex (Python) library offers a scrypt function in which I can specify how many hashes/keys I want from a single input key. For example, if I want 2 256bit long output hashes, I can specify that and scrypt will create a 2 * 256bit = 512bit key and simply divide it by 2, resulting in 2 256bit long hashes. I can then use one hash for encrypting the data and one for authentication, thus eliminating the need for the second level of scryt and SHA256 hashing in my previous concept. I created a visual description of the new concept and I'd appreciate your opinion about it :)

enter image description here

Summary Depending on the library and KDF you use, I guess that either concept 1 or concept 2 (which is essentially the same, but more compact) will work.

Community
  • 1
Peter
  • 123
  • 4

1 Answers1

3

If by "PW - Hash + Salt", you mean the derived key, your understanding is correct.

I've seen a few variations

  • Use of different salts each time you use one (i.e., Salt 1 and Salt 2 in your case). There is some theoretical benefit with this, but I don't consider it big enough.
  • Use the PW as input in the second round (of hashing / key derivation) too. Again, I'm not sure it is a big enough benefit, but the cost is negligible.
  • Use of a large number of rounds with the key derivation function (you probably implied this). This is important since the whole idea is to increase the work factor involved.
  • OWASP recommends 32 or 64 byte salt here: https://www.owasp.org/index.php?title=Password_Storage_Cheat_Sheet. IMHO benefits at this time are theoretical since iterating over even 16 bytes is not a trivial job for an attacker.

In general, I don't like the logic that says "let's do it just in case" (i.e., we let our fear decide without assessing the risks vs benefits). So I'm skeptical about the whole idea of the Intermediate Key. YMMV. :)

Sas3
  • 2,638
  • 9
  • 20