Anonymous_User Absent Member.
Absent Member.
1043 views

Self-service unlock

Is there any way for SSPR to support the ability for end-users to unlock
their account if they've locked it via an intruder lock detection? I
know that if linked to NMAS an intruder lock will lock both the password
and challenge-response authentication methods but is there some way this
can otherwise be done securely (without creating a security hole)?
Any suggestions are appreciated.
0 Likes
9 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

What kind of rules are you thinking should work? The trick with this is
that intruder detections it there to prevent brute force attempts, but
allowing the "user" (meaning, cracker trying to break in as the user) the
ability to unlock the account opens things up for brute force attempts again.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

On 6/4/2013 9:37 AM, ab wrote:
> What kind of rules are you thinking should work? The trick with this is
> that intruder detections it there to prevent brute force attempts, but
> allowing the "user" (meaning, cracker trying to break in as the user) the
> ability to unlock the account opens things up for brute force attempts again.
>
> Good luck.
>

That's part of what I'm asking. My customer would somehow like to enable
some sort of unlock self-service as that is the majority of their
helpdesk calls. increasing the number of intruder attempts is in itself
decreasing security and would be hard to sell internally. Due to the
complexity, enabling challenge-response as a source for intruder unlock
isn't seen as much of an increased security risk. However, as you know,
you can't exercise challenge-response with the account being locked by
an intruder.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Self-service unlock

Phil Cook wrote:

> increasing the number of intruder attempts is in itself decreasing security


Not necessarily much, though. Brute-force and dictionary attacks need to
perform many 1000s of attempts to be successful, so it does not really matter
if you set the limit to 10 or 50. But with 10 you might be low enough to
trigger when users accidentially have CAPS-LOCK on, with 50 chances are much
better he/she will noticy before the lock kicks in. Also low trigger counts
combined with low locking timeouts can help. Locking for 5 minutes after 10
failed attempts effectively limits brute force attacks to 120 tries/hour, which
in combination with a good PW policy can be OK. And when users know they have
to wait just 5 mins, they probably just go get another coffee istead of calling
helpdesk.

> and would be hard to sell internally.


That's another story....
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

On 06/04/2013 08:44 AM, Lothar Haeger wrote:
> Phil Cook wrote:
>
>> increasing the number of intruder attempts is in itself decreasing security

>
> Not necessarily much, though. Brute-force and dictionary attacks need to
> perform many 1000s of attempts to be successful, so it does not really matter
> if you set the limit to 10 or 50. But with 10 you might be low enough to
> trigger when users accidentially have CAPS-LOCK on, with 50 chances are much
> better he/she will noticy before the lock kicks in. Also low trigger counts
> combined with low locking timeouts can help. Locking for 5 minutes after 10
> failed attempts effectively limits brute force attacks to 120 tries/hour, which
> in combination with a good PW policy can be OK. And when users know they have
> to wait just 5 mins, they probably just go get another coffee istead of calling
> helpdesk.
>
>> and would be hard to sell internally.

>
> That's another story....


Agreed on all points. While I do not know that SSPR is your solution for
unlocking intruder-locked accounts having a short timeout may help and be
the simplest way to help as long as the intruder (whether it be a
legitimate intruder, a user with a bad memory, or a user's application or
device trying to login over and over and over to check e-mail) can take a
break long enough to actually allow the lock to be released.

Phil, you mentioned that the majority of helpdesk calls are to unlock
intruder-locked accounts, so I'd like to hijack the thread to think about
that a bit more. About how many calls is that, or maybe about how much of
the helpdesk's time (percentage-wise) is devoted to fixing this? The
reason I ask is to find out what this costs the organization.

Going down the same path, is it a random spread of users? Is there any
correlation with intruder locks and password change times? Asked another
way, are some devices storing passwords retrying with the old password
after a password change has taken place? This matters since these devices
basically make intruder detection kick you in the head since they will
retry, often regularly enough, in a way that keeps an account from
naturally unlocking, just like a persistent brute-force attacker.

