46

A service I use has a time limit (seemingly fairly short - 10-20 seconds maybe) on entering credentials at the login webpage. Attempting to login after this period gives the below message: login error message

[For security reasons, users are required to enter their credentials within a given period. This period has been exceeded. We’d like to ask you to log in again.]

The page then refreshes and I can log in without issue.

What security concerns might this service be trying to address by requiring the login within a 'given period'?

Improve this question
9
  • 36
    "we do this for ..... reasons ..."
    – schroeder ♦
    Jun 19, 2017 at 12:18
  • 11
    It's a stupid decision to implement such a thing because in many situations there may be delays in traffic due to providers, poor connections, deep inspection firewall or other reasons and that login will not work.
    – Overmind
    Jun 19, 2017 at 12:21
  • 11
    @Overmind if you have 10-20s latency, you have other problems
    – schroeder ♦
    Jun 19, 2017 at 12:29
  • 49
    They clearly expect you, or are even forcing you, to use a password manager or other device that auto-fills the username and password. Giving people 20 seconds to enter username and password is literally an ADA violation as a person in need of an assistive device would have no chance of success.
    – Harper - Reinstate Monica
    Jun 19, 2017 at 17:39
  • 9
    @Harper ADA considerations are a perfect metric for security UX and it's a shame infosec pros do not take that into account more often. Thanks for bringing this to the fore (I hadn't considered it!)
    – schroeder ♦
    Jun 20, 2017 at 6:30

5 Answers 5

Reset to default
44

This seems like a solution geared toward backend session management.

I'm speculating anonymous users don't initiate any sort of session, but a session gets instantiated once you hit the login page. When you log in, it gets noted in your session and you get to use their site and services. If you don't log in within a certain time, they go ahead and terminate your session.

Given the market within which they operate (security) I could see them being a target for DDoSing via resource consumption so this would be more of a resource management solution than anything (prevents the number of open sessions from exceeding a certain threshold).

So it's security for their infrastructure, not any sort of security for your account.

Improve this answer
6
  • 27
    If so, I wonder what is stopping them from deferring session creation until after the credentials have been checked?
    – meriton
    Jun 19, 2017 at 22:55
  • 4
    A better solution would be to encrypt the session in the cookies for anonymous users, since they shouldn't have any privileges that causes problems if duplicated or inconsistent.
    – user23013
    Jun 20, 2017 at 6:38
  • 4
    @meriton I agree, it doesn't make any sense to me either, but I don't put anything past web developers. Even doing things this way doesn't fully mitigate a resource exhaustion attack.
    – Ivan
    Jun 20, 2017 at 14:35
  • 1
    If their infrastructure goes down, you cannot access your account - so it is security for you.
    – OrangeDog
    Jun 20, 2017 at 15:49
  • 2
    @meriton Good Practice also dictates that you create a new session after successful authentication to protect against session pinning attacks (force the victim to enter an attacker provided session, e.g. by forging cookies, so that the user authenticates into a session the attacker can hijack, through the use of said cookies).
    – BlueCacti
    Jun 21, 2017 at 11:13
16

It could be that they are have issued a verification token of sorts to the form that they postback to the server as part of the login, which times out after a period of time. Not saying whether its a good solution or not, just that it may be the reason.

OWASP have this information: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Initial_Login_Timeout

Improve this answer
5

Yes, the login timeout is a mitigation against the following attack known as a session fixation attack:

  1. Malicious user has his own PandaCloud account containing a series of fake files.

  2. Malicious user accesses a public computer, e.g. in a library, university, or coffee shop, and signs on.

  3. Malicious makes a copy of his session cookies.

  4. Malicious user navigates back to the PandaCloud signon page but does not sign on.

  5. The PandaCloud page, when loading, drops all cookies in order to reset the browser to a clean state.

  6. Malicious user replaces his cookies in the browser's cookie store.

  7. Malicious user leaves the desk and goes to a corner to watch.

  8. Naive user comes along and signs on. The script that clears existing cookies already ran in step 5, and does not run again, so the malicious user's cookies are submitted to the PandaCloud.

  9. Naive user thinks he is accessing his own account, but is in fact accessing the malicious user's.

  10. Naive user uploads confidential files, then signs out.

  11. Malicious user signs on and downloads the confidential files.

The purpose of the time limit is to reduce the exposure that occurs between steps 5 and 8. If it is short enough, it is more or less impossible to pull off this attack.

