1

A system I'm implementing requires a user to create a single user, with a single login password.

I want to have a single password for the system, and not require multiple different password entries in order to encrypt/decrypt files after login in (the main purpose of this system).

The way I've implemented this is: when the user first setups on the account password,

  • the password is hashed (bcrypted) *
  • a salt is generated *
  • a crypto key is generated using PBKDF2 (based on the salt)
  • 256 random bits are generated
  • the 256 bits are encrypted with the key derived using PBKDF2 *

All of the above "*" information is stored in a database

The decrypted 256 bits are used for the actual file encryption/decryption.

The reason I'm doing it this way, is if the single user decides to change his password, the files will still be decryptable (i just have to re-encrypt the random 256 bits with the new password).

Is this a common and secure approach?

Improve this question
12
  • 1
    Is this a webservice where the encrypted info lives on your server?
    – MikeSchem
    Apr 4, 2017 at 18:45
  • 1
    Yes it's a common approach.
    – Gudradain
    Apr 4, 2017 at 18:57
  • 1
    What do you do when the user forgets their password? It's okay if the answer is "well, then their files are rendered inaccessible", but it should be a conscious decision.
    – user
    Apr 4, 2017 at 19:25
  • 1
    ^ yup, that's what I was gonna ask.
    – MikeSchem
    Apr 4, 2017 at 19:27
  • 1
    Also, I'm sure I don't have to tell you to make sure you encrypt the data on it's way down (ie. https).
    – MikeSchem
    Apr 4, 2017 at 19:27

1 Answer 1

Reset to default
2

Yes, this is a workable approach. A few issues string to my mind, though.

  1. You should salt the bcrypt hash as well, not just the PBKDF2 function
  2. You should not use the random 256 bits directly as an encryption key (unless you know exactly how your RNG works and always will work in all future versions). Use that random data as an input material to a proper key derivation function (like HKDF) instead.
Improve this answer
2
  • 1
    I don't agree on your second and third point. There is nothing wrong in using PRNG for key generation as long as it is CSPRNG. Actually, it is a preferred way of generating symmetric keys. HKDFs are used when you want to expand low entropy material to a cryptographically sound key. As for PBKDF2, if the output of PBKDF2 is used as an encryption key, once you change the password you will need to decrypt and encrypt all of the files again. I believe author is correct is his design. Similar design is used in DPAPI for example.
    – Marko Vodopija
    Apr 5, 2017 at 11:41
  • As I said, using the RNG data is fine, if you know which PRNG is implemented and thus can be sure that the output is not biased. The problem is, that most of the time, developers don't know that and just use some generic GetRandom() function. Using HKDF (or just a single HMAC call) afterwards, gives you an addition safety net. You are correct about the second part. I misread the question, and beleived that he is reencryptng the data upon password change anyway with a new 256-Bit key. I'll remove that part from my answer.
    – mat
    Apr 5, 2017 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .