3

I came up with a user-details-storing procedure that was, in the beginning, based on actual security-literature – but then I just kept writing without really doing all the cross-checking I should have been doing.

  • Username, password and personal details are entered.

  • A random 128-bit symmetric key is generated.

  • Two random initialization-vectors are generated.

  • The array in which the personal details (name, email etc) are stored is AES-128 encrypted using the freshly generated key and the first initialization vector.

  • The symmetric key itself is then encrypted with AES-128 – using the user's password plain-text password as the key and the second initialization-vector.

  • The newly encrypted key, initialization vector 1 & 2 and the encrypted array of personal details are stored in an object which is then serialized into a file under an ID – a hash of the user's username.

  • When program retrieves the details – it hashes the current user's username, looks up that hash in the "users" file (the ID), retrieves the object associated with it, decrypts the key and the uses the decrypted key to decrypt the user-data.

Is it grotesquely insecure? Am I missing something obvious?

2
  • What algorithm are you using to derive the encryption key from the password?
    – RoraΖ
    Aug 4, 2015 at 11:35
  • 2
    What's your mode of operation for AES? CTR? CBC? GCM? Why do you use the plain password as the key? Why don't you use a PHS to generate this key? (Argon2, Catena, Lyra2, yescrypt, scrypt, bcrypt)
    – SEJPM
    Aug 4, 2015 at 11:44

2 Answers 2

1

Few comments to the provided flow:

  1. Be sure that when you say "Two random initialization-vectors are generated.", they really are cryptographically-secure random.

  2. Symmetric Encryption must be Authenticated Encryption.

Therefore, I suggest you add som MAC (i.e using HMAC). E.g:

1. AES-encrypt: plaintext + secret key + fresh-generated random IV = ciphertext C1.
2. C2 = IV + C1.
3. MAC = HMAC(K , C2) where K is a different secret key independent the first used.
4. C3 = C2 + MAC.
0
-1

As @SEJPM's comment suggests, the scheme as described lacks some of the necessary detail in order to answer fully, but with some assumptions, we can come up with a couple of general points none the less. Specifically:

  1. The user's password should not be used directly as the key-encryption-key. You should use a proper PBKDF such as PBKDF2, bcrypt, scrypt, or another to turn the password into a properly random key with an appropriate work factor.

  2. Why are you hashing the username? Why not just use the username as the key directly? Perhaps this has value to the application, but it doesn't seem to have any security benefits as far as I can tell from your scheme description.

  3. To reiterate point 1, setting the work factor appropriately for your KDF is critical. If calculating a key from a candidate password can be done too quickly, your encryption will be mere window dressing, and will not offer significant protection from offline attackers who manage to obtain a copy of the encrypted data.

You must log in to answer this question.

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