I'm wondering when login timeouts are being used, specifically when using same session (same browser session). On a number of sites I have completed recently I have added 60 minute timeouts and they seem to be causing problems, such as users are not able to fill out larger forms (like a resume submission--people don't think of copying their resume from another program or saving part way through). On one site, I have implemented a div/popup forcing the user to enter their password to continue in the current session, without having to login again.
But on other sites, such as Facebook, it seems you are never logged out as long as you are using the same browser window, even without "remembering" your password.
The main reason I usually use timeouts is to ensure the data is secure, such that another party can't sit down at the computer a few hours later and use the system as the original user.
I'm wondering how you decide when a site should time out users because of inactivity?
I'm thinking the answer would be language agnostic.
IMO, they're valid when:
security is critical (ie. banking)
the likelihood of seat-swapping is
high (ie. public terminals)
Regardless, there may be instances like your resume system, where you want people on public terminals to be able to carry out an act that may leave them inactive for longer than your desired or necessary timeout.
I suppose you just have to handle that in a smart fashion - either figure out a way they can get the data in quicker (which would be ace, spending an hour filling out a form is not fun - can they just upload a file?), or ensuring they can continue without any data loss after being prompted to log in again.
Even though 60 minutes seems like a long time to fill out a single form (perhaps the forms should be divided into multiple pages?), you can probably use SlidingExpiration to solve the problem where your users get logged out even though the browser session is alive.
I think the timeout for an auth cookie is a Security level decision. If your site is SSL secured, you would probably have minimal timeout values (user session would expire within a matter of minutes). On the other hand, for sites with non-critical security, you could set a medium timeout value.
When I sign on to online banking, for example, it asks me whether or not I am using a "public terminal": and if I say yes then it enforces stricter security, or if no then laxer.
Related
I need to do some security validation on my program, and one of the things I need to answer, related to authentication is" Verify that all authentication decisions are logged, including linear back offs and soft-locks."
Does anyone knows what linear back off and soft-locks mean?
Thank you in advance,
Thais.
I am doing my research on OWASP ASVS. Actually Linear Back-of and soft-lock are authentication controls that are used to prevent brute force attacks and also can help against DoS.
Linear Back-of can be implemented through some algorithm by blocking user/IP for a particular time and after every failed login attempt that time is increase exponentially e.g. for first failed login block for 5 minute, for second failed login block for 25 minute for 3rd 125 min and so on.
As per my understanding as I have seen in some articles and implemented in some application like Oracle WebLogic Soft lock is much easier to implement, IP Address (Which is I think is also helpful to protect against DoS and Brute force using automated tools) or user name is logged in database for every failed login attempt and when a certain threshold number of failed login attempts (e.g. 5) block IP address permanently. Once the account has been soft locked in application runtime, it does not try to validate the account credentials against the backend system, thus preventing it from being permanently locked.
ASVS Verification requirement is very much clear on this though.
"Verify that a resource governor is in place to protect against vertical (a single account tested against all possible passwords) and horizontal brute forcing (all accounts tested with the same password e.g. “Password1”). A correct credential entry should incur no delay. For example, if an attacker tries to brute force all accounts with the single password “Password1”, each incorrect attempt incurs a linear back off (say 5, 25, 125, 625 seconds) with a soft lock of say 15 minutes for that IP address before being allowed to proceed. A similar control should also be in place to protect each account, with a linear back off configurable with a soft lock against the user account of say 15 minutes before being allowed to try again, regardless of source IP address. Both these governor mechanisms should be active simultaneously to protect against diagonal and distributed attacks."
I'm creating an app where user submissions (e.g. photo) are designed to be captured via crowdsourcing. The app connects to an API using an API key, and the app then submits the data anonymously.
We want to avoid the overhead of people creating user accounts and passwords.
However, it seems to me this is vulnerable to a the problem of the key getting revealed. The result is that spammy submissions could be made much more quickly via browser/wget HTTP requests. Because the app is installed on people's devices, it would take a long time for us to be able to withdraw a key and replace it with another.
The approaches to deal with this problem I can think of are:
Hope that the key stays secret. Not ideal from a risk perspective. Using HTTPS for the API endpoint would reduce this risk, but presumably the app could still be decompiled to reveal it (not that in practice anyone would really bother)
Store a fixed username and password in the app, and submit as that. That basically seems to run the same problem - if the credentials are leaked then this has the same problem as 1.
Require a first-run fetch of a token to auto-create a username and password. However, if the key is compromised then this is no more secure. Also, this means we end up with lots of junky usernames and passwords in our database that really don't mean anything.
Not considered desirable: force users to create a username/password. However, that then means a lot of messing around with accounts, and compromises the anonymity of submissions, meaning data protection implications.
Are there standard patterns dealing with this scenario?
The first time the app runs, it could get a random token from the server, store this, and use it on all subsequent requests. The server just checks that the token is one it produced itself. After each request, block the token for 5 minutes (or make a counter so 10 requests are ok but the 11th gets blocked, depending on your use case). When a token gets misused, block it, so the user will have to deinstall/reinstall your app, or, if he made a script to emulate the app, he'd have to re-register after every few posts (plus you can limit the numer of registrations per IP or something similar).
You can assume any fixed credentials will be compromised. A good attacker can and will reverse-engineer the client. On the flip-side, a username/password combo will compromise anonymity (and nothing is stopping a spammer from creating an account).
Honestly, this is a very difficult problem. The (inelegant) solution involves something like a captcha where you provide a problem that is difficult for a bot but easy for a human to solve (for the record, I think captchas are almost useless, although there have been some less annoying alternatives).
Alternatively, sites like Facebook use sophisticated algorithms to detect spam. (This is a difficult approach so I would not recommend it unless you have the manpower to dedicate to it).
I have a web application where I want users to only be able to use it from one location (meaning a user can't actively be using the application at two locations). Currently I got this working in a very common way by only allowing 1 cookie session to be valid and removing any existing ones when a user logs in. Unfortunately I've been told that my method of only allowing 1 cookie is unacceptable because my users move around a lot to different sites and are tired of having to login every time. An easy solution would just be to allow more than 1 cookie, but I can't do this because I need to make sure a user account is not being used at two locations at the same time.
I'm wondering what is the best way to implement a system like this where a user can't be active at more than 1 location, but shouldn't necessarily have to login at every location they visit.
One possible idea I had was to allow multiple cookies to be recorded, but once a cookie becomes active (meaning I notice that session navigating the application) all of the other cookies are locked out for a certain timelimit like 15 mins. If no cookie session has been active for 15 mins then allow any cookie to login and gain dominance over the others untill it exceeds the timelimit.
Edit: It's ok for them to remain logged in after they leave a location
One way to do this is to log their last ip address and at what time that access was. On each access, you can check their last access.
If the last access is from the same ip, let them through.
If the last access is from a different ip, check how long ago that was. You can then define a cut-off point for how long they need to be idle before they can access it from another location. 15 minutes seems reasonable.
All of this can be done on the backend and this would possibly provide a higher level of security.
The browser allows users to store their credentials. Let them use this feature to log back in without hassle.
No need for a timeout. Allow multiple cookies, but only one active one.
Instruct your users to close the application when they leave their workstations. Make this something that's easy to do. Put a close button on each page or perhaps catch onBeforeUnload and notify the server that the page is no longer being displayed. Do keep the session when the user closes the application, but mark it as currently inactive.
When you get a request with a cookie that belongs to an inactive session, activate that session without complaints if the user has no other session active.
If the user still has another session active, something fishy is going on. So remove all sessions and send the user to the login screen.
(That'll teach them :) )
I'm about to implement an RESTful API to our website (based on WCF data services, but that probably does not matter).
All data offered via this API belongs to certain users of my server, so I need to make sure only those users have access to my resources. For this reason, all requests have to be performed with a login/password combination as part of the request.
What's the recommended approach for preventing brute force attacks in this scenario?
I was thinking of logging failed requests denied due to wrong credentials and ignoring requests originating from the same IP after a certain threshold of failed requests has been exceeded. Is this the standard approach, or am I a missing something important?
IP-based blocking on its own is risky due to the number of NAT gateways out there.
You might slow down (tar pit) a client if it makes too many requests quickly; that is, deliberately insert a delay of a couple of seconds before responding. Humans are unlikely to complain, but you've slowed down the bots.
I would use the same approach as I would with a web site. Keep track of the number of failed login attempts within a certain window -- say allow 3 (or 5 or 15) within some reasonable span, say 15 minutes. If the threshold is exceeded lock the account out and mark the time that the lock out occurred. You might log this event as well. After another suitable period has passed, say an hour, unlock the account (on the next login attempt). Successful logins reset the counters and last lockout time. Note that you never actually attempt a login on a locked out account, you simply return login failed.
This will effectively rate-limit any brute force attack, rendering an attack against a reasonable password very unlikely to succeed. An attacker, using my numbers above would only be able to try 3 (or 5 or 15) times per 1.25hrs. Using your logs you could detect when such an attack were possibly occurring simply by looking for multiple lockouts from the same account on the same day. Since your service is intended to be used by programs, once the program accessing the service has its credentials set properly, it will never experience a login failure unless there is an attack in progress. This would be another indication that an attack might be occurring. Once you know an attack is in process, then you can take further measures to limit access to the offending IPs or involve authorities, if appropriate, and get the attack stopped.
I've been thinking about this quite a bit lately, and I would like some feedback from this wonderful community. Is it safe to assume that a user wants to be remembered when they login? And if they are using a public computer, is it safe to assume that they are smart enough to logout before leaving?
I don't really think it's safe to assume anything about the end-user.
Plus, it's easier for a user to just close the browser rather than to log out of every website, so providing a remember me checkbox defaulted to false is user friendly and less hassle for them over-all.
No. In this age of too-little privacy, any potential hole for a breach should be closed. Sites should be getting more secure, not less.
No, it is best to assume nothing, especially something like remembering the user.
What if they are at a friend's house or on a public computer and forget to log out?
No. Never assume that your users will do things that you want them to do if you don't explicitly tell them (i.e. force them) to do so.
The "Remember me" checkbox is an excellent example of how ignorant users can be - even when the checkbox is there, the fact that users are kept logged on on public computers is a problem. It won't help if you start assuming...
Now that most browsers can remember passwords anyway, there's little point in setting a remember-me cookie as well, so you can get rid of that option. Then users can no longer complain if they clear their cookies and then wonder why your site doesn't know them from Adam...
However, do not assume the user will log out. They don't, and with tabbed browsing, your session cookie could stick around for a very long time - maybe several days if they keep using hibernate/sleep mode and only restart their browser when it crashes. Therefore you need to set a reasonable inactivity timeout and require them to log back in once it expires.
No. Don't forget the old phrase:
When you make an assumption, you make
an "ass" out of "u" and "mption".
Thought I would update this discussion for anyone who finds this from Europe, where the EU Cookie Law will come into effect May 25th 2012. The law will require all European websites to obtain informed consent from visitors before they can store or retrieve any information on a computer or any other web connected device.
As the "Remember Me" almost certainly necessitates using a cookie, you absolutely CAN NOT assume that users will want to be remembered, and in fact doing this will become illegal from May 25th unless you somehow otherwise gain consent for cookie use from your users.
There are various strategies for how sites will comply with the new law, a popular choice currently is to have a site wide cookie Opt-In prominently displayed on your site, which disables all cookie operations until the user activates them. That's a discussion for another thread though, the message here is that you can't assume if you your web site operates out of Europe.
If your website is not security-relevant (that is: You're not a bank, medical or insurance company), then I would reverse the checkbox. Make "Remember me" the default and have a checkbox "This us a public computer, do not store my password". That would be my wish as a user, as I hate "Remember me" checkboxes, also because they don't work most of the time.
Is it safe to assume that a user wants
to be remembered when they login?
I would say that yes, in 80% of the cases (total guess on my part), the person connecting to your website is not through a public computer, and they would rather not have to retype their information every
time they come to the website.
And if they are using a public
computer, is it safe to assume that
they are smart enough to logout before
leaving?
No, that's not safe to assume. And smartness isn't even the proper term - it's more a question of remembering or even being aware I would say.
So I say go the safe route. Provide a "Remember me" checkbox, and leave it unchecked by default. People are used to this scenario. It's not that big a deal and it's much less likely to cause you trouble than checking it by default, or even worse not providing it and doing it silently.
I think it should be there on non-vital sites, but never checked by default and never automatically assumed to be wanted. If people don't want to remember their logins or retype them, let the browser's password manager or whatever deal with it, not the site. Users generally don't logout - to many, just closing the browser counts.