I am implementing a user login system and just want to run my security concerns by the community.
I plan on using Java's PBKDF2 to encrypt and store the users password/salt in the database upon the creation of the user account. Of course everything will be done over HTTPS. The resource I used contains actual source code documenting how to implement this functionality and i'll include that link at the end of the question.
Onto the "remember me" functionality. Is the proper way to implement this to:
Generate a UUID Session key upon login, store key in database, store key client side in cookie.
When a new session is created, get the key from the cookie, compare to database, create a new key and restore it client side.
Is there any security vulnerability here? I know a lot of resources suggest also storing the users ip address along side the session key and invalidating the key if the ip does not match. Doesn't the ip change quite often if the user is coming from a mobile network? Even on wifi, these days it seems most applications are not using ip verifcation? Say your dynamic ip changes, an application like Gmail doesn't log you out does it?
Resources:
Storing secure passwords in Java: http://www.javacodegeeks.com/2012/05/secure-password-storage-donts-dos-and.html
Implementing "stay logged in" in Java: How to implement "Stay Logged In" when user login in to the web application
Related
I'm trying to figure out database security in Java. Like video games, desktop app and others that uses database in its code and how they can store their password in it.
Here's an example:
There's an application that uses MySQL database for storing users data and their information.
A user is registered and logged into our app. He has 0 coin in start. He bought 100 coin from shop and his coin data changed to 100. During the steps that I mention, he always use database for insert and update his data.
In a nutshell, how can I hide my database information (username and maybe IP?) in my Java code?
In addition, I've searched a while and found that you can send web request for information, but if anyone finds the code of request, they also can make their program and use same request as my app. So, I cannot figure this out.
Usually, the database is in a server that you controls, and you provide an API to make requests.
In these requests there's no information about database username or password, that should be on your server.
Then, you need to protect that connection. Normally, yo do that with authentication and authorization. You need to provide username and passwords to your users, and that is present in any request they do to your server. Also, you need to make controls in your server to control what can do each user (control that a user cannot perform any query they want).
A common way to do this is using federated authentication and authorization, with protocols like OAuth2.0 or OpenID.
Also, you need to make sure that you use HTTPS, or attackers could capture the traffic and extract all the request information.
Short answer: you never talk from the Front End (UI, mobile application, whatever) to the Database.
Usually Frontend talks to some backend server - an entry point to the backend word, a gateway (there is indeed such a term). From that point, the request can be routed to another server, or be processed in the same server (depending on the application, its complexity, architecture, etc) and only after that the information should be stored in the database (or queried from the database and returned back to the end user).
Only the gateway is exposed to the "outer word", all the backend services and of course the database should be protected from the accidental/malicious access at different levels:
at the level of network so that it will be physically impossible to connect to it if you're not making a connection from one of the backed servers
at the level of application security - so that it will be impossible to connect to the database without appropriate credentials (username, password, etc). Note this are not the same Username/password that the end user must know in order to login to the application, these are the data about the user, it has nothing to do with the user / password required to connect to the database.
The answer to your specific question is to use Java's "secret storage" features. This question may be a starting point.
The wider point is - please do not make a MySQL database directly accessible from the internet if that's what you're thinking. The security of such a solution would require specialist skills and your question suggests you don't have those skills...
If your application runs outside a local area network (and even if it runs inside the network), you probably want to put a central service layer in place - and API - to handle requests from your client applications. In this case, you still need authentication - you don't want to allow unauthenticated users to add, remove or spend your coins. Most API frameworks have out-of-the-box solutions for this.
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.
I'm not a security guy so any help on this would be greatly appreciated.
I have a large number of third-party field devices that have remote methods that can be called across xml-rpc using ssl. For each method call, a username and password must be transmitted in plain text as parameters along with any other method parameters. I have no control over the devices or their implementation.
I'm currently writing a web application that a user would log into and then have access to some number of those field devices. The user doesn't need to know what devices they are connecting to, they just need the data. As such, I need to persist the username and password for each device in a database where they can be retrieved when an rpc call needs to be made.
How do I encrypt my device service passwords so that they can be decrypted when a call needs to be made? How do I decrypt the password when a call needs to be made?
I'm using Java and Spring for the application.
Note, I am not asking how to persist the user's login password.
If I have this right, there is only one username/pswd per field device (though each is different and there are many field devices).
Build a secure proxy service with access to all device passwords. The device passwords can be stored encrypted with proxy service's public key. Your web app presents user key to proxy service which (assuming satisfied) talks to field devices on their behalf. CryptoApi or one of its wrappers should be all you need.
You don't comment on numbers, but given proxy would be stateless, it should scale ok.
We solved similar problems with this code.
You would use the password the users log into your web application with as key when encrypting the usernames and passwords for the other services.
I don't know if this question has any sense, but this is what my boss want.
I work in a company with an intranet web.
In my department we have developed an application wich connects to a Bussiness Object server and executes and prints reports. This is a regular client/server app with our own user/password manintenance to log in.
My boss want to remove our password maintenance and let the users log in using the intranet password, somehow the desktop app connect the intranet (i don't know if it has a web service, but probabilly yes), makes the log in and retrieves some kind of object the Bussiness Object can use to authenticate.
Can this be done? I know the B.O. can use LDAP authentication if its well configured, so that if i can verify the intranet password and redirect the same password to B.O. it can autenticate the user by itself.
The closest I have seen/created is to use the shared secret (ITrustedPrincipal) mechanism to authenticate the user against secEnterprise without knowing the true password of the user. The only gotcha with this log in model is that the Universe Connection needs to not use the Business Objects credentials for connecting to the database.
The alternate is LDAP can be used and is fairly easy to set up as an authentication method for logging into Business Objects and auto adding users. The only caveat is that LDAP groups need to be correctly such that the Business Objects groups that the LDAP groups associate to are set up correctly.
Probably you'll have to look to some kind of "Single Sign One" ( sso ) and see if 1) your server can handle, 2) You client can implement it.