There are much better ways to deal with it, though, such as using more than one cookie and storing some of the user information server side. Perhaps these other methods were infeasible due to other technical constraints.

Improve this answer
9
  • 1
    If you are downvoting, please provide a comment that might improve the answer.
    – John Wu
    Jun 20, 2017 at 1:28
  • 6
    "Naive user comes along and signs on" - the server should respond to the login with new cookies linked to the credentials of the naive users. That or I misunderstood the steps. No, I didn't downvote.
    – Theraot
    Jun 20, 2017 at 2:11
  • 1
    I see. I believe the naive approach to fix this is to not present login form if the browser presents valid cookies. Although that could also be circumvented: 3.5. Malicius user removes the cookies from the browser.
    – Theraot
    Jun 20, 2017 at 2:28
  • 3
    So the main point for this attack to work is that the naive user has to use a login page that the malicious user left open? In that case there are way easier and better attacks which can't be prevented by the time limit and don't require the server has to handle cookies in a questionable way. For example: malicious user logs in and simply displays a fake login page that the naive user uses. (copy&paste HTML of real login, add a line of JS to hide fake login when hitting enter/clicking ok - probably takes just as long as replacing cookies).
    – kapex
    Jun 20, 2017 at 9:14
  • 6
    @JohnWu, this is an extremely convoluted scenario that requires an improbable error on the part of the website developer, followed by extreme cluelessness on the part of the user. Almost every website developer uses step (8b) instead: "replace existing session cookies with new session cookies". It's simpler, more foolproof, and meshes naturally with how browsers handle cookies. Your step (8) requires the website developer to intentionally subvert the normal cookie-handling process. Your step (9) requires the user to completely ignore any errors like "hey, where'd my files go?".
    – Mark
    Jun 20, 2017 at 18:30
3

Given the information we have to base this on, I like a lot of the speculations already given. Some better than others. So given all the speculation we seem to be entitled to, let me throw in another really really edge case scenario:

Protecting the easily distracted user

User types in credentials but has yet to hit the submit button. Gets distracted, called away, decides to start browsing a different page because of a social media notification or whatever else. Basically they filled in all their credentials but didn't submit.

Then they leave their machine: public machine, library, laptop in a coffee shop during a bathroom break (hey, I've seen people leave their cars running while going into a convenience store... it can happen!)

The potential attacker can gain access to the machine and submit the form, but with the short timeout, their session will be expired. Of course, instead of submitting, there are probably more interesting ways to recover a password from a ****** field so that it can then be properly reused for access. But that's a different security issue.

Improve this answer
2
  • 3
    It's worth noting that if the user logs in and leaves their session unattended, the server can log them out on timeout. If the user leaves their credentials, those are exposed practically indefinitely, and in a much more readable way.
    – Dmitry Grigoryev
    Jun 20, 2017 at 14:07
  • true! That's always a good practice for any site containing sensitive information. This one was specifically about timing out the login page even before the user logs in, which seems like overkill, but I guess it can have its uses.
    – subdigit
    Jun 20, 2017 at 14:31
2

The following may be a reason:

1) You provide user name and credentials and something cause you to leave the computer before you press on the submit button

2) An attacker access to your computer and press on submit button. Finally, the attacker can use your applications.

For example, Keycloak OpenIDConnect provider limits the login process time.

Improve this answer
7
  • 12
    how is this different from leaving the computer once you're logged in? how does the timer add value to the login screen?
    – schroeder ♦
    Jun 19, 2017 at 12:28
  • 2
    I have seen similar implementations on webpages that are used by internal staff (for example a travel agents), the reason it was implemented was to stop the situation as described, where the username and password have been typed but the user didn't press submit and walks away from desk. In an open office with the public (customers) in range this was deemed a suitable control. The web application also timed out logged in users after a slightly longer period of time, from memory I think it was 3 minutes of inactive use.
    – ISMSDEV
    Jun 19, 2017 at 15:21
  • 7
    2) The attacker inspects the password field with the browser dev tools.
    – xehpuk
    Jun 19, 2017 at 16:38
  • @xehpuk Only if they know this system is in place. If they were unaware of it, they would simply just try to hit login, thus clearing the password input box.
    – GrumpyCrouton
    Jun 20, 2017 at 20:39
  • @GrumpyCrouton Assuming a potential attacker is stupid is not a great idea while implementing security measures. The attack vector exists either way, independent of this system.
    – xehpuk
    Jun 20, 2017 at 21:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .