I'll start by saying I understand wanting to make data as safe as possible.
I have an app and I would like to just encrypt all of the information that can be used to personally identify someone in the database.
So I have read that it is terrible to store your key on the same server as the data. Okay so separate servers, no problem. Then I've read that It's terrible to put the key in the code on the app server (away from the data). People say that the proper way to store an encryption key is by using a HSM or a Key vault like Azure Key Vault. Ok, I am on-board with that but if my code has access to the HSM or the Azure Key Vault (which it would need to have in order to decrypt or access the data AT ALL...
If my code is stolen from the app server (which is why storing the key in the code itself would be insecure) Why couldn't an attacker just use the same method that my code uses to decrypt the data from the HSM or Key vault?
Assuming that it isn't safe to just store the key inside of the code itself.. How is it any different to have a method or a function that can decrypt the data in the code? That would essentially tell the attacker how to get the key from the vault anyway, wouldn't it?
What is the extra vector or layer that using an HSM or Keyvault prevents?
I don't mind paying for and implementing the extra layer. I am genuinely curious as I can't really see any difference.
I think your question is mainly about protecting secret keys in software vs. hardware key management solutions. the following links have useful information about their differences:
Usage of software/hardware-backed Android Keystore and possible security/usability drawbacks
https://www.itprotoday.com/iaaspaas/software-vs-hsm-protected-keys-azure-key-vault
if I understand your question correctly, it's because the application never sees the actual cryptographic keys. the HSM just exposes the primitive crypto operations, but never the keys themselves.
an attacker would therefore need to be logged into your "app server" in order to perform the operations, which is (hopefully) relatively easy to revoke/deny. if you had the keys available to the code itself then they could continue using the keys on any existing encrypted data until it has been re-encrypted after rotating in a new key. this also has associated assurance difficulties, e.g. how do you know the attacker didn't manipulate some data while this rotation was happening
Related
I am wondering what the functional benefits are of applying Tri-Secret Managed Key security in Snowflake warehouses?
From what I understand:
the Tri-Secret method let's you define your own key
revoking that key will make it impossible for Snowflake to decrypt your data
But is the level of encryption in any way more secure?
The only difference I see is that a Snowflake key and your own key are combined.
Prohibiting access to that key will make it impossible for Snowflake to decrypt, rendering your data useless.
And then what? How to recuperate from that?
Also see: https://www.snowflake.com/blog/customer-managed-keys/
This is from Snowflake themselves. What they essentially say, is:
you have more control, but you must supply Snowflake with that key otherwise they can't do their work
you can shut out Snowflake from accessing your data if you mistrust them
if there is a data leak, you can prevent further leakage (but why not shutdown all access in that case, except for reverified trusted parties???)
I am stymied by this functionality.
The only response I get from local Snowflake representatives is that the Dutch financial laws/regulations prescribe or at least imply the need for this.
Regards, Richard.
Let me start by making the most important statement here: Don't use customer managed keys, unless you really need to use them.
Think of the worst case scenario: If you don't have an incredible resilient platform to securely store your own keys, then you risk losing all your data if you ever lose your keys.
Let me quote now some 3rd parties on when customer managed keys should be used:
Google says:
Customer-managed encryption keys are intended for organizations that have sensitive or regulated data that requires them to manage their own encryption key.
Meaning: Customer managed keys are intended for organizations that are required to use them. Don't follow this path, unless you are required too.
Or why would some companies start using their own keys, or stop using them — from CIO.com:
If you’re considering whether bringing your own keys – which also means securing your own keys – is right for your business, the first question to ask is are you ready to become a bank, because you’ll have to run your key infrastructure with the same rigor, down to considering the travel plans of officers of the company. If you have three people authorized to use the smart card that gives access to your key, you don’t ever want to let all three of them on the same plane.
Same article about Microsoft customers on the automotive industry:
“They all start by saying ‘I want to be in control,’ but as they see the responsibility and they understand to what extreme lengths Microsoft taking this responsibility, they say ‘why don’t you just do it.’ They don't want to be the weaker link in a chain.”
And NY financial institutions:
Even some New York financial institutions, who initially wanted BYOK that ran against their own on-premises HSMs decided against that when they considered what could go wrong, says Paul Rich from Microsoft’s Office 365 team. “An HSM could have been powered down, taking out a vast swathe of user base. They quickly got the idea that this is potentially a great denial of service attack that malicious insider or attacker performs on the company. These are our most sophisticated customers who are highly sensitive that this is a big responsibility but also a threat of potential destruction, whether that’s accidental or malicious.”
So you should only use customer managed keys if you already understand why they would be beneficial for your use case - and only if you are ready to incur the cost of securely managing them. Otherwise, just let Snowflake handle all these complexities for you.
On the other hand, benefits of using tri-secrets from the Snowflake announcement post:
Customer-managed keys provide an extra level of security for customers with sensitive data. With this feature, the customer manages the encryption key themselves and makes it accessible to Snowflake. If the customer decides to disable access, data can no longer be decrypted. In addition, all running queries are aborted. This has the following benefits for customers: (a) it makes it technically impossible for Snowflake to comply with requests for access to customer data, (b) the customer can actively mitigate data breaches and limit data exfiltration, and (c) it gives the customer full control over data lifecycle.
On the same blog post you'll notice that Snowflake tri-secret customer keys are managed by AWS's KMS. This gives you the above benefits, without having to deploy your own infrastructure to manage your keys. You still need to carefully consider your responsibility for safeguarding your key.
AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. AWS KMS is integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.
The blog post hasn't been updated to reflect that also GCP and Azure can be used to manage the keys, as stated in the docs:
Tri-Secret Secure lets you control access to your data using a master encryption key that you maintain in the key management service for the cloud provider that hosts your Snowflake account: AWS: AWS Key Management Service (KMS); Google Cloud: Cloud Key Management Service (Cloud KMS); Microsoft Azure: Azure Key Vault.
Synonyms for future research you might want to perform: BYOK, CMEK.
I am creating a mobile app that uses Google App Engine (python) for the backend. Users sign in with Twitter on the app, and the auth token and secret are passed to the backend (over https) so that the server can authenticate with Twitter and also periodically sync friends and followers in a background task. Because they are used by the background thread, I want to store the information in the datastore so they can be retrieved and used later.
Right now, during development and testing, I just put these in the datastore in plain text. But I'd like to add a little more security by storing it encrypted and decrypting it when its needed. Thank you for any help!
For general account passwords, I use
security.generate_password_hash(raw_password, length=12)
based on how webapp2_extras stores the passwords. But this approach wouldn't allow me to retrieve the data. Is there anything similar that allows for encryption and decryption?
Normally for password storage you would use a unidirectional (One way) encryption technique so that no one can work out what the password is and then take the user supplied values and compare them to the stored values. This way you're never really storing the actual password and it's less likely to be stolen.
What you're looking for is a bidirectional encryption technique where by you provide the value and a key to create an encrypted value and can apply the key to the encrypted value to get the original.
You haven't stated which language you're using so I cannot provide a good example, however I suggest looking at techniques such as AES. Please keep in mind that if you choose an encryption technique with a short key it will be much easier to brute force. Any encryption that is bidirectional is at risk of easier brute force and once the key has been determined ALL passwords are at risk of being decrypted. Most languages have some form of support for AES and similar encryption techniques.
There are many techniques available, some much newer and more secure so do some research and see what you deem 'secure enough'.
Read more here: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Certain highly-sensitive information (payment info, usernames, passwords, etc.) should be encrypted before it can be persisted to my database.
Later, that information has to be decrypted in order to be fetched from persistence and used at a later time.
If I use, say, AES256 to encrypt a billing address, I'll still need to store that AES256 key/passphrase in persistence as well.
If the whole point behind encrypting information that is going into a database is to protect that information in case someone hacks into my database, and I'm storing the key to decrypt that same information in the database, then what's the point of encrypting the data in the first place?
If someone hacks into my database, they'll be able to find the persisted key and decrypt any encrypted data they want to anyways.
Am I missing something here?
There is an old saying "Encryption is easy, key management is hard". And that very much applies here.
If you need to store data in an encrypted format (you frequently don't because you only need to hash the data not encrypt it), you do not want the encryption key to be stored in the database. You want the key to be accessible when your applications need to decrypt the data but you don't want people like the DBA that has access to all the encrypted data to be able to get the key. You want to make sure that the key is backed up so that you can recover the data but you don't want those backups to comingle with your database backups. Key management, therefore, becomes a very thorny problem to solve.
In the vast majority of cases, you want to purchase some third-party key management solution that can deal with these contradictions. Just like you don't want to implement encryption algorithms on your own, you don't want to do key management on your own. The folks that attempt to solve key management on their own generally do not succeed.
A better option would be to use certificates and this can easily be done in most RDBMS.
The best option regarding passwords is to hash them. This is a one way hash, and is not decrypted. Basically, when a user logs in, you hash their input password, and compare the hash against the one stored in your db for a match - and a successful login.
Regarding payment information, you will need a random generated private key. Depending on the system and implementation this can be stored a number of different ways.
You can store this in a config file, encrypted using an RSA container for example so it is not readable.
There are other solutions as well.
You can also encrypted db connection strings and the like with the RSA container method above to help prevent anybody actually seeing you db username password your application will use to access the db.
In some project we have very that even our staff is not suppose to have access to. In theory, we have policies to ensure they don't. In practice, we are in Africa and policies don't mean a lot, no matter how strongly you enforce it.
I would like to know is there is a way to encrypt data in your database so:
each user password encrypt and decrypt its own data, and its own data only;
data is decrypted as late as possible in the process to ensure maximum security to the user. Ideally it would be on the client side I guess, but I'd love to hear that it's possible to do some crazy thing I don't know about on the server side.
data is still searchable. Is that even possible?
My first idea was: "if a customer want THAT level of protection, then give him its own hosting on a virtual machine and encrypt the hardrive, then all maintenance must be done with it's allowance".
I can't come up with a fancy strategy just how I've implemented this:
Keep in mind that you have to re-encrypt everything when the user changes his password. I'm using always the same encryption key but the key is encrypted using the user's plaintext password. So I just have to re-encrypt the key. The user's password is stored as a salted hash so nobody can decrypt the key and the data even if he sees the hash.
It works like this:
User enters his plaintext password
Create salted hash
Check if the generated hash matches the one in the database (authentication)
If yes, then decrypt the key for the data using his plaintext password
Decrypt stored data using the key
This won't give you 100% security but improves it.
Here are a few things I can think of:
You should encrypt data stored when it is stored in the and when you read it back. Use a solution that integrates at an RDBMS level rather than the data layer.
For the transport of data to and from the application, use HTTPS web services.
If you have a Desktop application, do not store any data and log files etc locally.
If it is a web app, make the app HTTPS as well.
Security is bound to make the app a little slower than using plain data, but that's the price you will pay.
It really depends on what and where (on the client or server) you are doing with the data.
For example, your application don't need to know the password itself to verify it during authentification. Best practice for this use case is to store only a cryptographic hash (e.g. sha1) of the password and a random salt. That is sufficient to verify it, but giving only the hash and salt, it would take a nearly infinte amount of time to figure out the plain password.
Encryption can be a soultion if you have to exchange data over unsecure channels. But keep in mind that in order to process the data you have to decrypt them. So if de- and encryption is done on the same machine, it's rather pointless. And if decryption is required it doesn't matter how late you are going to do it, because of the key must be given anyway.
You can use encryption to secure the communication between the server and the client, for example. You could even generate messages on the server that only the client will be able to read and vice versa using asynchronous encryption. So once the message was generated on the server and encrypted using the client's public key even the server isn't able to read the message anymore, because of the private key only the client knows is required for the decryption.
What you denfinetly can not solve by cryptography is, when you have data on the server, that the server should be able to read in order to process them but human users unrestricted with priveleages to this server shouldn't.
I have a encryted database and decryption key. How to keep decryption key away from hacking(Both database hacking and unauthorizated accessing PC.)?
Hardcode in assembly.
keep in registry.
keep in RAM.
Moreover, I need algorithm for encryted data. What's the best algorith for doing this in security per decryption time term?
RSA
AES
Twofish
RSA vs AES
Thanks,
You are asking the wrong questions: first you need to decide how secure you need things to be. Then you need to decide whether you want symmetric (think DES, shared key)) or asymmetric (think RSA, public and private keys), and also think hard about key management, because that is often the point of weakness.
Asymmetric algorithms are orders of magnitude slower than symmetric ones; they are often used to protect a symmetric key, rather than on the whole data.
There is no way to "keep the decryption key away from hacking" if you store it with the encrypted data. Period. Key management is often the hardest part of any security policy.
As for encryption algorithm, RSA is a very different type of algorithm to AES and twofish (see http://en.wikipedia.org/wiki/Symmetric-key_algorithm#Symmetric_vs._asymmetric_algorithms).
To answer both questions will require more information. Exactly why are you trying to encrypt the database? What threat are you trying to manage?
It will never be perfectly secure, especially given physical access to the machines, but you can make it difficult.
Use 3DES to encrypt the database fields you want to protect. Note that you will not need to encrypt every field, and you shouldn't. (both for speed, and because if you lose the key, you'll at least have a clue what you need to do)
Do not store the key on the database server. If you must, store it on a different drive than the database or web app.
Keep a backup of the key on a thumb drive or something. Do not skip this step.
Split the keyfile into several different files, scattered over different folders and different drives. Do not use names that indicate the purpose of the files. Store the locations in the registry.
Use code to read the registry, fetch the pieces of the key, and assemble them. Write this code yourself, and do not use a name that indicates the program's purpose.
I interpret your description that it is necessary to hold the decryption key SOMEWHERE on the database machine to carry out your work.
Given sufficient knowhow and access to the hardware you cannot protect your database that it is impossible to break through your encryption.
For all other cases where physical access is not possible you should refer to the encryption guidelines which exist for all major databases using the specific technologies unique to most platforms.