I have a webserver application which receives uploaded files, encrypts and decrypts them using AES256. I encrypted them so a potential hacker, who somehow got into the storage, can't do anything with the files. At the moment every file is being encrypted using the same hard-coded key.
Is it more secure to encrypt every file with an other random key stored in a database, maybe hashed (and salted, too)? Does this even provide a higher level of security? Or can it be worse to store such keys in the database?
key storage is a rather fundamental problem and hard to solve without rather special hardware.
as long as you store the keys on same machine as the encrypted data, an attacker will get both. that doesn't fundamentally change if you just have more keys.
you can't hash / salt the keys either, as hashing is a one-way function and with just the stored hash you yourself (or your app) would not be able to compute the key, so this is pointless.
if practicable, you could enter the key manually when the app server starts, so the key just lives in RAM, not on disk. make sure it doesn't get paged out to swap partition.
if you could encrypt the files clientside (before upload), so only the user has the keys, that would be safer...
Related
We have a legacy application that is storing the user's passwords down in the database unencrypted. We've had a fair few customers come onboard now which encrypting this password is a big deal to them (fair enough). Currently it's just a Nvarchar(100) field inside an SQL Server database table.
The situation is that we have multiple client applications accessing this database and validating against this password.
Just wanting to get advice on how we can achieve encryption on this field in the database without having to rewrite all the client applications that read off of it? It's not out of the question to change the client applications but we're trying to get away with this with as little fuss as possible.
Any ideas?
Do not do that, store salted, iterated HMACs of the passwords. Use something like Bcrypt, password_hash, PBKDF2 or similar.
If the HMAC is not salted and iterated it is not sufficient. Simply hashing without salting leaves the hashed passwords open to rainbow table attacks.
Convert the existing passwords now.
Let's say I have sensitive data in the database server that needs to be encrypted (i.e emails, etc..) and I want to make sure that in the event that the server is compromised, the attacker shouldn't be able to decrypt these data (at the very least make it harder).
I've read some solutions online, and it seems like I can either
Use Hardware Security Modules (i.e. Amazon KMS/Vault) to having a separate server handle encryption/decryption.
Use Public Key Encryption (where the public key in database server encrypts data, and a private key is stored in separate server that solely handles decryption)
What are the tradeoffs of each other and which one would you choose?
This has puzzled me for a while now. I don't have a broad understanding on encryption, but I understand the principle.
For the sake of an example, let's assume I have a program whose sole purpose is to post a random user's input to my private facebook profile. Now to do this, the program must have my login information to facebook (if this is not the case, assume another third-party application). This information, or credentials, must be stored somewhere, since the program's post method would be done without administration.
I know it is a bad policy to store the login credentials in the code as plain strings, as the compiled code can be decompiled and my credentials would be readable. The recommended solution is to store them in a separate file, encrypted.
As far as I understand, the encryption / decryption needs a key that also needs to be stored somewhere. Can't this key and the encryption algorithm be read from the decompiled code and used to decrypt the credentials?
Is the benefit of storing the credentials encrypted based on the extra step on decompile-decrypt, or have I drastically misunderstood something?
There are 2 ways one could check supplied credentials when you have encrypted version:
Decrypt the encrypted version; this would obviously require storing the tools necessary to decryption, which is unsafe
Encrypt what you are trying to check, and see if it matches your encrypted version. This does not require the ability to decrypt anything.
I'm encrypting some data that needs to stay on the client, and so will the Salt, Key and IV. Is there a standard way of handling this data on the client to prevent people from discovering it and encryption your data?
I can think of plenty of things to obscure them, but there must be an industry standard way of dealing with this issue.
There's no additional security risk if the IV and salt are known. IV's are safe to store in the clear, and salts are to help prevent precomputation and rainbow tables.
So you're really just talking about the key. There's a couple solutions, each with it's own tradeoffs. In your question, you only mention you need to encrypt data on the client. Does the client not need to decrypt?
If this is a Windows client, you can use the Data Protection API to protect the key under the users credentials.
Protect the key with a passphrase. If you don't mind entering a passphrase each time the client needs the key, this can offer reasonable protection, and it's supported in most cryptosystems like OpenPGP.
If the client only needs to encrypt, you can use a hybrid approach with public keys (like OpenPGP). In this case, you only store the public key on the client, and the private key somewhere safe. When you encrypt data, you'll generate a random symmetric key, and encrypt that under the client's public key. Now if someone compromises the machine, they won't be able to decrypt any of the session keys.
Use specialized hardware like a hardware security module or smart card. This is the most expensive route, but depending on your threat model might be viable.
How can I safely store cookies between my program's sessions? Should I use encryption or is there another, simpler way? If I will use encryption, what is safer: store encrypted cookies in files or in registry (with QSettings)?
I use Qt.
It isn't really needed to encrypt cookies when you save it to hard drive (if you aren't trying to defend against people who can read the user's hard disk).