1

Logging into our app takes 15 - 20 seconds, depending on how much the user has access to. Some of this time is purposeful - the login endpoint itself has a minimum time to response of 2 seconds to prevent automated password hacking/guessing, our password encryption uses a very robust algorithm with a very high cost, and the rest of the time is just gathering information from the API to build the app. Once the user is logged in, the app is very responsive.

So, what's the maximum acceptable time a login should take from the time the user hit's the "Login" button to the app being ready to use?

Improve this question
6
  • How often do they have to login? If they do it once and then remain connected for ever, it doesn’t matter much. If on the other hand they need to login again every few hours (or even just every day), that’s probably way too long. How long does it take to load your page if already connected?
    – jcaron
    Commented Jan 26, 2020 at 14:07
  • The sessions are invalidated after 2 weeks of inactivity. If there is already a valid session, the page loads in 5 - 10 seconds.
    – richard
    Commented Jan 27, 2020 at 2:28
  • 1
    Could you split things into two screens? Part of the time is the actual authentication. The other part of the time is loading the app. So when they click sign in, show the loading icon. Then when auth is complete (successfully), then show a checkmark, or a confirmation, or something. Then say something like "redirecting", or "building homepage", or "initializing", etc. You have multiple steps, and you can use animations and things to keep the user interested. The key is progress/change every couple seconds.
    – Kelderic
    Commented Jan 29, 2020 at 14:06
  • @AndyMercer Yes we are basically doing that. Lot's of user feedback. I'm just looking for login time specifically.
    – richard
    Commented Jan 31, 2020 at 9:16
  • If load time when already logged in is 5 to 10 seconds, thay suggests a bunch of stuff to optimize apart from logging in. It's quite a long time by modern standards.
    – Luke Sawczak
    Commented Jan 30, 2022 at 13:14

2 Answers 2

Reset to default
1

Anything longer than a few seconds will make the user lose it's focus. But there is not necessarily a maximum acceptable time for login. There are a number of factors that determine wether the user will drop the login if the duration is too long.

Is there a system feedback ? Is the app login in slow because the app is massive and it needs to do some operations ? Does it look like that app is hanging and it looks like nothing is happening ?

Surely it is better to improve performance as much as possible to shorten load times but this is not always possible and so the last resort would be to make the waiting time more "fun" or explanatory. Take for example Discord. While loading you would see all kinds of fun messages: "Creating additional pylons"

enter image description here

Improve this answer
1
  • We have feedback and the app shows it's building as it authenticates and loads.
    – richard
    Commented Jan 31, 2020 at 9:17
-1

I would say that a login should feel instantaneous. That's not to say it will be instantaneous but rather the UI animations and state should hide any delays and make the user feel as if it were.

I can see several improvements you could make to your login system:

There are better ways to prevent automated password guessing such as exponential delays on requests. The user gets the password wrong twice and they have to wait 10 seconds to try again. They get it wrong again and now have to wait 20 seconds etc. This removes any hindrance to actual users but makes brute force attacks impossible as it takes longer each guess so if you don't get it in the first few tries its pointless.

Why bother with a robust but slow encryption algorithm when the user is likely to use an insecure password in the first place? Use an industry standard tried and tested algorithm that is quick to compute and combine it with two-factor authentication of some sort for added security. This will always be more secure than a password alone as even if someone manages to guess the password they still need to get past the second factor of authentication which requires access to a users physical 2FA device.

The data in the app itself should be lazy loaded when required. Your app UI should be loaded and cached so it is always available to the user and then any data can be fetched asynchronously while presenting a loading bar or spinner to the user. Only load the data required for the current page as the user may not need all of the data and you would waste bandwidth and server processing time. If it takes while to load the data for the app then making the user feel like they have logged in by showing them placeholder UI will improve the feel of responsiveness in your app.

Improve this answer
2
  • Hi James, Thanks for the answer. Don't really want to get into a discussion about the merits of the security - it's robust and correctly architected. Your suggestion of exponential delays is good but doesn't work for cases where they have tables of accounts and are trying them in rotation, so no two guesses with the same email address are one right after the other. Just because some users don't use secure passwords, it's not a good reason to forgo good security. And we are using an industry standard algorithm (just with a higher than normal cost factor). We are lazy loading. Thanks.
    – richard
    Commented Jan 29, 2020 at 10:24
  • How does your delay help against lookup tables? I can just spool up multiple instances and try multiple passwords in parallel with all of those instances waiting two seconds for the response. Using a faster password encryption is not forgoing good security. An algorithm which is widely used and quick to compute when used with two factor authentication is much stronger than your hard to compute algorithm alone. Even basic 2FA will protect against brute force attacks. All you seem to be doing is delaying how long it takes to confirm if an attack worked.
    – James Coyle
    Commented Jan 29, 2020 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.