Play framework security issue regarding cookies and sessions

Question

For my app I\'m implementing the same security as shown in the zentask.

public class Secured extends Authenticator {

@Override
public String getUsername(Context         


        

Answer 1

Putting simply the user ID in a cookie is not security at all. As you point out, anyone could invent a cookie value.

Sessions: Instead you need to put an arbitrary (e.g. random) value in the cookie, and then on the server look up the identity of the user in a mapping table. That arbitrary value has to change frequently, so you typically have a login session lasting, say, 30 minutes. Each login provides a new arbitrary value, and that value is known as the session ID.

Invalidation: Sessions are invalidated by removing that entry from the lookup table (on the server side) after a period of time without any requests (e.g. 30 minutes). Any request with a session id that is not in the table, is treated like an unauthenticated request, and you prompt for login again. It does not matter if the user forgets to log out.

Hacking: Because the value is arbitrary, there is no way for a hacker to know in advance what the future session id will be. You are still vulnerable to session stealing, but it is much harder: the hacker has to find a session ID only at the time it is being used, and then can use it only for a certain time. You can take some steps to prevent this, such as only allowing requests for a particular session to come from a particular IP address. You can also cycle session IDs quickly, even every request, but there are negative sides of that. In general, providing a unique session ID for every log in, particularly when this is done over HTTPS, is good enough for most authentication needs.

Persistence: If the number of concurrent users is small over any given session period (e.g. 30 minutes) then you don't necessarily need to put this in a database. Maintaining this in memory is low overhead, but has the disadvantage that if you cycle the server, all the users need to log in again. If you do put the session ID in a database, you need to be sure that when the server starts up it can clean out all the old sessions.

User Info: There still is a value to putting the user's email address in a cookie, but only for use as the "default" user id to log in as. This should be treated only as a convenience to the user, and not as an indication that the user is authenticated.