4

I am currently working on the redesign of a login page. I have initially suggested that login be throttled whereby pauses (incremental - in number of seconds) are introduced between each failed login attempt. The idea is that this will allow us to avoid locking the account and give users time to think about reseting their password and also counter any brute force attacks.

The development team suggested that login throttling will not help in preventing brute force attacks but a temporary lockout will. the temporary lockout works in the same way except that pauses introduced are (incremental - in number of mins and hours) so i am a bit confused...below is an example of how IBM QuickFile allows login to be configured:

Temporary lockout definitions

So I have a number of questions:

A- what is the difference between login throttling and temporary lockout? aren't they the same but use different configuration parameters?

B- what are interaction design implications that i need to consider when adopting a temporary lockout mechanism? Do i have to let the user know when they will be able to try again? perhaps using some form of visual indicator.

C- what are the most adapted timeframes for pauses between failed login attempts that will not frustrate the end user? This post on StackOverflow seems to suggest seconds rather than mins

Thanks

Improve this question
6
  • 3
    Just wondering, but I think you can better ask this on security.SE than here. At least the answers will be a lot better.
    – David Mulder
    Commented Dec 3, 2014 at 13:41
  • 1
    Hi David, I am trying to reconcile the need for security with that of not frustrating the end user with needless waiting time. this will also have implications i think on messaging and interaction design so its important to get both security and usability point of views.
    – Okavango
    Commented Dec 3, 2014 at 13:57
  • All three questions should be decided purely by the security/dev team. No matter how much it may 'suck' from the user perspective, these are things that have to be decided by their security implications. True, a question may be here whether a user wishes to see when they are allowed to login and how to best show it, but security has to decide whether showing such a thing is 'save' in the first place (which it normally (though not always) is).
    – David Mulder
    Commented Dec 3, 2014 at 14:15
  • I think you are right about security having an upper hand on this but i have looked at few examples where this functionality was configurable so i am assuming that there is a point where both security and usability will be satisfied.
    – Okavango
    Commented Dec 3, 2014 at 14:23
  • 1
    Well, it depends a lot on what system you're logging into I guess and what kind of users you have. For example, for a company extranet I would make the rules a lot stricter and less communicative than for a consumer facing product. But either way, still would advice you to first ask a (couple of) question(s) on security.SE and then come with actual, focused UX questions here. But that's my 2ct, if somebody else gives a long canonical answer straight here that would be awesome too :D
    – David Mulder
    Commented Dec 3, 2014 at 14:29

1 Answer 1

Reset to default
5

I don't follow the current vendor-specific security-speak, but I can try to list some UX implications related to various security measures for login dialogs from my experience (as a user and a developer):

  • locking accounts, even temporarily (necessary against brute force password attacks) - link to the support service must be available, email notification to the user should be generated, admins have to be able to unlock the account and/or send a password reset link to the user
  • randomizing / throttling response times (necessary against username guessing e.g. "is my competitor your customer?", the authentication process waits a fraction of a second after getting the response from DB, so the total response time is randomly distributed independent of account existence) - should not impact UX at all if the total time is distributed around ~1 second, no more
  • login fails 1-2 times - no delay is expected, security measures are meaningful only after X attempts (stronger the password policy, higher the X is)
  • password strength requirements - requiring 8 characters, number+letter combo is commonplace on the internet, requiring special characters or >16 characters is oppressive
  • password expiry - not a good UX, use only if necessary (for access to extra sensitive data)
  • security questions for password recovery - very bad UX, do not improve security a bit if the attacker can find the info on social media - password reset via 1-time email link is preferable
  • 2-way password encryption - very bad security, does not improve UX a bit (sending forgotten passwords via email is no more usable than sending 1-time links to reset the password) and creates a potential for public relations cock up - please store passwords using 1-way slow hash with salt
  • OpenID or some other SSO solution - yes, use it if possible, no extra passwords for users to remember, they log in once and can use all their services without re-typing the password ever again
Improve this answer

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.