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."
Related
I'm looking for a way to open a JDBC connection without specifying my database login and password in plain text, as the application will be distributed and any Java decompiler would reveal them, allowing the users to access the database easily.
Is there any way to encrypt them, or store them somewhere else?
Looks like you want to let Android application talk to your database directly? Don't do that. It's a major security flaw. No matter how you encrypt your credential, you have to reveal your plain text somewhere during the execution of the program, and anyone with a debugger can see that. The correct way is to have use an API on your web service and call that API from client. All database transaction should happen in a trusted intranet.
Why would you want to do this? Generally the business side of your application would have this info and connect to MySQL. There, a user does not have access to any code. Then you create an endpoint that actually is accessible to the public. There you can worry about passing username and password stuff to the business logic, which again, actually has direct access to your database.
Basically, do not open a jdbc connection anywhere but your server side. Its a security measure.
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.
I am creating simple web application.
There is some public data, and managed data.
Admin is logging in when performing some actions with private data.
Web application server: Tomcat.
Database server: MySQL.
The question is what is best practice to do login verification.
Should I:
a) login be used with some XML files like web.xml/context.xml, maybe using tomcat-users.xml? In this case I think Tomcat admins can easily manage (add/remove/change pass) users.
b) use MySQL db table like users. But then it is managed by DB admins. And well is it OK, to put users/passwords in some DB? Maybe should they be encrypted.
Maybe there's some other way.
Limitation is if some software is needed, this must be a freeware.
Thanks in advance.
The second option is the way to go. Ofcourse you need to store passwords hashed in the database. When the user logs in, hash his inputted password and compare it to the (already hashed) password retrieved from the database in order to know if his provided password is correct.
You can keep track of permissions in the user table by adding permission colums. Add columns 'Add', 'Remove', 'ChangePassword', ... and set them 0 or 1 to know if the corresponding user has the permission to do the action.
I want to implement a stay logged in or remember me in my jsp login page. I am using container based form authentication. I think I need to I have to store users' data such as userid and token - a status information to determine whether as user is logged or not, into the cookies.
Also I heard that we should not store users' password even it is encrypted.
If I store their password and userid, I can sigh them in automatically by submitting the data to servlet before I show the login page to users.
If I do not store their password, what method could I use to sign them in automatically?
I would suggest that you not create your own framework for this but rather use something like spring-security or Apache Shiro since the security of your application is pretty important and not something you generally want to build from scratch.
If this is purely for educational purposes, I would suggest looking at the code for the two mentioned applications to see how they handle it.
I have seen this implemented as a secure token in the cookie (with expiration date) whose value is also stored on the server for a set period of time and associated with a specific user account. When the user returns to the site with that cookie, the server will compare it's token value to that of the cookie and let them in if they match (and it is not expired).
Again, it is best to use pre-existing and tested libraries for this kind of work.
Best of luck.
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.