I am designing a web application at the moment, and one of the requirements is to secure the user credentials as well as their roles. Now ofc besides the usual pwd hashing + salt +....
I was thinking of putting those specific tables in an encrypted H2 database, and the rest of the data ina MySQL db. the advantages of H2 in my case are: in-memory storage, so means faster access; encrypted db so an additional layer of security in case the server gets compromised.
My question: is this a common practice when an additional security layer is demanded? meaning is it a good idea to seperate the login info (in my case, it is the sensitive data) from the other data?
Thanks
Ok I got my answer at the security forum, for those interested this is the link https://security.stackexchange.com/questions/7062/securing-sensitive-data-in-a-db-is-using-h2-worth-it
I don't think that this really adds a relevant layer of security.
If your server is compromised and your server can verify the credentials of users, then whoever compromised your server has the necessary data to verify it as well (for example: you'd need to store the encryption key/password on the server to decrypt the DB, unless you enter it on each startup).
And: it complicates your setup quite a bit, which in itself can lead to lots of security problems ("Why can't component A read this file? Oh, I'll just make it world-readable"). Simplicity can be good for security.
If the application is very simple I think you can use only one type of database, e.g. MySql. You can hash the password before storing in the database. Note that hashing is different from encryption in that you cannot get the actual password from the hashed password. When a user tries logging in you hash the user entered password and compare the hash value that is already stored in the database. If a salt value is used then it would be extremely difficult for a hacker to get the actual password even if she has access to the hashed password.
For a more complex application I suggest using one of the ldap servers (e.g. openladp). Then you get the password policies and hashing for free.
Related
I'm developing an budgeting application that uses a set of tokens and secret keys to access an external financial service, where a token-secret pair map to a single account. In this system, a user can have multiple accounts and therefore multiple sets of token-secret pairs. The token and secret can be used to access the transactions for an account, which means that the token-secret pairs should be securely stored (and be guarded against nefarious access or tampering). Although these pairs should be securely stored, the external financial service API requires the token and secret in plaintext.
What is a secure technique for storing these credentials at rest but providing the external service API with the original, plaintext credentials?
My application is a REST-based Spring Boot application written in Java 9+. Although there have been other answers I've seen on this topic, many of them are specific to Android and use Android security techniques (as are thus not applicable to my application). This application also uses Spring Data MonogDB to store other non-sensitive information, but if another technology is required for satisfying the above security requirements, I am open to suggestions.
This is not a problem that can be solved inside Java.
The token and secret can be used to access the transactions for an account, which means that the token-secret pairs should be securely stored (and be guarded against nefarious access or tampering).
The fundamental issue is who you are securing this against:
If you are trying to secure it against the people who manage the platform, it is pretty much unsolvable1.
If you are trying to secure it against "ordinary" (i.e. non-privileged) users, then you can either rely on ordinary file system security (plus standard service "hardening"), or you can use something like a Spring Vault or a Hardware Security Module if local file system security is insufficient2.
If you are trying to secure against a hacker who might be able to acquire the privilege of a full administrator, this is probably unsolvable too. (Though a hacker may need to be sophisticated ... )
Note that you can do things like saving the secrets in a Java keystore, but in order to do that the JVM needs the secret key to the keystore in order to get the secret. And where do you store that secret?
Aside:
... many of them are specific to Android and use Android security techniques (as are thus not applicable to my application).
Those techniques typically assume that the platform itself is secure, and / or that it hasn't been "rooted" by the user.
1 - So, if your goal is to embed some secrets in an app that you give to a client to use ... give up. If that problem was solvable, priracy of software, music, videos, etcetera would have a simple and reliable technological solution. Clearly ... it hasn't.
2 - For a lot of purposes, it isn't sufficient. However, the decision should be based on an assessment the risks, and balancing risks versus the cost / severity of the consequences of security failure.
We have run into a requirement to encrypt certain sensitive data before storing it in a PostgreSQL database. Our application is a Spring app running on top of Tomcat. We need to store the keys so that our web app can encrypt data before inserting it and decrypt data after retrieving it.
We would like to avoid storing this type of thing in our config files (or files that are filtered by Maven) since those files are checked into source control and readable by anyone with access. We seem to have the same issue with database credentials but it looks like JNDI datasources might solve those.
Are there best practices for this when using Tomcat? Things like environment variables might work but would be cumbersome to maintain.
EDIT: To clarify, we're trying to prevent sensitive data loss due to unauthorized access to the actual database file. Our db lives on a different physical box from our app server so we feel comfortable keeping the keys on the server that the application server lives on.
As far as I have seen, all the best practices around credentials optimize ease-of-use (for the operations team) and code simplification (for the development team), rather than optimize for security. This is very disappointing.
I would state the requirement as: Do not ever store any credentials or encryption keys in an unencrypted form, whether embedded in properties/config files, source code, or files managed separately from the application.
Some effects of this requirement:
JNDI data sources do not work for DB credentials, because the configuration of the JNDI data source resides in a configuration file in the container.
Passwords/passphrases for encryption/decryption (e.g., for the data in a database) cannot reside in the code or a properties file.
You must implement a way for the operations team to pass the secrets to the application as it is instantiated.
How might you design a system to meet this requirement?
Store all of your secrets in an encrypted file in a centralized location (e.g., in Amazon S3 or a Hardware Security Module). The passphrase/credentials to read this encrypted data must never be stored digitally - it is provided (e.g., in the body of a POST) when the app spins up. In addition to the passphrase to the secrets file, you may also need to dynamically provide credentials to get access to the file itself.
When the application receives the passphrase to the secrets file, it cracks it open and initializes it's internals (e.g., create DB data sources, initialize the encryption services, etc.).
You don't need encryption. You need access control.
Best practice? Yes. Cheap? No:
Don't use a single web server user account to log in to the db. This allows privilege escalation and data theft via SQL Injection. Use a unique connection per user. This kills connection pooling and allows maybe 500 simultaneous users max per db box.
Use a database that supports Row Level Security and Column Level Security. Right now, this is just Oracle. PG9.5 will have it. You can mimic it in 9.4
Put the db in its own network zone. Only the web server can connect.
Use a DAM (database activity monitor) to look for bad queries in and too much data out
A guide: https://securosis.com/assets/library/reports/Securosis_Understanding_DBEncryption.V_.1_.pdf
So, I'm writing a password verification thingy, loading username and passwords from a database, but I can't figure out how to keep the database username and password out of the code.
String user = "username";//database username, not username to verify
String password = "password";//my password, not users password to check
String url = "jdbc:mysql://databaseurl:3306/table";
//i want this hidden somehow
I could load it from a file, but then people could just read the file.
Obviously I don't want people gaining access to the database and reading secret information. How should I go about doing this?
EDIT: What I'm asking, is, how can I secure MY database credentials. Other people should not have access to the database
You could, for instance, decompile the jar and read the above lines, and access my database using my credentials. (using a program such as jd-gui)
Use password encryption.
If you application runs inside J2EE container, use standart tools
Look at sample for Jboss container
If you're going to give the user direct access to the database, why not just make the username/password you're passing to the database the user's actual username/database?
Typically in secure systems the database is not directly exposed to the user. The user passes a query to some system which then performs authentication and then if passes passes the query to the database.
In other words, if you're relying on the obscuring of the database login credentials as the obstruction to accessing the database, you're relying on the client to authenticate itself with respect to actually querying the database, which is a bad, bad idea. As soon as your database's login credentials are compromised, your whole security scheme has now failed.
You can keep database details in a
property file/database
. It is a kind of one layer of abstraction. And in that property file/database, you give some different keys so that at the time of accessing database, take the keys/columns from property file/database and construct url information.
Secure your authentication and authorization services using a PKI exchange with a properly signed certificate (so it can be revoked if something does go wrong, and it certainly may).
One example is ws-security (a SOAP extension), but if you need to use REST you're stuck with transport-level security (securing your connection with HTTPS).
You might want to read up at http://security.stackexchange.com for more insightful commentary, rather than "store it in a property file."
I want to make an application which will monitor user's email account for incoming emails as well as his twitter account for tweets. The user has to provide his login credentials therefore. My doubt is how and where to store this sensitive data? I don't want my application to annoy the user asking these things repeatedly.
Moreover, if I should encrypt and then store these data then how should I protect the key which I am using in my application?
The point of encryption is to make the secrecy of a plaintext depend on the secrecy of a smaller key.
In the case, encryption alone is useless to you, since you have no way to store the key either.
Instead, you need to use some existing secret managed by a third party (using a password), and use it to derive a key.
On Windows, you can use the DPAPI, which is ultimately backed by the user's login password.
If the user forgets his password (or if it is changed from a different account), your data will be irrecoverably lost.
Note that this will not defend against code running as that user.
You need to decide what you're trying to defend against.
If you really need it (it's no good idea but...) you may want to create encrypted storage for passwords like Firefox has for example. Users will protect passwords with master password.
The answer is nowhere. You should never store passwords even in encrypted form.
The "correct" way is probably simulate the behavior of similar web applications. Indeed if you login into twitter you can select check box "remember me" and twitter will not ask you for the password next time, right? How is it implemented?
Typically special token is stored on client side in cookie. The cookie is sent to server and is used for authentication. Cookie has expiration date, so it will be automatically removed when its time is over.
Unless there is better solution for desktop applications I'd suggest you to try to use this mechanism.
i think use a password that is your application wide and use that password to encrypt all other passwords and when an application say twitter is needed use that password to decrypt... further take salted-hash of master password and save it on disk.
We are using Java + H2 Database in server mode, because we do not want users from accessing database file.
To add more protection to database file, we plan to use AES encryption (add CIPHER=AES to database URL) in case the storage is stolen.
However, each user will also need to supply file protection password when connecting ([file password][space][user password]).
Although users do not have access to database file, knowing the encryption key (file protection password) will make the encryption quite useless.
Any idea to keep the database file secure (encrypted) without exposing file encryption key to users?
Thank you.
There is currently no way to do that within H2.
One solution is to use file system encryption that is independent of H2.
But please note at some point you would have to provide the (database file or file system) password. This could be when starting the server (prompting for the password to be entered manually). Unfortunately, because somebody would have to enter the password, you couldn't fully automate starting the server.
One clever approach I've heard of is to write a simple webservice that blocks all sites but your webapp's server. Use SSL with certificate-based authentication.
This webservice provides the encryption key.
It sounds really stupid since it seems to provide the key without authentication but the certificate-based authentication covers that. It provides encryption of the key during transit (and if you're really paranoid you could use a shared key to wrap the database key). It can only be called from the webapp's server and it's a lot harder to trigger a webservice call than to do SQL injection or even looking at the filesystem.
If your risk model allows it you could even run this webservice on the same box as your webapp.
A second approach, if you have the necessary permissions, is to create a virtual disk. Put the key on the virtual disk.
During startup you mount the virtual disk, read the encryption key, then unmount the virtual disk. In some designs you could drop the operating system permissions that allow you to mount the virtual disk - it would then be literally impossible for an attacker to read the key via your webapp.
This comes from a much older strategy that read sensitive information from a CD-ROM (or even floppy disk). The app would read the key and then eject the media. It works but requires manual intervention to reload the media before the next restart. It also doesn't work in modern environments where servers don't have CD-ROMs, much less floppy drives.