Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Thanuja Jayasinghe 
Hi Farasath,

On Tue, Jun 21, 2016 at 2:57 AM, Farasath Ahamed  wrote:

> Hi Thanuja,
>
>
> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> I'm working on $subject.
>>
>> We are planning to prevent this flow from brute force attacks by
>> enabling followings,
>>
>>1. Enable captcha/reCaptcha after n failed attempts
>>2. Lock the account after n failed attempts for a period of time
>>
>> How are we going to keep track of this "period of time" after an account
> is locked?
>

We calculate unlock time as current timestamp + locked time * 60 * 1000.
After that time, a user can try to reset the password, as in a normal flow.


>
>
>> *How to track failed attempts?*
>>
>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
>> which used in the login flow to track failed login attempts. Since this is
>> a different flow, using the same claim to track the failed password
>> reset attempts will lead to unintended situations. (Ex: After n number
>> of failed attempts in the login flow, a user may try to reset the password.
>> In this case, the user will see captcha if the number of failed attempts
>> reached to the maximum. But since this is the first time which the user
>> tries to reset the password, captcha is redundant.)
>>
>> So we will introduce a new claim call "
>> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
>> this.
>>
>>
>> *Implementation*
>>
>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>> connector will introduce to handle this. The configuration of the connector
>> UI will allow modifying connector according to the requirements.
>>
>> *Lock the account after n failed attempts for a period of time *-
>> Account lock will handle from the identity recovery rest API logic. Also 
>> "PRE_SET_USER_CLAIMS"
>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>> in case of account lock.
>>
>> Appreciate your input.
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
> Thanks,
> Farasath.
>



-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Prabath Siriwardana 
This thread is also related to [Architecture][Dev][IS] Improvements in
handling incorrect login attempts [1].

[1]:
http://wso2-oxygen-tank.10903.n7.nabble.com/Dev-IS-Improvements-in-handling-incorrect-login-attempts-td138672.html

Thanks & regards,
-Prabath

On Mon, Jun 20, 2016 at 1:05 AM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>
> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://facilelogin.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Farasath Ahamed 
Hi Thanuja,


On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
> How are we going to keep track of this "period of time" after an account
is locked?


> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>
> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Thanks,
Farasath.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Malithi Edirisinghe 
Hi Thanuja,


On Mon, Jun 20, 2016 at 7:55 PM, Thanuja Jayasinghe 
wrote:

> Hi Darshana,
>
> On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
> wrote:
>
>> Hi Thanuja,
>>
>> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on $subject.
>>>
>>> We are planning to prevent this flow from brute force attacks by
>>> enabling followings,
>>>
>>>1. Enable captcha/reCaptcha after n failed attempts
>>>2. Lock the account after n failed attempts for a period of time
>>>
>>>
>>> *How to track failed attempts?*
>>>
>>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; 
>>> claim
>>> which used in the login flow to track failed login attempts. Since this is
>>> a different flow, using the same claim to track the failed password
>>> reset attempts will lead to unintended situations. (Ex: After n number
>>> of failed attempts in the login flow, a user may try to reset the password.
>>> In this case, the user will see captcha if the number of failed attempts
>>> reached to the maximum. But since this is the first time which the user
>>> tries to reset the password, captcha is redundant.)
>>>
>>> So we will introduce a new claim call "
>>> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
>>> this.
>>>
>>>
>>> *Implementation*
>>>
>>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>>> connector will introduce to handle this. The configuration of the connector
>>> UI will allow modifying connector according to the requirements.
>>>
>>
>> I assume this new connector will be much similar to "
>> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
>> depending on the "failedLoginAttempts" claim, the new connector will
>> depends on new "failedPasswordResetAttempts" claim.
>>
>
> Yes. They will share a similar design.
>
>
>>
>> *Lock the account after n failed attempts for a period of time *-
>>> Account lock will handle from the identity recovery rest API logic. Also 
>>> "PRE_SET_USER_CLAIMS"
>>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>>> in case of account lock.
>>>
>>
>> Are you referring locking the password recovery flow? What would be the
>> impact of locking the "password recovery flow" to the "login flow"?
>>
>
> Account lock from any flow (either from "password recovery flow" to the
> "login flow") will consider as an account locked situation for the user.
>

