In web development we have usually seen we use session or cookies to maintain username, and it remains there unless we destroy it or server removes it, i am making an android application, i have a login and a password, what i want is to just, if i get logged in, it should save my username in something similar to session or cookie, and if i move anywhere among intents or screens, it should not be destroyed and i must be able to access it any where. What's the best approach to implement it?
store your username & password or session id in SharedPreferences on success
It depends how permanently persisted you want to store the information. If you need it to be remembered after the app is closed you'll need a persitant store but you should ensure that the password is encrypted.
If it's only for the running life of the app you could hold the information in static properties on a class.
The best way is to store in in SharedPrefences. See this tutorial. Also use MD5 or SHA algorithm for encrypting. See this
Related
I'm using OpenID. How do I make it so that the user stays logged in for a long time even after closing the browser window?
How do I store and get access to the user's User object?
Basically, I guess I just don't really understand how sessions work in Java.
So you actually want like a "Remember me on this computer" option? This is actually unrelated to OpenID part. Here's a language-agnostic way how you can do it:
First create a DB table with at least cookie_id and user_id columns. If necessary also add a cookie_ttl and ip_lock. The column names speaks for itself I guess.
On first-time login (if necessary only with the "Remember me" option checked), generate a long, unique, hard-to-guess key (which is in no way related to the user) which represents the cookie_id and store this in the DB along with the user_id. Store the cookie_id as cookie value of a cookie with known cookie name, e.g. remember. Give the cookie a long lifetime, e.g. one year.
On every request, check if the user is logged in. If not, then check the cookie value cookie_id associated with the cookie name remember. If it is there and it is valid according the DB, then automagically login the user associated with the user_id and postpone the cookie age again and if any, also the cookie_ttl in DB.
In Java/JSP/Servlet terms, make use of HttpServletResponse#addCookie() to add a cookie and HttpServletRequest#getCookies() to get cookies. You can do all the first-time checking in a Filter which listens on the desired recources, e.g. /* or maybe a bit more restricted.
With regard to sessions, you don't need it here. It has a shorter lifetime than you need. Only use it to put the logged-in user or the "found" user when it has a valid remember cookie. This way the Filter can just check its presence in the session and then don't need to check the cookies everytime.
It's after all fairly straight forward. Good luck.
See also:
How to implement "Stay Logged In" when user login in to the web application
How do servlets work? Instantiation, sessions, shared variables and multithreading
Well, the original reason I chose OpenID was so someone else could handle as much of the implementation and security of authentication for me.
After looking into OpenID more, it appears there is something called an "Immediate Request" (http://openid.net/specs/openid-authentication-2_0.html#anchor28).
When requesting authentication, the Relying Party MAY request that the OP not interact with the end user. In this case the OP MUST respond immediately with either an assertion that authentication is successful, or a response indicating that the request cannot be completed without further user interaction.
Because of this I think I could just store the user's openID url in the cookie, and use an immediate request to see if the user is authenticated or not. This way I don't have to do anything with my database, or implement any logic for preventing session hijacking of the long-lived cookie.
This method of doing it seems to be the way OpenID suggests to do it with their Relying Party Best Practices document.
I am trying to figure out where or how i should store application secrets and keys inside a desktop application.
For example a facebook app key or dropbox key and secret.
So I've read that i should hash, salt, encrypt etc etc these values. This is to prevent someone from reverse engineering my code and seeing the keys.
The is all good and well, but with all these methods, i'm just storing a salt or hash value somewhere instead of the key itself, in the end. Surely if a hacker can get to the salt/hash and possibly the source code, they will be able to decrypt the encrypted key and get my password/key/secret anyway?
One option I've read about that seems the most secure is to not store this value in the desktop app at all, but to call a web service to obtain the key (probably encrypted).
But my question is, even in this case, a decent hacker will surely just do a memory dump or something to see what the value returned from the web service is, and then we're back at square 1.
The next best alternative seems to be obscurity.
Am I missing something completely?
On a side note, what use will a facebook/twitter/dropbox/etc key/secret be to a hacker anyway?
Surely they would still need a user's credentials or access token to be able to use it anyway?
Any advice or suggestions will be appreciated.
For each user account generate a new access token for the application when they successfully log into your service. Your login service should be designed much like a login for a website:
The API should only allow a set number (say 5) bad login attempts that reports back to the desktop client that the username/password do not match.
The API should return a token affiliated with only that user when the user successfully logs in.
Use SSL and a localized hashing method to pass user passwords to your API
This auth token provided by your API will only work for the individual account and as such should only allow the user to perform operations to their individual account. So for instance, if a user wants to perform an operation they must be able to provide a valid auth token in order to complete the action. Using this method attackers will still be able to obtain an auth key, but that auth key will only be able to perform operations for the account in which it is generated. It will not be able to perform operations on anyone else account. The idea here is to let them mess with data but to keep the bad activity compartmentalized to one account.
From there, if you do have generic API calls (say an image search) that accesses data from multiple accounts make sure that you are never returning or allowing for any account to access all the data in your system outright. Provide only a limited number of records. In this case the system is still performing its job, but at no point allows all the records in your system to be accessed.
I typically implement a service like this:
User logs in and gets an auth token. I store said auth token in a database associated with that user.
User calls web service with auth token. I lookup user account by the transmitted auth token and User ID (two forms of authentication) and use the discovered user account to perform all operations. I don't just assume the User ID is correct, it has to be the one the auth token authenticated against.
If a user needs to perform a delicate operation like reset a password, my app opens a browser window or browser task in the app where the user can request and administer a reset. I can more-easily secure a web application than one on an unknown client.
Using these methods you should be able to make a fully operational desktop application. There are outliers to this functionality, if you have any post them up in the comments and we can dive further into the problem and see if this solution can still work for you.
I am using JBoss server. I have one problem with session. After logged in to the page again I restarted server. But user session is getting logged out. Again It redirects to login page. I need to allow user to see the webpage without logout.
After restarting the server, your login session information is lost. You need to persist it to avoid this.
https://community.jboss.org/wiki/HAWebSessionsViaDatabasePersistence looks like exactly this.
When you restart the application server, all the sessions will be terminated, that is a normal thing, because sessions are kept in the memory to put it simply.
If you want the user to continue on from his previous session, you will have to go through a lot of trouble such as re-creating the session objects and populate them with the data you somehow saved from last session, and a way to authenticate the user without the user entering his password again. That is probably the easy part which you can achieve by storing the session identifier in a cookie and keeping track of it in a database or text file, but re-creating the session itself exactly from where you left off might not be a good or even practical idea.
Two options for storing and restoring the session:
1) Save the data related to the session (items in a shopping cart for instance) in a database or a text file of some sort. (save it on the hard disk) This will prove very difficult, how difficult depending on the complexity of your site.
2) Save the users session data in a cookie along with the session identifier (jsessionid). Again you will need to do some custom work, identifying these cookies and reading them. User can always get rid of cookies, or disable them etc.
If you have a very simple web page that doesn't include any data other than the authentication, you simply want to see the previous page you were at, you can save a cookie in the client identifying the user and the page he was last at.
I store user data such as name, password and email in your HttpSession with setAttribute.
I want to know if it is safe to store critical data in HttpSession.
Try storing login information in one of the following user repositories (checking the validity while logging in):
In-memory (say, it could be an xml file),
JDBC-based,
LDAP-based.
It's not the full list of the authentication options.
You should at least use SSL/HTTPS for login and any other sensitive data.
Take a look at this article: http://en.wikipedia.org/wiki/Session_hijacking
And here is a nice SO discussion on that issue: What is the best way to prevent session hijacking?
Some security issues are also mentioned here: What should every programmer know about web development?
Ideal practice is to NEVER save passwords in any means of the application. Ideally passwords need to be saved encrypted in the DB's user table if you use db based authentication or use LDAP authentication.
After being successfully authenticated, you can keep the fields such as email and name in the http session. Its best that the username is kept (which is unique) in session and profile information has to be read from the database based on this username by performing a database read.
can keep this information in a cookie to facilitate repopulating frequent visitors with some information as well.
most important thing is to NOT save passwords in hidden variables,cookies or query strings AT ALL.
any sensitive information that MUST be kept must be in a SESSION but encrypted.
Very basic question.
I have a portal containing several servlets, one of which takes care of logging in (but only as an admin). How do I use HttpSessions between Servlets to know if the admin is signed in?
Thanks in advance!
Whenever your admin users signs in put something like session.setAttribute("admin","true");
check this as session.getAttribute("admin") to see if admin is logged in
set an attribute in session
session.setAttribute("isAdmin",true OR false);
At the login time decide the user type and set it.
I'd store the complete user object in the session.
http://download.oracle.com/javaee/1.3/api/javax/servlet/http/HttpServletRequest.html#getSession()
You can gain access to the session through this method.
If you store the whole user in the session (or the user-id from your database), you can implement a more refined, role-based access later on as your application grows.
greetings