I am designing a generic Java library which needs to Sign messages before Sending and Verify messages before accepting. Sign and Verify needs to work with both of the following constraints;
Use raw 32 characters long key with some additional details like key start date, end date, grace period, the algorithm as raw information (do not have a choice, but have to accept it as raw data).
Use a proper PKI certificate containing a public key
For PKI based secret it is straightforward to use JKS/PKCS12 to store information and use it.
The problem I am facing is how do I manage and store raw information? What should be the data structure? So far my options are;
Use JCEKS provided by JRE to store all the raw information in my own made up data structure as secret properties and resolve at runtime to execute my library
Use JKS/PKSC12 and along with X509 Certificate data structure to store all raw information under its Extensions
What I am really looking for is the best practices for these kinds of versatile requirements i.e. manage un-managed secret properties?
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.
My use case looks like this:
encrypt some super secret data using a key provided by user
when requested, ask the user for that key and decrypt the data
re-encrypt the data with a key that will allow my program to access the data for a user defined period of time
if token expired ask user for original key again
This feels like it should be a solved problem by my googlefu is weak today.
I could just decrypt the data and store it with a known key in my program but cracking my code would expose those secrets.
I could and maybe should, use some local secure storage for this data like macos keychain etc but i'd like to keep the amount of native variations to a minimum.
The answer to this specific question appears to be, no it is not possible to do locally.
The best solution to this kind of problem, ie a temporary cache of data decrypted with a user's key is to either use security tooling present on the users machine, ie macos keychain or to simply re-encrypt the cache with a key known to the program and except that it is possible to reverse engineer that program to find the decryption key.
My plan to deliver this is to generate an encryption key when the program is first run, use that + a known salt to encrypt my cache. The idea being that both the program, the generated key and the cache would need to be compromised together to decrypt my cache.
Am I right in saying that if I have a plain text password (say to connect to an SMTP mail server) in one of my c# controllers, there is no way for an attacker to view this (or the rest of the server side code for that matter) unless server security is broken?
I am on shared hosting so I can't do anything with IIS to encrypt web config (as far as I am aware). If this is such bad practice, does anyone have any suggestions as to how to best tackle this issue?
If this is such bad practice, does anyone have any suggestions as to how to best tackle this issue?
It is a bad practice. While you can't prevent an attacker who can read files on the server (or the backups) from figuring it out (quickly, if they're good), you can force them to spend more time and effort in reading your code/disassembled application and your config files both.
Are you allowed to set the SMTP password yourself? Store in your config file a very high number of iterations (millions; it's just startup delay!), a truly random** salt of 8 bytes, and a long, random "password" (binary is better). In your code, when the application is started, read those values, add a hardcoded string of 8 truly random bytes to the salt (a "pepper"), and use the RFC2898DeriveBytes class to generate the actual SMTP password (which you're likely to have to encode with Base64). Don't ask for more than 20 bytes of RFC2898DeriveByutes output; that's using SHA-1 as the native hash. You will obviously need to do this prior to changing the SMTP password :).
Regardless of your ability to change the SMTP, you can always encrypt the password, using the above RFC2898DeriveBytes to generate a 128 bit key for use with AES-128 in, say, the AesCryptoServiceProvider class if you're on .NET 3.5 or up, which is one of the few FIPS 140-2 compliant encryption classes in .NET.
If you want a way to handle this that prevents simply reading files from finding out the password, you'll need to look at something like an HSM (hardware security module) or other secure key storage provider outside of your appliance. Be prepared to open your wallet!
** In .NET, use the RNGCryptoServiceProvider class to generate random bytes for crypto use.
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.
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
is there a way, to encrypt information on windows, and have windows securely manage the passwords?
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call EncryptFile() on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use the FILE_ATTRIBUTE_ENCRYPTED flag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.
If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.