Master Data Encryption

I have a question about encrypting master data. I store some sensitive user data in a SQL Server database. The critical values ​​are all transformers, and I use AES256 to encrypt and decrypt them on the fly, including an individual IV for each value. The encryption key is the SHA512 hash of the password that the user selected. It works very well so far.

Now about the user password. When the user starts the application, they are asked for a password. The password is hashed with SHA512 and stored in the iOS keychain. For each write or read operation, NSValueTransformer will receive a password from the key fob. If the application closes, I delete the password hash from the key fob.

In my Core Data database, I have a special entity that has a random number! = 0, since this is only a value. To check if the user has entered the correct password, I retrieve this object and read the number. If it is =! 0, I know that the password was right, because when decryption fails, NSValueTransformer always returns 0.

Now my actual questions: do you think a good approach to encryption? How else could you verify the password you entered is correct?

I'm a little worried that keeping the password hash in the keychain while the application is running is getting slower because NSValueTransformer has to constantly access the keychain. Would it be safe enough to just store the password hash in memory, so will it be deleted when the application closes?

+6
source share
2 answers

You should not use a password hash, hashes should be fast in order to (relatively) easily make brute force attacks. Use a key derivation function , such as PBKDF2 .

Do not use the key obtained directly from the password as an encryption key. If the user changes the password, you need to re-encrypt all the data, and the backups will become useless. Use a randomly generated encryption key that you encrypt with a password-based encryption key key.

I'm not sure if the hash is stored in the key chain, instead of just keeping it in memory. The last time I looked at it, it was easy to decipher the keychain. And every attacker who can read the memory of your running application is likely to be able to track access to keychain or decrypted data. Just save it in memory and don't forget to erase the memory if the application pauses in the background, etc. This is obviously also true for every piece of decrypted data.

[EDIT: @JeffLockhart to clarify the procedure for the master encryption key] you generate a random key to encrypt your data, let him call it A. You can use SecRandomCopyBytes to generate the key A, see Apple CryptoExcercise for an example use. You use key A to encrypt user data. To save the key A, you need to encrypt the key A with the second key B. You should not use the password directly as the key B due to quick searches or word attacks. This way you get the password key using PBKDF, for example, in this stackoverflow answer. Then you encrypt key A with key B, for example. using CCCrypt . You save the encrypted key A and the salt used to obtain the key B. To decrypt the user enters the password, you get the key B using the password and salt. You will decrypt key A using the derivative key B. Hope that clarifies.

+7
source

You could look at this:

Secure incremental store

They implemented a subclass of NSIncrementalStore, which uses an encrypted SQLite database. This is a replacement for the Apple SQLite Store. Comes with a price.

+1
source

All Articles