I have a webapp, with all my configurations defined in a file which includes, passwords, secrets and other configs. What is a secure and easy way to provide these settings when deploying to App Engine?
I have 2 files: config.dev.yaml and config.prod.yaml.
Solutions that I found:
google cloud key manager (GKM) however i think this solution seems expensive, and complex to implement.
put secrets in app.yaml as environment variables. A lot of people said that this is not secure?
include config file in deployment with source code. also people say this is a bad idea.
solution I'm thinking about that I'm not sure if it will work:
store all my config in the Firestore, and pull them at a build time?
I spent all day looking for answer to this, nobody seems to have a "standard" simple solution.
Secrets need to be kept secret. Therefore, putting the secrets in plain text either in environment variable or in a config file is not a good idea. And in both case, you will commit the files in the repositories, which is also ugly.
So, you need to keep the secrets secret until you need to use them.
You can use KMS and manage yourself your encryption/decryption. But it's not very funny to do and there is a lot of extra code to implement. At the end, you store only encrypted version of your secret
You can use Secret manager. You store only a secret reference and a simple API call allows you to get the secrets. And you store only the secret manager references in your files.
The main issue with these secure solutions is if you have framework or library that autoload values from configuration automatically. Therefore, you have to implement a hook at the application startup to convert the values from secret form to plain text, and then continue the normal loading.
If you share your language, I could have answers.
Related
Hello to all
I did a lot of research on encrypting important data such as credit card numbers in Spring Boot, and three ways to securely encrypt data caught my attention:
Protect secrets with Hashicorp Vault
Column-level encryption
Data Encryption with Java Cryptographic Extensions
All three methods have their advantages and disadvantages. The initial setup of the vault requires a lot of configuration, and I could not find a complete and integrated source for learning it. Column-level data encryption imposes a large processing load on the server, and requires the management of cryptographic keys. The third case requires the creation, management and maintenance of encryption keys for each client request. Is there a better choice for managing sensitive customer data such as email addresses or credit card numbers? Or is it recommended to use Vault to manage the secrets of website users?
Can I encourage you to take a look at our product. I don't want this to be a shameless plug but as a developer who has felt your pain, I think you would want to take a look at what we have. We have designed it to address some of your concerns. ubiqsecurity.com.
To address your specific considerations.
MUCH easier than setting up Hashicorp Vault. We have demos of creating an account and sharing encrypted data in two different languages within 5 minutes. The demos should help you get started if necessary but I wouldn't expect you to need them. Our client libraries also have fully functional examples to help you get started.
This seems to be the reason DBAs are hesitant to turn on encryption within the DB layer. We are leaving the encryption at the application layer. If your encrypted DB is up and running and someone is on the DB server with harvested credentials is your DB really secure?
We manage encryption keys for you. Client uses an API key (similar to other SaaS). Data is encrypted on the client.
Please feel free to reach out to us if you have any questions. Again, not trying to be a shameless plug, but we know the problems developers face when working with encryption and feel our solution addresses a number of the issues you are facing as well as others you haven't even mentioned.
I am using Heroku to host my web server. Is my source code there available or open to others as there are some private information in my source codes? If it is, how can I prevent that? I looked at some questions before, but it wasn't clear.
Your code pushed to Heroku stays private, however it is a bad idea to store sensitive data (tokens, passwords, IDs) in the source code.
Heroku best practises is to use Config Var to define secrets, these are injected into your application at runtime as environment variables (which you can access programatically - depending which language you use)
Are there any examples of using encryption to encrypt the disk-cache used by OkHttp's HttpResponseCache? Naively, I don't think this is a very hard thing to do, but I'd appreciate any advice or experience to avoid security-pitfalls.
Without too many specifics, here's what I'm trying to achieve: a server that accept user's api-keys (typically 40-character random string) for established service X, and makes many API calls on the users behalf. The server won't persist user's api-keys, but a likely use case is that users will periodically call the server, supplying the api-key each time. Established service X uses reasonable rate-limiting, but supports conditional (ETag, If-Modified-Since) requests, so server-side caching by my server makes sense. The information is private though, and the server will be hosted on Heroku or the like, so I'd like to encrypt the files cached by HttpResponseCache so that if the machine is compromised, they don't yield any information.
My plan would be to create a wrapper around HttpResponseCache that accepts a secret key - which would actually be a hash of half of the api-key string. This would be used to AES-encrypt the cached contents and keys used by HttpResponseCache. Does that sound reasonable?
Very difficult to do with the existing cache code. It's a journaled on-disk datastructure that is not designed to support privacy, and privacy is not a feature you can add on top.
One option is to mount an encrypted disk image and put the cache in there. Similar to Mac OS X's FileVault for example. If you can figure out how to do that, you're golden.
Your other option is to implement your own cache, using the existing cache as a guide. Fair warning: the OkResponseCache is subject to change in the next release!
we are saving user data on a server and we want to do save this data encrypted with TrueCrypt.
If a user registers, we generate an asymmetric key for him that is encrypted with his password. This asymmetric user-specific key will encrypt all the keys that are used for services, including the above mentioned data encryption.
If we now want to read the users files, add new and modify existing ones from within our Java Application running on a Application Server, should we mount the TrueCrypt container?
We think that it might be a security leak as an attacker could easily look in the mounted container, but we also have no other idea - we are kind a stuck!
I am sure someone can help us here.
Thanks,
Heinrich
#edit By the way, we are using Spring for your Java App.
I don't think it is a good idea to use TrueCrypt for this usecase. When using TrueCrypt you have no other choice than mounting it on each request to encrypted files. You should think about using plain Java encryption and do encryption and decryption yourself. There are libraries like Google Keyczar that may help you implementing this.
If I built an application that accessed some of the data from say Gmail, Twitter and Facebook, and I want the user to be able to only have to enter their authentication info once, and it's reset after some days or weeks, what is the best way to do this, dynamically, in Ruby?
I see a lot of people just having a config file of their clients'/users' credentials like so:
gmail_account:
username: myClient
password: myClientsPassword
This seems a) like it's very insecure, and b) it wouldn't work if I wanted to store this kind of information for thousands of users. What is the recommended way to do this?
I would like to be able to build an interface on top of these services, so having to enter credentials every time the user made a transaction isn't feasible.
If you're comforatable with the potential liability when a hacker gets into your database / filesystem, then go for it. And in all fairness, you should also disclose to your users that their passwords will be stored on your system, and let them decide if they want to give your program that level of trust.
But why do this in the first place? Facebook Connect and Twitter & Google using OAuth there's no need for you to store user passwords at all. At some point a user's cookies will expire (or they'll try to access your site from another computer) and they'll have to re-authenticate. You can't prevent re-authentication - instead, you should make it as easy for the end user to handle as possible.
Such services are providing OpenAuth authorization. You are strongly recommended to have a look at it.
Security
I assume your application needs to know the password in plaintext. Then there is no way around storing it in some kind of plain way.
Store in some kind of encoded way eg. Base64, this protects you from knowing password when looking through the database with your eyes, but it does not protect you from anything else.
Ensure that the files are not readable from any other user
Encrypt your harddrive, so nobody can get the passwords from stealing your harddrive. Your computer will require inputung you the password during booting.
Storing
There is nothing wrong with storing much data in your filesystem. For better performance you can do the following
One file for each user, so the filesystem and not ruby needs to search for the data
Make a lot of subdirectorys. Some filessystems performance suffer's if you put to many files into one directory. eg. put the file 'abcd' into 'a/b/c/d'
You could use a database instead of the filesystem
This is the way it works for instance for fetcmailrc which has to be chmod to 600 (readeable and writable only by his owner). And yes, it contains the plain password.
I would strongly suggest you to use OAuth, but if you have to store the passwords (please be absolutely sure that you need to do it) you could use the OpenSSL library to encrypt the passwords. The OpenSSL library is quite poorly documented in Ruby, but as far as I know they are quite similar to the C OpenSSL library. Since I think you should use OAuth, and not storing the passwords I'll let you find the documentation yourself.
However, for the OAuth approach, you want to take a look at the OAuth gem. Google, Twitter (which I recommend you to use the excellent twitter gem for) and facebook (which has two seemingly good alternatives: RFacebook and facebooker)