Suppose both flows ('login flow' discussed at [3] and the 'password
recovery flow'), will be sharing the same configurations with regard to
locking the account of the user and behaving similarly.


>
>
>
>>
>> Going through supported password recovery flows listed in [2],
>> > Recover with Notification : Has less risk on brute force attacks
>>
> > Recover with Secret Questions (one question at a time) : Has moderate
>> risk on brute force attacks
>> > Recover with Secret Questions (multiple questions at a time) : Has
>> higher risk on brute force attacks
>>
>
>> Considering above, it's better to have this feature enabled by default if
>> the password recovery is enabled.
>>
>
> +1 . We planning to apply these security enhancements only to 'Recover
> with Secret Questions' flows due the less risk in 'Recover with
> Notification' flow.
>
>
>> [1] "[Architecture][IS] Support for Google reCaptha"
>> [2] "Identity Management Recovery API improvements"
>>
>> Thanks,
>> Darshana
>>
>>>
>>> Appreciate your input.
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
[3] '[Architecture] [Dev][IS] Improvements in handling incorrect login
attempts'

Thanks,
Malithi.

-- 

*Malithi Edirisinghe*
Associate Technical Lead
WSO2 Inc.

Mobile : +94 (0) 718176807
malit...@wso2.com
___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Thanuja Jayasinghe 
On Mon, Jun 20, 2016 at 7:55 PM, Thanuja Jayasinghe 
wrote:

> Hi Darshana,
>
> On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
> wrote:
>
>> Hi Thanuja,
>>
>> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on $subject.
>>>
>>> We are planning to prevent this flow from brute force attacks by
>>> enabling followings,
>>>
>>>1. Enable captcha/reCaptcha after n failed attempts
>>>2. Lock the account after n failed attempts for a period of time
>>>
>>>
>>> *How to track failed attempts?*
>>>
>>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; 
>>> claim
>>> which used in the login flow to track failed login attempts. Since this is
>>> a different flow, using the same claim to track the failed password
>>> reset attempts will lead to unintended situations. (Ex: After n number
>>> of failed attempts in the login flow, a user may try to reset the password.
>>> In this case, the user will see captcha if the number of failed attempts
>>> reached to the maximum. But since this is the first time which the user
>>> tries to reset the password, captcha is redundant.)
>>>
>>> So we will introduce a new claim call "
>>> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
>>> this.
>>>
>>>
>>> *Implementation*
>>>
>>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>>> connector will introduce to handle this. The configuration of the connector
>>> UI will allow modifying connector according to the requirements.
>>>
>>
>> I assume this new connector will be much similar to "
>> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
>> depending on the "failedLoginAttempts" claim, the new connector will
>> depends on new "failedPasswordResetAttempts" claim.
>>
>
> Yes. They will share a similar design.
>
>
>>
>> *Lock the account after n failed attempts for a period of time *-
>>> Account lock will handle from the identity recovery rest API logic. Also 
>>> "PRE_SET_USER_CLAIMS"
>>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>>> in case of account lock.
>>>
>>
>> Are you referring locking the password recovery flow? What would be the
>> impact of locking the "password recovery flow" to the "login flow"?
>>
>
> Account lock from any flow (either password recovery flow or login flow)
> will consider as an account locked situation for the user.
>
>
>>
>> Going through supported password recovery flows listed in [2],
>> > Recover with Notification : Has less risk on brute force attacks
>>
> > Recover with Secret Questions (one question at a time) : Has moderate
>> risk on brute force attacks
>> > Recover with Secret Questions (multiple questions at a time) : Has
>> higher risk on brute force attacks
>>
>
>> Considering above, it's better to have this feature enabled by default if
>> the password recovery is enabled.
>>
>
> +1 . We planning to apply these security enhancements only to 'Recover
> with Secret Questions' flows due the less risk in 'Recover with
> Notification' flow.
>
>
>> [1] "[Architecture][IS] Support for Google reCaptha"
>> [2] "Identity Management Recovery API improvements"
>>
>> Thanks,
>> Darshana
>>
>>>
>>> Appreciate your input.
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>



-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Thanuja Jayasinghe 
Hi Darshana,

On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
wrote:

> Hi Thanuja,
>
> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> I'm working on $subject.
>>
>> We are planning to prevent this flow from brute force attacks by
>> enabling followings,
>>
>>1. Enable captcha/reCaptcha after n failed attempts
>>2. Lock the account after n failed attempts for a period of time
>>
>>
>> *How to track failed attempts?*
>>
>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
>> which used in the login flow to track failed login attempts. Since this is
>> a different flow, using the same claim to track the failed password
>> reset attempts will lead to unintended situations. (Ex: After n number
>> of failed attempts in the login flow, a user may try to reset the password.
>> In this case, the user will see captcha if the number of failed attempts
>> reached to the maximum. But since this is the first time which the user
>> tries to reset the password, captcha is redundant.)
>>
>> So we will introduce a new claim call "
>> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
>> this.
>>
>>
>> *Implementation*
>>
>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>> connector will introduce to handle this. The configuration of the connector
>> UI will allow modifying connector according to the requirements.
>>
>
> I assume this new connector will be much similar to "
> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
> depending on the "failedLoginAttempts" claim, the new connector will
> depends on new "failedPasswordResetAttempts" claim.
>

Yes. They will share a similar design.


>
> *Lock the account after n failed attempts for a period of time *- Account
>> lock will handle from the identity recovery rest API logic. Also 
>> "PRE_SET_USER_CLAIMS"
>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>> in case of account lock.
>>
>
> Are you referring locking the password recovery flow? What would be the
> impact of locking the "password recovery flow" to the "login flow"?
>

Account lock from any flow (either from "password recovery flow" to the
"login flow") will consider as an account locked situation for the user.


>
> Going through supported password recovery flows listed in [2],
> > Recover with Notification : Has less risk on brute force attacks
>
> Recover with Secret Questions (one question at a time) : Has moderate
> risk on brute force attacks
> > Recover with Secret Questions (multiple questions at a time) : Has
> higher risk on brute force attacks
>

> Considering above, it's better to have this feature enabled by default if
> the password recovery is enabled.
>

+1 . We planning to apply these security enhancements only to 'Recover with
Secret Questions' flows due the less risk in 'Recover with Notification'
flow.


> [1] "[Architecture][IS] Support for Google reCaptha"
> [2] "Identity Management Recovery API improvements"
>
> Thanks,
> Darshana
>
>>
>> Appreciate your input.
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Darshana Gunawardana 
Hi Thanuja,

On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>

I assume this new connector will be much similar to "
SSOLoginReCaptchaConnector" which is discussed in [1], rather than
depending on the "failedLoginAttempts" claim, the new connector will
depends on new "failedPasswordResetAttempts" claim.

*Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>

Are you referring locking the password recovery flow? What would be the
impact of locking the "password recovery flow" to the "login flow"?

Going through supported password recovery flows listed in [2],
> Recover with Notification : Has less risk on brute force attacks
> Recover with Secret Questions (one question at a time) : Has moderate
risk on brute force attacks
> Recover with Secret Questions (multiple questions at a time) : Has higher
risk on brute force attacks

Considering above, it's better to have this feature enabled by default if
the password recovery is enabled.

[1] "[Architecture][IS] Support for Google reCaptha"
[2] "Identity Management Recovery API improvements"

Thanks,
Darshana

>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; http://wso2.com

*E-mail: darsh...@wso2.com *
*Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

2016-06-20 Thread Isura Karunaratne 
Hi Thanuja,

On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
> this.
>

+1 for having a seperate claiam for tracking password reset faliled
attempts since it is different from login Attempts.

>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>

> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
Where can we define the lock time?. Is it a new configuration or same
configuration used when account lock with invalid credentials?

Thanks
Isura.

>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture