Re: Concurrent Sessions and User Feedback

[Anders Thulin <Anders.Thulin () kiconsulting se>]

Susan Olson wrote:

> My question…what is the best way to handle “feedback” for users attempting
>to access an account that is already logged-on?  Currently, users get a message
>stating that the account that they are attempting to use is already logged-on.
>I am not comfortable with this because it lends to the possible harvesting of
>valid UserIDs & Passwords by an “evil doer.”

  How much effort will that take?  Given the complexity of the user IDs
and the passwords, and a good brute-force password generator (say, the one in
John the Ripper), how many attempts will it take, on average, to get in?
Can user IDs be obtained by other means -- that is, need an attacker really
guess both, or can he concentrate on password cracking alone? Will
such attempts pass by unnoticed, or will they be detected? How quickly?
If they are detected, can any countermeasures be taken?

  Does the single-session model make users confused now?  Many calls to
user support?  If it does, making it even more confusing to ordinary user
will probably generate even more calls, and the cost for that may be
significant. (Help desk may not even have time for more calls.)

  I'm assuming that the damage that can be done if an account is cracked
is sufficiently large to make it important to avert any such threats.
(In some cases it isn't -- and if no damage can be done, security is
already as good as it need to be.)

  Personally, I'd make the user message as clear and helpful as possible,
without actually giving anything away for free. (That message needs to
be formulated with the help of user support. A call to user support
is just another type of damage to the system, either in real cost
or in decreased user support availability.)  I'd also ensure that
user IDs and passwords need to be complex enough that any brute force
attack on both would take at least two workdays, and so be detected before
any damage is done. And if it is sufficiently important (in terms of damage
costs) and at all possible, I'd request modifications to the application
(and possibly also the web site) to detect various intrusion scenarios
and take countermeasures.

>                                        Also, I have a similar issue with
>the “feedback” given to users when an account is locked out…”Your account is
>currently locked out, please contact an administrator” in that I only get this
>message when I have entered a valid User ID & Password for an account that is
>locked out – seems to facilitate harvesting as well.

  And how great a problem is that, really?

  The only way to avoid harvesting would be to have one single message for
all 'access denied' scenarions, regardless of why. ("Login failed. Either
you entered the wrong username or password, or your account has been locked,
or there are too many concurrent users or the system is down for maintenance."
or perhaps more honestly "Login failed for reasons you can't be told because
they might be used against us.")  In most cases, users can't decide what the
reason is, and so they will call their helpdesk. (As I have already said, too
many such calls, and you have a DoS attack on helpdesk on your hands instead.)

  What alternatives are there? After all, the message that the account is
locked will be produced only when both user id and password are guessed
correctly. Unless you allow very short user ids and passwords and don't
have any way to detect authentication attacks, it is not quite clear if
this is a major threat, or that this is the only reasonable way to handle it.
(Have there been any guessing attempts prior to now? If you don't know, you
have other problems to solve.)

  Security that makes things difficult for users is usually
bad security because it increases costs elsewhere. User authentication should
be the first line of defense, but never the only line. If it is the last/only
line of defense, the real problem is probably elsewhere: you can't
rely on users for that kind of effort, it should be conducted by professionals.


  This was probably more questions than answers. I hope they might
stimulate further thought. A book I found very thought-provoking
is "Authentication" by Richard E. Smith.

--
Anders Thulin   anders.thulin () kiconsulting se   040-661 50 63        
Ki Consulting AB, Box 85, SE-201 20 Malmö, Sweden


top spam and e-mail risk at the gateway.
SurfControl E-mail Filter puts the brakes on spam & viruses
and gives you the reports to prove it. See exactly how much
junk never even makes it in the door. Free 30-day trial:
http://www.securityfocus.com/SurfControl-pen-test