2

I'm currently developing an authentication service for our company. I somehow understand how to store a salt used in hashing a password in that it should be stored together with the hashed password. That means for every account, a unique salt is also created.

What I don't get is how do you store an AES Key and IV? Should there be a unique AES Key and IV for every account too? Or should there be 1 app wide AES Key and another app wide IV?

I've read this post but it only answers where I should store them.

Community
  • 1
Yongga
  • 21
  • 1
  • 2

2 Answers2

4

You describe very little about why you are using symmetric encryption, but in general, you use the same key but a different IV for each encryption operation, provided encryption and decryption takes place on the same device.

The IV is not a secret value but it should be randomly generated using a CSPRNG. This is very important.

It is common practice to prepend the IV to the resulting ciphertext so that it can be easily retrieved during decryption.

Luke Park
  • 249
  • 3
  • 8
  • The only way that using AES for encrypting passwords makes sense is if the key is derived from the password (via appropriate key stretching). I.e. a (hopefully) different key for each user. – symcbean Apr 05 '17 at 22:17
  • @symcbean The OPs actual question didnt mention encrypting passwords. – Luke Park Apr 05 '17 at 22:27
  • True but the one feature common to most authentication software is the ability to validate passwords. While an SSO/federated authentication system might use surrogate tokens created using reversible encryption, 1) this is an edge case 2) not mentioned by the OP 3) if this were the case, then rolling your own seems a bit silly – symcbean Apr 05 '17 at 22:34
  • @symcbean I'm not sure exactly what you want me to do with this information. The OPs actual question didn't relate to the authentication system at all. If you feel my answer can be improved, feel free to edit it! – Luke Park Apr 05 '17 at 22:53
1

You will store IV along with ciphertext, it is not a secret. But please bear in mind, there are various modes for AES (or any other blok cipher). Please see this question and also this for GCM.

The main point behind this is that IV must be unique every time you use the same key. Usually it must be random (use strong CPRNG), but some modes tolerate nonces.

To answer your question directly: yes, you can have one app wide key but no, you will not have one app wide IV.

You can also derive a key from user password and use it for encrypting user data. This will complicate "forgot password" functionality though.

Community
  • 1
Marko Vodopija
  • 1,062
  • 1
  • 8
  • 19
  • I disagree that using the same key for encrypting passwords for different users is a good idea (@Yongga: go read the answers to the post you linked more carefully or explain why you deliberately want to make the passwords recoverable). When a user forgets a password you generate a new one (and optionally provide a window where both old and new passwords can be used). – symcbean Apr 05 '17 at 22:23
  • @symcbean OP didnt mention why he would use encryption. I agree encrypting passwords for different users with same key is not a good idea but OP didnt say he would do that. Also, if you are deriving keys from passwords and password is forgotten, there is no way you can retrive encrypted information. That is what I meant when I said it would complicate things. I also implied that passwords are not reversibly stored. – Marko Vodopija Apr 06 '17 at 05:39