If an application redirects the user to the Keycloak login page, and it sits there for more than the "Login timeout" (default 5 minutes), then when the users enters a username and password, instead of a login, she is greeted by:
You took too long to login. Login process starting from beginning.
To avoid this, one can change "Realm Settings → Tokens → Login timeout" to e.g. 10000 days which is 27 years, which should ensure this never happens in reality.
But before we go ahead and effectively disable this timeout, we'd like to ask: What is the purpose of this timeout? Somebody apparently went to the trouble of implementing it, but what is it protecting against? What are the (security?) consequences of disabling it?
As far as I know, it is mostly used as an additional mechanism to avoid session fixation attacks. For instance, in a company a user goes for a coffee and leaves the computer on, and then the hacker sees the opportunity and manually sets in the Browser URL the
current login session ID (or just copies it). Now if the system is configured in a way that the session ID does not change in-between the pre and the pos login phases. Then after the victim has successfully authenticated, the hacker will be able to use, without having to insert any authentication, the session that the victim is currently on;
The higher the timeout is, the wider will be the window of opportunity for such attacks to happen. Login timeout is just another layer of protection to avoid such issues, as it is session expiration, changing the Session ID between the pre-login and pos-login phase, among others.
More formally one can read in (source).
Initial Login Timeout
This extra protection mechanism tries to force the renewal of the
session ID pre-authentication, avoiding scenarios where a previously
used (or manually set) session ID is reused by the next victim using
the same computer, for example, in session fixation attacks.
And from the OWASP.org
Session Fixation is an attack that permits an attacker to hijack a
valid user session. The attack explores a limitation in the way the
web application manages the session ID, more specifically the
vulnerable web application. When authenticating a user, it doesn’t
assign a new session ID, making it possible to use an existent session
ID. The attack consists of obtaining a valid session ID (e.g. by
connecting to the application), inducing a user to authenticate
himself with that session ID, and then hijacking the user-validated
session by the knowledge of the used session ID. The attacker has to
provide a legitimate Web application session ID and try to make the
victim’s browser use it.
A fairly good explanation on how the session fixation attacks works and how to prevent it here and here.
Now I am not a security expert, but I would say that if you have other preventing mechanisms in place such as change the session ID, you should be fine. However, on the other side of the coin, do you really need that much time to login? And is that much of an annoyance to just refresh again?
Related
I'm writing my own authentication code and I've been reading a lot about possible attacks. One attack vector is that an attacker hijacks the session and uses this information to perform malicious actions as an authenticated user. I've read that the work-around to this is to expire the session frequently or at least renew the session periodically.
This got me thinking, I can't remember the last time I signed into Facebook. I stay signed in from many devices, some of which I don't use every day (e.g. work laptop). I'm wondering, how do they have such long-lived sessions without risking session hijacking?
HTTPS. Many session hijacking attacks work by sniffing cookies "in flight". Using HTTPS greatly raises the effort required to do this successfully.
I'm looking at developing an application using the Yodlee FinApp API.
Their REST protocol requires you to login your users to their system to retrieve data. To do that, you need to send a login and password. A successful request returns you a token that is valid for 30 minutes. Before that 30 minutes elapses, you must log the user in again in order to retrieve a new token. Here's where the problem lies, in my opinion.
I could set something up wherein every time a user logs into my application, I immediately send their login info and password to Yodlee and log them in there as well. Then, I wouldn't need to store their password in my database in plain text. But what happens when 30 minutes elapses? I don't actually "know" their password, so I'm unable to get them a new token and would require them to log in again. It would be a real pain to have users constantly having to log back in every 30 minutes.
Alternatively, I could generate my own password for them when they sign up with my app and use that for my application's interaction with Yodlee. But then I have their Yodlee password stored in my database in plain text. Assuming somebody was able to gain access to my server, they'd have my application's credentials and also all user credentials, so they'd be able to mimic my application's process for logging in and gain access to user transactions. This seems like a bad idea.
What's the correct approach here? It seems like both of the avenues I'm investigating have serious downsides, but maybe I'm missing another option?
#aardvarkk- How are you planning to authenticate the user on your application?
If I understand correctly then you should be storing the user credentials in your application to validate the user and also to check if he/she is a new user or not.
When you would be having this data, you can use the same to login again on behalf of user before 30th minute & only when user will still be in session not every 30 mins.
And we would suggest you to not to store any of the user's credentials in plain texts. You could encrypt it before storing and decrypt before sending it to Yodlee.
Also, the access to your application credentials for Yodlee's production environment is IP restricted and hence only request's coming from your static IP can connect successfully to Yodlee.
[UPDATED]
For this Case:
You can call touchConversationCredentials API which extends the relative (or inactivity) timeout validity of the conversationcredentials i.e. UserSessionToken. You need to pass userSessionToken in this. And you can call this before 29th min of user session to extend his/her session for another 30 mins. But there's an absolute timeout of 120 mins, so after 120 mins of initial session creation it will expire.
First off, really try to avoid storing the user's password in plain text. That is just asking for a world of pain if anything goes wrong (e.g., if you get hacked) and can open you up to all sorts of legal trouble. Truly, don't go that way.
It would in fact be better off if you never learn their Yodlee credentials at all; you don't want to be them, you just want to interact with the system on their behalf.
REST doesn't really say that much about how systems authenticate to one another; many possibilities are available in general. All you can do is try to connect with whatever credentials you have, and if that fails, bail to the user (well, to client-side code) so that they can give you another token. REST does clearly state how a failure to authenticate should be conveyed, a 401 HTTP response, but that's all really.
I'm creating an iphone app where the user logins once (when they open the app for the first time), then will never have to login again (like how instagram does it). The app will automatically log them in the next time they open it up. However, the app makes a bunch of requests to a web server.
What is the best way for the server to issue session tokens? How long should the session tokens be valid for? How can I ensure the user never has to log in again, while still providing secure session tokens.
One approach is for the server to issue a token to the user when the user logs in for the first time, and make that token permanent. That, however, does not seem secure.
Thanks for the help!
Well, generally the session is already handled through session cookies. Unless you're planning to have third parties connect to your service, I think it's a bit overkill to do anything besides basic http authentication. I would definitely send all of your connection requests over an https connection though.
As far as persisting the session on the iPhone side, you can save the user and password in the Keychain, and then automatically retrieve and send it to the server when it requires you to log in again, without having to prompt the user to log in again. How often you want the sessions to last on the server end is really up to you.
What is the best way for the server to issue session tokens?
One way to do it is using OAuth. It is more complex than cookies but it has more features.
A token is granted to each application and can be revoked by the user from a page in the server. This token can be permanent or temporary. You can store it as plain text or inside the iPhone keychain, depending on the level of security you need. There is open free code for server and client implementations. Another benefit is that clients can log in your service using their Twitter/Facebook/... account so they don't need to register on your site.
While load testing using loadrunner all my virtual users are getting logged off from application after 30 min. Looking in detail came to know that authentication cookie is getting expired even though we have continuous activity performed by users.
Now we are trying to update the cookie explicitly after each action to prevent expiration, but not sure how server identifies that authentication cookie is expired. The cookie has only encrypted text and no explicit title mentioning expiry time.
What information in cookie should be updated in authentication cookie to prevent it from expiring?
Cookie Information:
Cookie:
.ASPXAUTH=66DD4AB74239F00D553BA9640D3AD3F284F47DEC315FD6789AE3FB8D67D2A46A4E89EDB45845C921A7557BD6B39A12EE07188D1009D581AA7AAF6743710653AE44EEF2733CC16082C595D7AE7C73D3E7E3D44BA1BAEEFEB1BF5F98B35C5F8429670FFDD5586E03BB3138C5B78945D82702BDD7C4;
path=/; HttpOnly
Tell us how you are managing session state in your script. Generally if you are cleaning all cookies and instantiating a new session for each iteration you should not run into this. If you are attempting to maintain some sort of singular session state for the entire length of your test I could see how the server would potentially kick you out after your original session technically logged out of the system (as part of a business process).
Also, do you have explicit cookies noted in your script? If so, you may want to consider commenting these statements out as LoadRunner will manage cookies automatically. As part of your burn in consider running a singular virtual user for 30 minutes to an hour to see if you experience this on a single virtual user level. It's a lot easier to fix for a single user and then projecting to load than it is to try and figure out what is happening across dozens or hundreds of users experiencing a similar issue.
From what I can gather the Server keeps track of the expiry time of the cookies, and it's also the server that updates the expiry time, meaning you as the client have no control over this.
I assume the flow is this:
The browser or LoadRunner Script will always send the cookie and the
server then verifies it's expiry time on the server side, redirecting
you to the login page if it has expired.
I've had this happen to me, and solved it by visiting a special page on the server that "updated the client session expiry time". Perhaps you have a similar situation?
I'm going to develop site accessible to anonymous and registered users. Planed security schema is similar to let's say YouTube and most of others "web 2.0" sites. Logged user will get access to more functions, more data etc. What is best approach to implement that?
I'm thinking about create simple service returning random session code to client, and adding session object to singleton application object. When user provide credential, I'll change parameter "logged" in his session object. Session token will be passed as one of parameters in every single request, and services will change their behavior if user is registered or not (i.e. there will be returned only "public" data, or restricted content only)
Is it good approach, or should I use something different?
There is nothing inherently different about GWT security, it is the same with JSP,PHP, ASP, ROR, etc..., that is web application security.
There is already a session mechanism on the server side, that generates secure random session cookies, use it. As a bonus, it handles session expiration and other things you would have to handle if you rolled your own.
You cannot trust ANYTHING the client sends you, so if you send the username or some kind of token from the client to the server (other than the user logging in), you are doing it wrong.
If your information has any value, force SSL on all connections.
Your implementation of the server calls should check the server session for the current user info, and determine if the user is authorized to perform the action. Again, your RPC information should not include any information about the user making the call, other than the session cookie that is sent automatically with the request headers. Anything you store, such as whether the user is logged in, should be in the server side session.
Of course, you need to do something on the client to present logged in and anonymous users with the proper user interface. But that is not security, only work to present a consistent interface. All the security is on the server side.