Semi-simple things that you could implement include notifying users as
their intruder count starts to creep up. If their mobile phone number or
personal e-mail address is known to the organization (if not, these are
often trivial to gather, policies/laws permitting) then sending an e-mail
or SMS message may let them know that something is amiss and to take
action proactively (disable a device, stop trying the password over and
over and go straight to SSPR before locking out, or call the helpdesk to
notify of a legitimate intruder since the user is not causing it
themselves... or so they think). Using something like Log Manager could
do this in a fairly simple way, though Sentinel would be the better
solution because Correlation could be used to easily keep from spamming
the user with e-mails about intruder attempts (it's bad to DoS your
users... usually). Perhaps at at the same time also use this product to
notify the helpdesk about a potential problem (proactively call the user
to help them.... knock their socks off with service) or investigate a
legitimate problem (device/application, user, or intruder). If the user
is the problem, training, or a call to a manager, could also be pursued to
help solve the problem permanently. If a problem user's manager's budget
is charged for each excessive helpdesk ticket because the user cannot
remember their password, or cannot change passwords on various
devices/applications after being told the millionth time things may start
to change, or at least the Helpdesk budget will be nicely padded.

Other semi-simple things could include setting up a little website where
the username is entered and the password is just magically unlocked, once.
The site, perhaps via an attribute in eDirectory, would need to keep
track of the last time this happened, and probably the source IP of the
requesting party, and then only do this once in a while to avoid opening
the avenue for a simple brute-force by simply hitting this site with
usernames all day and night.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

On 6/4/2013 11:13 AM, ab wrote:
> On 06/04/2013 08:44 AM, Lothar Haeger wrote:
>> Phil Cook wrote:
>>
>>> increasing the number of intruder attempts is in itself decreasing security

>>
>> Not necessarily much, though. Brute-force and dictionary attacks need to
>> perform many 1000s of attempts to be successful, so it does not really matter
>> if you set the limit to 10 or 50. But with 10 you might be low enough to
>> trigger when users accidentially have CAPS-LOCK on, with 50 chances are much
>> better he/she will noticy before the lock kicks in. Also low trigger counts
>> combined with low locking timeouts can help. Locking for 5 minutes after 10
>> failed attempts effectively limits brute force attacks to 120 tries/hour, which
>> in combination with a good PW policy can be OK. And when users know they have
>> to wait just 5 mins, they probably just go get another coffee istead of calling
>> helpdesk.
>>
>>> and would be hard to sell internally.

>>
>> That's another story....

>
> Agreed on all points. While I do not know that SSPR is your solution for
> unlocking intruder-locked accounts having a short timeout may help and be
> the simplest way to help as long as the intruder (whether it be a
> legitimate intruder, a user with a bad memory, or a user's application or
> device trying to login over and over and over to check e-mail) can take a
> break long enough to actually allow the lock to be released.

I've told them the same thing, along with increasing the number of
attempts before locking - There's a resistance to change what's already
established (lockout settings).
>
> Phil, you mentioned that the majority of helpdesk calls are to unlock
> intruder-locked accounts, so I'd like to hijack the thread to think about
> that a bit more. About how many calls is that, or maybe about how much of
> the helpdesk's time (percentage-wise) is devoted to fixing this? The
> reason I ask is to find out what this costs the organization.

I've been told by the customer that it's nearly 50% of the calls are due
to locked accounts. They're not willing to do a cost analysis on this.
>
> Going down the same path, is it a random spread of users? Is there any
> correlation with intruder locks and password change times? Asked another
> way, are some devices storing passwords retrying with the old password
> after a password change has taken place? This matters since these devices
> basically make intruder detection kick you in the head since they will
> retry, often regularly enough, in a way that keeps an account from
> naturally unlocking, just like a persistent brute-force attacker.
>
> Semi-simple things that you could implement include notifying users as
> their intruder count starts to creep up. If their mobile phone number or
> personal e-mail address is known to the organization (if not, these are
> often trivial to gather, policies/laws permitting) then sending an e-mail
> or SMS message may let them know that something is amiss and to take
> action proactively (disable a device, stop trying the password over and
> over and go straight to SSPR before locking out, or call the helpdesk to
> notify of a legitimate intruder since the user is not causing it
> themselves... or so they think). Using something like Log Manager could
> do this in a fairly simple way, though Sentinel would be the better
> solution because Correlation could be used to easily keep from spamming
> the user with e-mails about intruder attempts (it's bad to DoS your
> users... usually). Perhaps at at the same time also use this product to
> notify the helpdesk about a potential problem (proactively call the user
> to help them.... knock their socks off with service) or investigate a
> legitimate problem (device/application, user, or intruder). If the user
> is the problem, training, or a call to a manager, could also be pursued to
> help solve the problem permanently. If a problem user's manager's budget
> is charged for each excessive helpdesk ticket because the user cannot
> remember their password, or cannot change passwords on various
> devices/applications after being told the millionth time things may start
> to change, or at least the Helpdesk budget will be nicely padded.

