2

I just got locked out yet again from my university's system for typing the wrong password twice, then mistyping the correct one by accident. Now I have to call the helpdesk or go there myself to reset it.

Now my question, is there really any value in doing this? I could understand a 5-15 minute lockout, but I simply do not see any value in a hard account lockdown from a security point of view. From my point of view as a user of this system, it has been nothing but trouble, frustration, and lots and lots of lost time.

If anything, this looks like a huge sign saying "lock this user's account FOR FREE!" simply by knowing their username, enabling mass denial of service with little effort. But I could be missing something.

Of course, I am obviously biased, so does anyone see an advantage in doing this? To me it looks like overzeal, and their other password policies - I will spare you the horror - really don't do a good job at making me feel good about giving them passwords, but I unfortunately have zero authority over this.

Thomas
  • 460
  • 4
  • 13
  • 2
    You're underestimating the reliance of academia on pointless, time-wasting bureaucratic procedures to ensure their subjects and/or peers conformity to the established culture, no matter how ridiculous it might seem. Give it a year or two, you'll come to your senses. :) One uni I've been at had a main gate with a writing _'enter if you seek knowledge'_ on the entrance side, and _'exit if you seek wisdom'_ on the exit side. You see their security is on the _'knowledge'_ side of things, and your objections are from your _'wisdom'_ side. You can't have one without the other, though. ;) – TildalWave Mar 04 '13 at 09:08
  • 1
    Related and [possibly a duplicate of "Why do sites implement locking after 3 failed password attempts?"](http://security.stackexchange.com/q/487/396) – makerofthings7 Mar 04 '13 at 21:06

3 Answers3

4

I agree - the hard account lockout can be used by malicious users to DoS (Denial of service) legitimate user accounts. Depending on the sensitivity of the user accounts a time based lockout may be more appropriate. For similar applications our company uses a time-based incrementing approach.

For example, the first time it locks out after 3 incorrect passwords it locks for 10 minutes. If it is locked again it locks for 20 minutes. The third time 40 minutes. And so on, this incrementing time makes it time consuming for automated brute force attempts and will give significant time to the sys admin / security team to identify an attack. Without the time based lockout a brute force attack would be possible in a number of minutes, and with the hard account lockout it would cause a headache for the support team.

One question would be can you easily enumerate usernames of the application. If you can then point this out to the support / development team as a malicious attacker could easily do the same and lock out every account in the system.

fixulate
  • 788
  • 4
  • 9
  • The username is a simple first name/surname mashup, and I **believe** I have access to enrolment lists for the courses I'm attending, so I think I could derive *at least* two hundred usernames without too much difficulty. And even then it would not be infeasible to hang around the library and snoop on people's username as they log on. Not sure about an external attacker, but if the system is as fragile as I fear it is, an attacker with inside information could certainly do a lot of damage. – Thomas Mar 04 '13 at 10:03
  • Does the application give you a different error message for a valid username to an invalid one. For example, entering a valid username with an invalid password gives "invalid password please retry." and an invalid username gives "did not find username in the system". Using these errors an attacker can quickly enumerate a list of valid users. – fixulate Mar 04 '13 at 10:12
  • No, it simply says "ERROR: The username and/or password you entered is not correct." in either case. – Thomas Mar 04 '13 at 10:18
  • Well thats a slight help then, but again, like you say insider knowledge or a trivial guess (lots of systems use surname firstname mashup) could easily bring this to its knees. – fixulate Mar 04 '13 at 10:20
  • As for the accounts themselves, they are not particularly valuable in and of themselves, but since you need an account to access many of the online services, a compromise could cause major disruption. – Thomas Mar 04 '13 at 11:12
  • The pain would come from someone locking all the accounts out in the system making it a nightmare for the support team to reset them. My opinion is that a hard lockout on these accounts is not required. However, an elite private banking service where customers can transfer £xmillion a hard lockout is probably a better option. – fixulate Mar 04 '13 at 11:22
  • @Thomas - of course, with a policy like this, it's probably only a matter of time before it fixes itself when some "enterprising" student decides to DoS the accounts of the school administrators. While it is probably a good way for said student to get expelled, it will also likely make administrators unhappy enough to want the policy changed. (Note, I specifically recommend you NOT be that student as it would likely not be that hard for them to track down who is responsible for the lock outs, but someone will be upset enough at the school at some point and see the easy problem.) – AJ Henderson Mar 04 '13 at 14:07
3

The Problem

Determining the threshold of your password policy is quite objective. Depending on how your authentication is setup, you can either have a low number of bad logon attempts (1-3) within a certain period of time and a higher administrative overhead or a higher number of bad logon attempts with lower administrative overhead.

Low bad logon attempts

Consider the example where a user only has 1-3 bad login attempts and they are locked out of the system. This minimizes the chance of a successful password attack and prevents almost any bruteforce attempt. This threshold provides the greatest security that you can achieve through bad logon attempts.

Only a few bad logon attempts will lock out the user and the account will be required to be unlocked before another logon attempt. This does make it easy to preform a DoS on yourself, your teacher, your boss, or your friend.

High bad logon attempts

A reasonable number of bad logon attempts over 5-10 is considered to be high. If a user needs 10 tries before they get the right password it is probably because of infrequent logons or they simply don't remember their password.

With higher bad logon attempts, there is a greater chance of success during a password attack. If the users type their password correct before the threshold, then there is no administrative overhead.

No Bad logon attempts

This is usually found when logging on a local system with no network authentication, like a home PC. In network authentication, this method is asking be subjected to a password attack.

Of course this will allow unlimited number of password attempts by anyone.

Administrative Overhead

Companies and organisations have to pay people to help with unlocking customers/employees accounts. The most common way is by using a password reset system through email. It costs money to develop, support, integrate, and maintain a system like this. However, it is quite cost effective to the other alternatives.

A help desk will help solve any problem that the email system cannot. If a user forgot the password of your site, maybe they forgot the password to their email password too!

Weaknesses

Large schools, banks, organisations can be targeted with a dictionary password attack. When there are more accounts, there is a better chance of a successful attack. And when you can attack an account many times before it is locked out, it has a greater chance of being compromised.

If the school UCLA has 40,000 students, you would expect some of the accounts may have passwords that include "UCLA", "bruins", "college", as well as weak passwords.

Conclusion

It is up to the managers, administrators, etc, to pick the password policy that fits their situation. Many things would be included in this decision and some are: cost of data loss, administrative overhead, cost of security, cost of potential down time.

ponsfonze
  • 1,332
  • 11
  • 13
0

Well, the coin has two sides.

The unlock interaction is there to have a trusted human — the help desk person — check that the person asking for unlock is really you. This can be done over the phone, by asking you some details… And this can be quick, provided that the help desk is open — here a 24/7 help desk comes in handy.

On the other hand, I hate when an account is locked for a given duration, say 15 minutes. If you really want to do something now, you cannot do anything, you cannot phone the right service, you have to wait 15 minutes. This is frustrating, and I find this more blocking.

Nicolas Barbulesco
  • 148
  • 5