I'm not experienced with encryption at all, so please bear with me.

My use case: I'm working on a membership management web application to be used by a small organisation. When someone becomes a member, his ID gets read and the photo on this ID gets stored on our server. Only a few people with the right permissions are allowed to see the photo via the web application.

Even though it's legal to extract and store these photo's (at least in my country), it's still sensitive data, so I would like to make sure these are stored securely.

My idea is as following: when the user is registered, the image is send to the back-end (as base64 or another readable format, obviously HTTPS is used). The back-end will encrypt this image and generate a guid to be used as the file name. Both the guid and the encryption key are stored in the database as 2 fields in the users table. The encrypted file gets stored in a folder which is not accessible for the public.

When someone requests a photo, the back-end will check if the user is authorized and if he is, it will look for the file with the right guid, decrypt the photo and send it to the front-end as base64.

My first questions are: is this approach correct? Is the usage of a guid as a filename even adding extra security? My reasoning is: if someone gets access to the folder, he will not be able to see which file belongs to which member. Is storing the encryption key in the database a decent approach?

The thing I'm a bit struggling at, is the encryption itself since I do not have any experience with this. My plan is to use AES and I'm using this article as a reference: https://www.codeproject.com/Articles/769741/Csharp-AES-bits-Encryption-Library-with-Salt

The approach looks simple enough, but I have no idea how to handle the password/key. I was thinking of generating (although I don't know how exactly) a unique password per user on which the key will be generated. Only the key will be stored in the database as that's all I need. In all approaches I've seen however, a single password is used (so the same for all users in my case) and a unique key gets generated by using salts.

I'm not sure why I would need a salt anyway. If I generate a unique password per user, which is long enough and a series of random characters, rainbow tables can't be used. But is that the right approach? And if so, what would be a secure way of generating this password? Or is my reasoning completely wrong and should I do something else?

2 Answers 2


I am not good at crypto either so edit or comment below if i get it wrong.

The first and foremost thing you need to get right is APPLICATION LOGIC.

By that i mean the logic should have effective controls such that my image should not accessible by anyone else to begin with.For example if http://example.com/imgid=(GID),Now no matter what the GID is,my image shouldn't be accessible by anyone else,at all.That is two people could have the same GID .So the back end logic should be that my SESSION is associated with the images i have uploaded and the image to my account.DO NOT USE THE SECRECY OF GID AS A LOGIC

The next part is storing images at the backend

Here you should use symmetric encryption(AES256).The encryption key should be randomly generated with sufficient entropy using a cryptographically secure random number generator.The key is generated whenever a user signs up|uploads and then gets associated with that user.Store it in a database in the user collumn its fine.Then use the encryption key associated with that user to encryt and decrypt the image.


  1. The user signs up.He is allotted an encryption key.
  2. The user requests the image.
  3. The back end logic check's if the image belongs to the user asking for it.
  4. If it is true then decrypt it using his and only his decryption key and send the image back.
  • Thanks for the answer. Just to be clear, I wasn't planning the use the guid as part of application logic. My idea was to use it so that, in case the folder with the photos would be compromised, the attacker wouldn't be able to see which file is the photo of a specific user.
    – Bv202
    Commented Jul 17, 2019 at 19:39
  • What is stress is not use a GUID or any number.What i say is not use the secracy of such number to guide authorization logic
    – yeah_well
    Commented Jul 17, 2019 at 19:43

I'll add a couple of suggestions. First: you need to understand who is the attacker.

My reasoning is: if someone gets access to the folder, he will not be able to see which file belongs to which member.

That's alright, but how did they acquire access to the folder? If your web application was compromised and the attacker achieved remote code execution – it's trivial to grab pictures together with DB credentials from source code or running process and the whole DB dump. The same goes for people with server access.

This at rest encryption will protect you only against snooping eyes and path traversal vulnerabilities, having access to db+files = decrypted pictures.

Second: don't use your own crypto. Using AES directly is not much better. I suggest using SecretBox from libsodium, it offers high-level symmetric encryption with secure defaults (internally it uses 256 bit AES with message authentication).

Third: I'll echo Vipul Nair here, pay close attention to application logic and expose only what is needed. If "user account to picture" connection could be handled internally (via IDs and file names) - they should be.

You must log in to answer this question.

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