Good thoughts, thanks. But unfortunately the customer is looking for a
cheap/simple solution to this and much of the above is neither. I've
brought up some of this to them and they've balked at most of it as
being too invasive, complex, or expensive.
>
> Other semi-simple things could include setting up a little website where
> the username is entered and the password is just magically unlocked, once.
> The site, perhaps via an attribute in eDirectory, would need to keep
> track of the last time this happened, and probably the source IP of the
> requesting party, and then only do this once in a while to avoid opening
> the avenue for a simple brute-force by simply hitting this site with
> usernames all day and night.

Yea, I was hoping SSPR might help to do or enable some of this without
having to build it from scratch.
>
> Good luck.
>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

On 6/4/2013 10:44 AM, Lothar Haeger wrote:
> Phil Cook wrote:
>
>> increasing the number of intruder attempts is in itself decreasing security

>
> Not necessarily much, though. Brute-force and dictionary attacks need to
> perform many 1000s of attempts to be successful, so it does not really matter
> if you set the limit to 10 or 50. But with 10 you might be low enough to
> trigger when users accidentially have CAPS-LOCK on, with 50 chances are much
> better he/she will noticy before the lock kicks in. Also low trigger counts
> combined with low locking timeouts can help. Locking for 5 minutes after 10
> failed attempts effectively limits brute force attacks to 120 tries/hour, which
> in combination with a good PW policy can be OK. And when users know they have
> to wait just 5 mins, they probably just go get another coffee istead of calling
> helpdesk.
>
>> and would be hard to sell internally.

>
> That's another story....
>

Yea, I've argued that same point with various customers but typically
the infosec people argue just the opposite despite proven stats. I'd be
happy(er) to get most at 10 as many are between 3-6 now (and they wonder
why they have so many help desk calls to unlock accounts!). Rather than
banging my head on that wall I'm hoping to find some way to securely
enable a self-unlock. I've found it's easier to implement something new
than to change what's already established.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

On 6/4/2013 8:45 AM, Phil Cook wrote:
> Is there any way for SSPR to support the ability for end-users to unlock
> their account if they've locked it via an intruder lock detection? I
> know that if linked to NMAS an intruder lock will lock both the password
> and challenge-response authentication methods but is there some way this
> can otherwise be done securely (without creating a security hole)?
> Any suggestions are appreciated.

To narrow the question a bit more; The native challenge-response
mechanism is also disabled if intruder lock is set. Can SSPR's
challenge-response be independent from the intruder lock flag in eDir so
that it has its own flag? If so would this allow a user to answer their
challenge questions to reset their password, triggering an event which
could be used to unlock their account?
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

> To narrow the question a bit more; The native challenge-response mechanism
> is also disabled if intruder lock is set. Can SSPR's challenge-response be
> independent from the intruder lock flag in eDir so that it has its own
> flag? If so would this allow a user to answer their challenge questions to
> reset their password, triggering an event which could be used to unlock
> their account?


Actually, yes. SSPR can be configured to handle the challenge/response
policy on its own without using NMAS/eDirectory. I believe it then uses
an administrative proxy user to reset the user's password which may (have
not tested) also reset the intruder attributes.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Self-service unlock

On 6/4/2013 2:46 PM, ab wrote:
>> To narrow the question a bit more; The native challenge-response mechanism
>> is also disabled if intruder lock is set. Can SSPR's challenge-response be
>> independent from the intruder lock flag in eDir so that it has its own
>> flag? If so would this allow a user to answer their challenge questions to
>> reset their password, triggering an event which could be used to unlock
>> their account?

>
> Actually, yes. SSPR can be configured to handle the challenge/response
> policy on its own without using NMAS/eDirectory. I believe it then uses
> an administrative proxy user to reset the user's password which may (have
> not tested) also reset the intruder attributes.
>
> Good luck.
>

Yea, that's mostly what I was thinking. I'll give that a shot, thanks.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.