How to prevent user from login in more than one session at the same time?

[avihai marchiano]

Hey,

i build my own login mechanism.(i use in Jboss as server)

For simplicity it work like this:
when user login i store the time he login and give him session id.
every time the user send a request he send the session id to the server and i check if the user already have session in the server (the session is object i created and not http-session).

this is only simplicity of the design.

the issue:
the client server protocol is http and not https. i am afraid that the session-id is not secured in this way.

I don't want to allow to the user to login without logout or before time expired any idea how to prevent him from doing this, or how to send the session-id secured?

Thank you

[Omar Al Kababji]

Use a filter and map its url-pattern to the same url that is used for login, and in the doFilter() method check if the user is logged in. if yes then redirect him to another page, if not then just send him back the login page.

[avihai marchiano]

I guess that the client dosnt send for each request user name + password, so how in standard web-framework the security know if this client authanticted?

thank you

[Omar Al Kababji]

Normally the servrr stores a cockie on the client that contains a unique session id that identifies that user. And this coockie is passrd to the server for each request. Then the server could check if there is a user object in the session or not. Remember that http is stateless so you will have to pass what you need to identify your session with each request.

If coockies are disabled then the programmer use a url rewriting mechanism, that should add the session id as part of each url

[avihai marchiano]

Thanks,

I know that the client must send a session id for the server for each request (due to the fact that http is stateless),

but!!!

Its not reasonable (for me) that the server will authantiate each request based on the session-id.
someone can still this session-id , which is not encrypted and used it to communicate with the server.

[Omar Al Kababji]

yes but when your user logs in, you will be checking that his username and password are correct and only then you will put an object representing that user in the session.

public void authenticateUser(){
//if username and password are correct
//   1- get the object that represent the user, usually you will be getting it from the DB
//   2- store the object in the http session, session.setAttribute("user.key", userObject);

//if username or password are incorrect
//   1- redirect to the error login page.
}

and then when you get a request it will be passing through the filter

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain){
//check if there is a userObject in the session
if(((HttpServleteRequest)request).getSession().getAttribute("user.key") != null){
   //the user is alread logged in
  chain.doFilter(request, response);
}else{
   //redirect to log in page.
}
}

even if some one puts session ids randomly he will not be logged in because there is no userObject in the session so he will still be redirected to the log in page, and he would be considered logged in only if he enters a valid username and password which will cause the addition of the userObject to the session.

[avihai marchiano]

I think you didnt understad me.
Lest talk on general login security and not about my case.

My question - how does the server know that this user login and dont need to login again?
If i understand you - you said he know this based on get the user session-id and check that this session-id exists on the server.

Suppose user AAA login and get session-id (555) as i understand you from now on this cureent sesssion the server will authanticate the user based on the session-id.

Now, hacker can send randomally session-id to the server or since the ession-id send in none secured transport steal the session-id and claim that he is user AAA that continue the session.

Thank you very much.

[Omar Al Kababji]

No,

username = AAA
session-id = 555

first time he comes to your web site he gets the login page so he enters:
username = AAA
password = XXX

your signInServlet will check username & password and if correct

User user = new User(username, password);
session.setAttribute("user.key",user);    

now your user opens a new page and the filters doFilter method is called

User user = (User)session.getAttribute("user.key");
if(user !=null) //logged in    

now there is no use of the session-id in determining wether the user is logged in or not. the session id is only used to obtain the session object. and this is assigned to the client from the server so the client can't decide his own session-id. servlets generate a session-id token which consists of 128 hashed bits and must be unpredictable, pay attention on (be unpredictable) and this is the job of the servlet container to provide a secured mechanism for that. but if you or someone else could hijack those session-ids and be able to generate valid session-id's then you are cracking the web application and sure you will be considered a valid logged in user. and for these reason most of applications that need high security mechanisms they use certificates and SSL.

there are some papers on session-id hijacking on the web here is one session-id hijacking

[avihai marchiano]

Thanks a lot, so the bottom line - if i stole the session-id , by listen to the communication i can stale the session.
Its not help that the password was encrypted, becuase it not used any more.

Thanks a lot.

[Omar Al Kababji]

exactly in addition since you are listening to the communication you can know what pages the user is looking at with no need to the session-id ;)

[salvin francis]

I have implemented a totally different solution for this:

I maintained a database table. when a user logs in, an entry is made in the database as userId is logged in at xyz time.
now if any other user attempts to login, a query is first executed to check the logged in database. if user exists in table,
the respective error is shown ( i also maintained the machine ip)


Problems that you may face with this approach:
you are maintaining a lock (that too in persistant storage) its your eternal duty to properly release the lock at some time.
else a user wont be able to login for ever.
as far as concurrency is concerned, the database is usually the best at doing so.

Test cases you need to consider @ releasing the lock:
1. User browser close (trigger session close)
2. User browser crash / connection break (trigger session timeout)

[Omar Al Kababji]

I will give you only one big problem, proxies, normally a huge amount of computer are connected to internet using a proxy so in the case of your application if there are 100 users behind this proxy they will be considered as one person, so if one logs to his account, you will be entering a new record in your DB table holding an IP and sadly that IP will be the IP of the proxy. then if someone else behind the same proxy tries to login he will be either two possibilities:

1) he will be allowed to access your application since he will be having the same IP address of the previous user, since they are behind the same proxy.
2) he will not be able to log at all, until the other person logs out.

i think what will be happening in your case is point (1).

[salvin francis]

Try to download multiple files from rapidshare using a proxy and see wht happens....
there are ways to detect proxies.

[salvin francis]

Try to download multiple files from rapidshare using a proxy and see wht happens....
There are ways to detect proxies. Infact no matter wht you try, some sites are able to detect your actual ip.

[Omar Al Kababji]

ok but you are inside an internal network and you have an ip address lets say 168.192.0.40 and your proxy has an external ip address 23.25.27.88 now whats the ip of your machine ?? is it 168.192.0.40 ? in this case there would be 1000 person in the world that have the same ip address.

in the end you have a 24bit address and these ip addresses are not sufficient to address each individual device in the planet, so you can't rely on ip addresses to manage sessions.