Empathy List Archives

谭翔宇

Sun, May 19, 2013 3:13 PM

Dear all:

I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID.
Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

Dear all: I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID. Is there any better way to recognize the brute force attack? Thanks. Eric Tan

NL

Nuno Loureiro

Sun, May 19, 2013 3:52 PM

You should prevent all types of brute force attacks, namely, horizontal, diagonal and vertical.

Take a look at slides 24 and 25 from the following presentation for a quick overview:
http://www.slideshare.net/nuno.loureiro/codebits-2012key

Hope it helps.

Nuno

On May 19, 2013, at 16:13 , 谭翔宇 buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID.
Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

You should prevent all types of brute force attacks, namely, horizontal, diagonal and vertical. Take a look at slides 24 and 25 from the following presentation for a quick overview: http://www.slideshare.net/nuno.loureiro/codebits-2012key Hope it helps. Nuno On May 19, 2013, at 16:13 , 谭翔宇 <buptisc_txy@yahoo.com.cn> wrote: > Dear all: > > I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID. > Is there any better way to recognize the brute force attack? Thanks. > > Eric Tan > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

PJ

Paul Johnston

Mon, May 20, 2013 8:54 AM

Hi,

A common approach is this:

Lock account after three bad login attempts - this prevents vertical
attacks (using Nuno's terminology)
User names are random numbers, with 12 digits or so - this prevents
horizonal attacks

Most financials do not use captchas as it's generally accepted that a
determined attacker can break them, either through AI software or even
mechanical turk.

If your user names are not random numbers, asking a supplemental
question servers a similar purpose. e.g. user is asked for: user name,
surname, and password. The (user name, surname) pair is treated as the
user name.

Using IP addresses at all is a minefield as sometimes many users will
come from the same IP address - think of the bank's own outgoing IP
address, and all the thousands of staff that will login to their own
account at lunchtime. It does have a place, but a determined attacker
can easily bounce through proxies or botnets.

Most financials now use a risk engine, which looks at a lot of variables
related to the login, e.g. time of day, geolocation, machine
fingerprint, etc. (commercial risk engines have up to 90 variables). If
the engine deems the login high risk then supplemental authentication is
required, e.g. an SMS code.

Paul

On 19/05/2013 16:13, ? ?? wrote:

Dear all:

I work for a online financial company. As a financial company, we
accept little risk. So,our strategy was designed strictly that our
clients always need to input the recaptcha code to login, and the
account will be locked if the password errors exceed the limit. But
nowadays, we want to improve the user experience somehow, like google
who avoids the recaptcha code if the login is normal. If we choose to
show the recaptcha image by the rule of ID login error sum and
IP login error sum, hacker can still run the attack by switching the
proxy and reducing the trial times per ID.
Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

--
Pentest - The Application Security Specialists

Paul Johnston - IT Security Consultant / Tiger SST
PenTest Limited - ISO 9001 (44/100/107029) / ISO 27001 (IS 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

Hi, A common approach is this: 1) Lock account after three bad login attempts - this prevents vertical attacks (using Nuno's terminology) 2) User names are random numbers, with 12 digits or so - this prevents horizonal attacks Most financials do not use captchas as it's generally accepted that a determined attacker can break them, either through AI software or even mechanical turk. If your user names are not random numbers, asking a supplemental question servers a similar purpose. e.g. user is asked for: user name, surname, and password. The (user name, surname) pair is treated as the user name. Using IP addresses at all is a minefield as sometimes many users will come from the same IP address - think of the bank's own outgoing IP address, and all the thousands of staff that will login to their own account at lunchtime. It does have a place, but a determined attacker can easily bounce through proxies or botnets. Most financials now use a risk engine, which looks at a lot of variables related to the login, e.g. time of day, geolocation, machine fingerprint, etc. (commercial risk engines have up to 90 variables). If the engine deems the login high risk then supplemental authentication is required, e.g. an SMS code. Paul On 19/05/2013 16:13, ? ?? wrote: > Dear all: > > I work for a online financial company. As a financial company, we > accept little risk. So,our strategy was designed strictly that our > clients always need to input the recaptcha code to login, and the > account will be locked if the password errors exceed the limit. But > nowadays, we want to improve the user experience somehow, like google > who avoids the recaptcha code if the login is normal. If we choose to > show the recaptcha image by the rule of ID login error sum and > IP login error sum, hacker can still run the attack by switching the > proxy and reducing the trial times per ID. > Is there any better way to recognize the brute force attack? Thanks. > > Eric Tan -- Pentest - The Application Security Specialists Paul Johnston - IT Security Consultant / Tiger SST PenTest Limited - ISO 9001 (44/100/107029) / ISO 27001 (IS 558982) Office: +44 (0) 161 233 0100 Mobile: +44 (0) 7817 219 072 Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy Registered Number: 4217114 England & Wales Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

DC

Dinis Cruz

Tue, May 21, 2013 5:51 PM

Hi, one option to reduce Brute force is to have a delay in the login
process. For example when I was developing TeamMentor we implemented that
using the PBKDF2 hashing process (see
https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31)
which also gave us a strong method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see
this blog post for more details (and the unit tests we created to check its
timings):
http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html

You should also monitor your logins, like ETSY does it:
http://codeascraft.com/2011/02/15/measure-anything-measure-everything/

Btw, note that if you are blocking your users accounts after a number of
failed password attempts, you have created a potential DOS (Denial of
Service) vulnerability (since an attacker will be able to block your users
if he/she is able to find out valid usernames)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 19 May 2013 16:13, 谭翔宇 buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept
little risk. So,our strategy was designed strictly that our clients
always need to input the recaptcha code to login, and the account will be
locked if the password errors exceed the limit. But nowadays, we want to
improve the user experience somehow, like google who avoids the recaptcha
code if the login is normal. If we choose to show the recaptcha image by
the rule of ID login error sum and IP login error sum, hacker can still
run the attack by switching the proxy and reducing the trial times per
ID.
Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Hi, one option to reduce Brute force is to have a delay in the login process. For example when I was developing TeamMentor we implemented that using the PBKDF2 hashing process (see https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords.. At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see this blog post for more details (and the unit tests we created to check its timings): http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html You should also monitor your logins, like ETSY does it: http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ Btw, note that if you are blocking your users accounts after a number of failed password attempts, you have created a potential DOS (Denial of Service) vulnerability (since an attacker will be able to block your users if he/she is able to find out valid usernames) Dinis Dinis Cruz Blog: http://diniscruz.blogspot.com Twitter: http://twitter.com/DinisCruz Web: http://www.owasp.org/index.php/O2 On 19 May 2013 16:13, 谭翔宇 <buptisc_txy@yahoo.com.cn> wrote: > Dear all: > > I work for a online financial company. As a financial company, we accept > little risk. So,our strategy was designed strictly that our clients > always need to input the recaptcha code to login, and the account will be > locked if the password errors exceed the limit. But nowadays, we want to > improve the user experience somehow, like google who avoids the recaptcha > code if the login is normal. If we choose to show the recaptcha image by > the rule of ID login error sum and IP login error sum, hacker can still > run the attack by switching the proxy and reducing the trial times per > ID. > Is there any better way to recognize the brute force attack? Thanks. > > Eric Tan > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >

OG

Omer Granot

Tue, May 21, 2013 9:14 PM

Hi Dinis,

I agree with your solution direction and I did it with another tool which
gave me additional options but the brute force protection is similar.

We built in LoginWall a system which includes the time element in the
password and in addition I am sending pings to the server when the user
starts to type his password, if the time between the type start and the
password sending is too short I ignore the password, if it��s more than X
second I am checking the characters and the time elements. In this case
there isn��t any option to attack my password with brute force and I don��t
need to block users at all. In addition with my complicated passwords the
database is also protected because it impossible to find the original
password after I hashed it together with the time elements.

I think that we solved the brute force threat in our system and I will be
happy to share my experience with all of you (including free system
testing).

I will be happy to hear your comments about the method and about our
technology, more details at www.loginwall.com .

Omer Granot

LoginWall.com �C CTO

M: +972-54-6618185

From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf
Of Dinis Cruz
Sent: Tuesday, May 21, 2013 8:51 PM
To: ̷ ��
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] How to recognize brute force attack

Hi, one option to reduce Brute force is to have a delay in the login
process. For example when I was developing TeamMentor we implemented that
using the PBKDF2 hashing process (see
https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMent
or.CoreLib/TM_AppCode/Utils/Crypto.cs#L31 ) which also gave us a strong
method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see
this blog post for more details (and the unit tests we created to check its
timings):
http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html

You should also monitor your logins, like ETSY does it:
http://codeascraft.com/2011/02/15/measure-anything-measure-everything/

Btw, note that if you are blocking your users accounts after a number of
failed password attempts, you have created a potential DOS (Denial of
Service) vulnerability (since an attacker will be able to block your users
if he/she is able to find out valid usernames)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 19 May 2013 16:13, ̷ �� buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept
little risk. So,our strategy was designed strictly that our clients always
need to input the recaptcha code to login, and the account will be locked if
the password errors exceed the limit. But nowadays, we want to improve the
user experience somehow, like google who avoids the recaptcha code if the
login is normal. If we choose to show the recaptcha image by the rule of ID
login error sum and IP login error sum, hacker can still run the attack by
switching the proxy and reducing the trial times per ID.

Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Hi Dinis, I agree with your solution direction and I did it with another tool which gave me additional options but the brute force protection is similar. We built in LoginWall a system which includes the time element in the password and in addition I am sending pings to the server when the user starts to type his password, if the time between the type start and the password sending is too short I ignore the password, if it��s more than X second I am checking the characters and the time elements. In this case there isn��t any option to attack my password with brute force and I don��t need to block users at all. In addition with my complicated passwords the database is also protected because it impossible to find the original password after I hashed it together with the time elements. I think that we solved the brute force threat in our system and I will be happy to share my experience with all of you (including free system testing). I will be happy to hear your comments about the method and about our technology, more details at www.loginwall.com . Omer Granot LoginWall.com �C CTO M: +972-54-6618185 From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Dinis Cruz Sent: Tuesday, May 21, 2013 8:51 PM To: ̷ �� Cc: websecurity@webappsec.org Subject: Re: [WEB SECURITY] How to recognize brute force attack Hi, one option to reduce Brute force is to have a delay in the login process. For example when I was developing TeamMentor we implemented that using the PBKDF2 hashing process (see https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMent or.CoreLib/TM_AppCode/Utils/Crypto.cs#L31 ) which also gave us a strong method to store user's passwords.. At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see this blog post for more details (and the unit tests we created to check its timings): http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html You should also monitor your logins, like ETSY does it: http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ Btw, note that if you are blocking your users accounts after a number of failed password attempts, you have created a potential DOS (Denial of Service) vulnerability (since an attacker will be able to block your users if he/she is able to find out valid usernames) Dinis Dinis Cruz Blog: http://diniscruz.blogspot.com Twitter: http://twitter.com/DinisCruz Web: http://www.owasp.org/index.php/O2 On 19 May 2013 16:13, ̷ �� <buptisc_txy@yahoo.com.cn> wrote: Dear all: I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID. Is there any better way to recognize the brute force attack? Thanks. Eric Tan _______________________________________________ The Web Security Mailing List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

RD

Ryan Dewhurst

Tue, May 21, 2013 9:44 PM

RE: LoginWall.

If you send the AJAX request with the unix epoch in the past and then send
the login request afterwards. Does this not defeat the timing security
mechanism?

Basic sequence:

GET /demo2/loginwall.php?_=1369171933073
POST /demo2/process.php

On Tue, May 21, 2013 at 11:14 PM, Omer Granot omer@loginwall.com wrote:

Hi Dinis,****

I agree with your solution direction and I did it with another tool which
gave me additional options but the brute force protection is similar.****

We built in LoginWall a system which includes the time element in the
password and in addition I am sending pings to the server when the user
starts to type his password, if the time between the type start and the
password sending is too short I ignore the password, if it��s more than X
second I am checking the characters and the time elements. In this case
there isn��t any option to attack my password with brute force and I don��t
need to block users at all. In addition with my complicated passwords the
database is also protected because it impossible to find the original
password after I hashed it together with the time elements.****

I think that we solved the brute force threat in our system and I will be
happy to share my experience with all of you (including free system
testing).****

I will be happy to hear your comments about the method and about our
technology, more details at www.loginwall.com .****

Omer Granot****

LoginWall.com �C CTO****

M: +972-54-6618185****

From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On
Behalf Of Dinis Cruz
Sent: Tuesday, May 21, 2013 8:51 PM
To: ̷ ��
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] How to recognize brute force attack**

Hi, one option to reduce Brute force is to have a delay in the login
process. For example when I was developing TeamMentor we implemented that
using the PBKDF2 hashing process (see
https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see
this blog post for more details (and the unit tests we created to check its
timings):
http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html***
*

You should also monitor your logins, like ETSY does it:
http://codeascraft.com/2011/02/15/measure-anything-measure-everything/****

Btw, note that if you are blocking your users accounts after a number of
failed password attempts, you have created a potential DOS (Denial of
Service) vulnerability (since an attacker will be able to block your users
if he/she is able to find out valid usernames)****

Dinis****

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2****

On 19 May 2013 16:13, ̷ �� buptisc_txy@yahoo.com.cn wrote:****

Dear all: ****

I work for a online financial company. As a financial company, we accept
little risk. So,our strategy was designed strictly that our clients always
need to input the recaptcha code to login, and the account will be locked
if the password errors exceed the limit. But nowadays, we want to improve
the user experience somehow, like google who avoids the recaptcha code if
the login is normal. If we choose to show the recaptcha image by the rule
of ID login error sum and IP login error sum, hacker can still run the attack
by switching the proxy and reducing the trial times per ID. ****

Is there any better way to recognize the brute force attack? Thanks.****

Eric Tan****

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

RE: LoginWall. If you send the AJAX request with the unix epoch in the past and then send the login request afterwards. Does this not defeat the timing security mechanism? Basic sequence: 1. GET /demo2/loginwall.php?_=1369171933073 2. POST /demo2/process.php On Tue, May 21, 2013 at 11:14 PM, Omer Granot <omer@loginwall.com> wrote: > Hi Dinis,**** > > ** ** > > I agree with your solution direction and I did it with another tool which > gave me additional options but the brute force protection is similar.**** > > ** ** > > We built in LoginWall a system which includes the time element in the > password and in addition I am sending pings to the server when the user > starts to type his password, if the time between the type start and the > password sending is too short I ignore the password, if it��s more than X > second I am checking the characters and the time elements. In this case > there isn��t any option to attack my password with brute force and I don��t > need to block users at all. In addition with my complicated passwords the > database is also protected because it impossible to find the original > password after I hashed it together with the time elements.**** > > ** ** > > I think that we solved the brute force threat in our system and I will be > happy to share my experience with all of you (including free system > testing).**** > > ** ** > > I will be happy to hear your comments about the method and about our > technology, more details at www.loginwall.com .**** > > ** ** > > ** ** > > Omer Granot**** > > LoginWall.com �C CTO**** > > M: +972-54-6618185**** > > ** ** > > *From:* websecurity [mailto:websecurity-bounces@lists.webappsec.org] *On > Behalf Of *Dinis Cruz > *Sent:* Tuesday, May 21, 2013 8:51 PM > *To:* ̷ �� > *Cc:* websecurity@webappsec.org > *Subject:* Re: [WEB SECURITY] How to recognize brute force attack**** > > ** ** > > Hi, one option to reduce Brute force is to have a delay in the login > process. For example when I was developing TeamMentor we implemented that > using the PBKDF2 hashing process (see > https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords.. > **** > > ** ** > > At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see > this blog post for more details (and the unit tests we created to check its > timings): > http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html*** > * > > ** ** > > You should also monitor your logins, like ETSY does it: > http://codeascraft.com/2011/02/15/measure-anything-measure-everything/**** > > ** ** > > Btw, note that if you are blocking your users accounts after a number of > failed password attempts, you have created a potential DOS (Denial of > Service) vulnerability (since an attacker will be able to block your users > if he/she is able to find out valid usernames)**** > > ** ** > > Dinis**** > > > **** > > > Dinis Cruz > > Blog: http://diniscruz.blogspot.com > Twitter: http://twitter.com/DinisCruz > Web: http://www.owasp.org/index.php/O2**** > > ** ** > > On 19 May 2013 16:13, ̷ �� <buptisc_txy@yahoo.com.cn> wrote:**** > > Dear all: **** > > ** ** > > I work for a online financial company. As a financial company, we accept > little risk. So,our strategy was designed strictly that our clients always > need to input the recaptcha code to login, and the account will be locked > if the password errors exceed the limit. But nowadays, we want to improve > the user experience somehow, like google who avoids the recaptcha code if > the login is normal. If we choose to show the recaptcha image by the rule > of ID login error sum and IP login error sum, hacker can still run the attack > by switching the proxy and reducing the trial times per ID. **** > > Is there any better way to recognize the brute force attack? Thanks.**** > > ** ** > > Eric Tan**** > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > **** > > ** ** > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >

SD

Stephen de Vries

Wed, May 22, 2013 9:54 AM

On 21 May 2013, at 23:44, Ryan Dewhurst wrote:

If you send the AJAX request with the unix epoch in the past and then send the login request afterwards. Does this not defeat the timing security mechanism?

Basic sequence:

GET /demo2/loginwall.php?_=1369171933073
POST /demo2/process.php

Presumably the AJAX request doesn't contain the time, it's just a ping request to indicate that the server-side should start the timer, e.g.:

GET /demo2/starttimer?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu
POST /demo2/dologin.php?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu

On Tue, May 21, 2013 at 11:14 PM, Omer Granot omer@loginwall.com wrote:
Hi Dinis,

I agree with your solution direction and I did it with another tool which gave me additional options but the brute force protection is similar.

We built in LoginWall a system which includes the time element in the password and in addition I am sending pings to the server when the user starts to type his password, if the time between the type start and the password sending is too short I ignore the password, if it’s more than X second I am checking the characters and the time elements. In this case there isn’t any option to attack my password with brute force and I don’t need to block users at all. In addition with my complicated passwords the database is also protected because it impossible to find the original password after I hashed it together with the time elements.

I think that we solved the brute force threat in our system and I will be happy to share my experience with all of you (including free system testing).

I will be happy to hear your comments about the method and about our technology, more details at www.loginwall.com .

Omer Granot

LoginWall.com – CTO

M: +972-54-6618185

From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Dinis Cruz
Sent: Tuesday, May 21, 2013 8:51 PM
To: 谭翔宇
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] How to recognize brute force attack

Hi, one option to reduce Brute force is to have a delay in the login process. For example when I was developing TeamMentor we implemented that using the PBKDF2 hashing process (see https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31 ) which also gave us a strong method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see this blog post for more details (and the unit tests we created to check its timings): http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html

You should also monitor your logins, like ETSY does it: http://codeascraft.com/2011/02/15/measure-anything-measure-everything/

Btw, note that if you are blocking your users accounts after a number of failed password attempts, you have created a potential DOS (Denial of Service) vulnerability (since an attacker will be able to block your users if he/she is able to find out valid usernames)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 19 May 2013 16:13, 谭翔宇 buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID.

Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

On 21 May 2013, at 23:44, Ryan Dewhurst wrote: > > If you send the AJAX request with the unix epoch in the past and then send the login request afterwards. Does this not defeat the timing security mechanism? > > Basic sequence: > > 1. GET /demo2/loginwall.php?_=1369171933073 > 2. POST /demo2/process.php Presumably the AJAX request doesn't contain the time, it's just a ping request to indicate that the server-side should start the timer, e.g.: 1. GET /demo2/starttimer?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu 2. POST /demo2/dologin.php?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu > > > On Tue, May 21, 2013 at 11:14 PM, Omer Granot <omer@loginwall.com> wrote: > Hi Dinis, > > > > I agree with your solution direction and I did it with another tool which gave me additional options but the brute force protection is similar. > > > > We built in LoginWall a system which includes the time element in the password and in addition I am sending pings to the server when the user starts to type his password, if the time between the type start and the password sending is too short I ignore the password, if it’s more than X second I am checking the characters and the time elements. In this case there isn’t any option to attack my password with brute force and I don’t need to block users at all. In addition with my complicated passwords the database is also protected because it impossible to find the original password after I hashed it together with the time elements. > > > > I think that we solved the brute force threat in our system and I will be happy to share my experience with all of you (including free system testing). > > > > I will be happy to hear your comments about the method and about our technology, more details at www.loginwall.com . > > > > > > Omer Granot > > LoginWall.com – CTO > > M: +972-54-6618185 > > > > From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Dinis Cruz > Sent: Tuesday, May 21, 2013 8:51 PM > To: 谭翔宇 > Cc: websecurity@webappsec.org > Subject: Re: [WEB SECURITY] How to recognize brute force attack > > > > Hi, one option to reduce Brute force is to have a delay in the login process. For example when I was developing TeamMentor we implemented that using the PBKDF2 hashing process (see https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31 ) which also gave us a strong method to store user's passwords.. > > > > At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see this blog post for more details (and the unit tests we created to check its timings): http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html > > > > You should also monitor your logins, like ETSY does it: http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ > > > > Btw, note that if you are blocking your users accounts after a number of failed password attempts, you have created a potential DOS (Denial of Service) vulnerability (since an attacker will be able to block your users if he/she is able to find out valid usernames) > > > > Dinis > > > > > Dinis Cruz > > Blog: http://diniscruz.blogspot.com > Twitter: http://twitter.com/DinisCruz > Web: http://www.owasp.org/index.php/O2 > > > > On 19 May 2013 16:13, 谭翔宇 <buptisc_txy@yahoo.com.cn> wrote: > > Dear all: > > > > I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID. > > Is there any better way to recognize the brute force attack? Thanks. > > > > Eric Tan > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

RD

Ryan Dewhurst

Wed, May 22, 2013 10:13 AM

I noticed this afterwards. It seems the epoch is just so the browser
doesn't cache the request. The request itself must be used to start the
timer on the server which is then stored against the user's session on the
server.

On Wed, May 22, 2013 at 11:54 AM, Stephen de Vries stephendv@gmail.comwrote:

On 21 May 2013, at 23:44, Ryan Dewhurst wrote:

If you send the AJAX request with the unix epoch in the past and then

send the login request afterwards. Does this not defeat the timing security
mechanism?

Basic sequence:

GET /demo2/loginwall.php?_=1369171933073
POST /demo2/process.php

Presumably the AJAX request doesn't contain the time, it's just a ping
request to indicate that the server-side should start the timer, e.g.:

GET /demo2/starttimer?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu
POST /demo2/dologin.php?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu

On Tue, May 21, 2013 at 11:14 PM, Omer Granot omer@loginwall.com

wrote:

Hi Dinis,

I agree with your solution direction and I did it with another tool

which gave me additional options but the brute force protection is similar.

We built in LoginWall a system which includes the time element in the

password and in addition I am sending pings to the server when the user
starts to type his password, if the time between the type start and the
password sending is too short I ignore the password, if it’s more than X
second I am checking the characters and the time elements. In this case
there isn’t any option to attack my password with brute force and I don’t
need to block users at all. In addition with my complicated passwords the
database is also protected because it impossible to find the original
password after I hashed it together with the time elements.

I think that we solved the brute force threat in our system and I will

be happy to share my experience with all of you (including free system
testing).

I will be happy to hear your comments about the method and about our

technology, more details at www.loginwall.com .

Omer Granot

LoginWall.com – CTO

M: +972-54-6618185

From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On

Behalf Of Dinis Cruz

Sent: Tuesday, May 21, 2013 8:51 PM
To: 谭翔宇
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] How to recognize brute force attack

Hi, one option to reduce Brute force is to have a delay in the login

process. For example when I was developing TeamMentor we implemented that
using the PBKDF2 hashing process (see
https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms,

see this blog post for more details (and the unit tests we created to check
its timings):
http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html

You should also monitor your logins, like ETSY does it:

http://codeascraft.com/2011/02/15/measure-anything-measure-everything/

Btw, note that if you are blocking your users accounts after a number of

failed password attempts, you have created a potential DOS (Denial of
Service) vulnerability (since an attacker will be able to block your users
if he/she is able to find out valid usernames)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 19 May 2013 16:13, 谭翔宇 buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept

little risk. So,our strategy was designed strictly that our clients always
need to input the recaptcha code to login, and the account will be locked
if the password errors exceed the limit. But nowadays, we want to improve
the user experience somehow, like google who avoids the recaptcha code if
the login is normal. If we choose to show the recaptcha image by the rule
of ID login error sum and IP login error sum, hacker can still run the
attack by switching the proxy and reducing the trial times per ID.

Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

I noticed this afterwards. It seems the epoch is just so the browser doesn't cache the request. The request itself must be used to start the timer on the server which is then stored against the user's session on the server. On Wed, May 22, 2013 at 11:54 AM, Stephen de Vries <stephendv@gmail.com>wrote: > > On 21 May 2013, at 23:44, Ryan Dewhurst wrote: > > > > If you send the AJAX request with the unix epoch in the past and then > send the login request afterwards. Does this not defeat the timing security > mechanism? > > > > Basic sequence: > > > > 1. GET /demo2/loginwall.php?_=1369171933073 > > 2. POST /demo2/process.php > > Presumably the AJAX request doesn't contain the time, it's just a ping > request to indicate that the server-side should start the timer, e.g.: > > 1. GET /demo2/starttimer?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu > 2. POST /demo2/dologin.php?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu > > > > > > > > > > > On Tue, May 21, 2013 at 11:14 PM, Omer Granot <omer@loginwall.com> > wrote: > > Hi Dinis, > > > > > > > > I agree with your solution direction and I did it with another tool > which gave me additional options but the brute force protection is similar. > > > > > > > > We built in LoginWall a system which includes the time element in the > password and in addition I am sending pings to the server when the user > starts to type his password, if the time between the type start and the > password sending is too short I ignore the password, if it’s more than X > second I am checking the characters and the time elements. In this case > there isn’t any option to attack my password with brute force and I don’t > need to block users at all. In addition with my complicated passwords the > database is also protected because it impossible to find the original > password after I hashed it together with the time elements. > > > > > > > > I think that we solved the brute force threat in our system and I will > be happy to share my experience with all of you (including free system > testing). > > > > > > > > I will be happy to hear your comments about the method and about our > technology, more details at www.loginwall.com . > > > > > > > > > > > > Omer Granot > > > > LoginWall.com – CTO > > > > M: +972-54-6618185 > > > > > > > > From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On > Behalf Of Dinis Cruz > > Sent: Tuesday, May 21, 2013 8:51 PM > > To: 谭翔宇 > > Cc: websecurity@webappsec.org > > Subject: Re: [WEB SECURITY] How to recognize brute force attack > > > > > > > > Hi, one option to reduce Brute force is to have a delay in the login > process. For example when I was developing TeamMentor we implemented that > using the PBKDF2 hashing process (see > https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords.. > > > > > > > > At the moment we have the PBKDF2 hash to last between 200ms and 500ms, > see this blog post for more details (and the unit tests we created to check > its timings): > http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html > > > > > > > > You should also monitor your logins, like ETSY does it: > http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ > > > > > > > > Btw, note that if you are blocking your users accounts after a number of > failed password attempts, you have created a potential DOS (Denial of > Service) vulnerability (since an attacker will be able to block your users > if he/she is able to find out valid usernames) > > > > > > > > Dinis > > > > > > > > > > Dinis Cruz > > > > Blog: http://diniscruz.blogspot.com > > Twitter: http://twitter.com/DinisCruz > > Web: http://www.owasp.org/index.php/O2 > > > > > > > > On 19 May 2013 16:13, 谭翔宇 <buptisc_txy@yahoo.com.cn> wrote: > > > > Dear all: > > > > > > > > I work for a online financial company. As a financial company, we accept > little risk. So,our strategy was designed strictly that our clients always > need to input the recaptcha code to login, and the account will be locked > if the password errors exceed the limit. But nowadays, we want to improve > the user experience somehow, like google who avoids the recaptcha code if > the login is normal. If we choose to show the recaptcha image by the rule > of ID login error sum and IP login error sum, hacker can still run the > attack by switching the proxy and reducing the trial times per ID. > > > > Is there any better way to recognize the brute force attack? Thanks. > > > > > > > > Eric Tan > > > > > > _______________________________________________ > > The Web Security Mailing List > > > > WebSecurity RSS Feed > > http://www.webappsec.org/rss/websecurity.rss > > > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > > > WASC on Twitter > > http://twitter.com/wascupdates > > > > websecurity@lists.webappsec.org > > > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > > > > > > > > > _______________________________________________ > > The Web Security Mailing List > > > > WebSecurity RSS Feed > > http://www.webappsec.org/rss/websecurity.rss > > > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > > > WASC on Twitter > > http://twitter.com/wascupdates > > > > websecurity@lists.webappsec.org > > > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > > > > > _______________________________________________ > > The Web Security Mailing List > > > > WebSecurity RSS Feed > > http://www.webappsec.org/rss/websecurity.rss > > > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > > > WASC on Twitter > > http://twitter.com/wascupdates > > > > websecurity@lists.webappsec.org > > > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >

DC

Dinis Cruz

Thu, May 23, 2013 8:46 AM

Following from my comment below, I wrote a detailed blog post yesterday
that explains how it works: How TeamMentor creates SHA256+PBKDF2 password
hashes and stores them in XML
fileshttp://blog.diniscruz.com/2013/05/how-teammentor-stores-sha256pbkdf2.html
(with
better links to the source code, in case you want to see how it was
implemented)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 21 May 2013 18:51, Dinis Cruz dinis.cruz@owasp.org wrote:

Hi, one option to reduce Brute force is to have a delay in the login
process. For example when I was developing TeamMentor we implemented that
using the PBKDF2 hashing process (see
https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see
this blog post for more details (and the unit tests we created to check its
timings):
http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html

You should also monitor your logins, like ETSY does it:
http://codeascraft.com/2011/02/15/measure-anything-measure-everything/

Btw, note that if you are blocking your users accounts after a number of
failed password attempts, you have created a potential DOS (Denial of
Service) vulnerability (since an attacker will be able to block your users
if he/she is able to find out valid usernames)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 19 May 2013 16:13, 谭翔宇 buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept
little risk. So,our strategy was designed strictly that our clients
always need to input the recaptcha code to login, and the account will
be locked if the password errors exceed the limit. But nowadays, we want
to improve the user experience somehow, like google who avoids the recaptcha
code if the login is normal. If we choose to show the recaptcha image by
the rule of ID login error sum and IP login error sum, hacker can still
run the attack by switching the proxy and reducing the trial times per
ID.
Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Following from my comment below, I wrote a detailed blog post yesterday that explains how it works: How TeamMentor creates SHA256+PBKDF2 password hashes and stores them in XML files<http://blog.diniscruz.com/2013/05/how-teammentor-stores-sha256pbkdf2.html> (with better links to the source code, in case you want to see how it was implemented) Dinis Dinis Cruz Blog: http://diniscruz.blogspot.com Twitter: http://twitter.com/DinisCruz Web: http://www.owasp.org/index.php/O2 On 21 May 2013 18:51, Dinis Cruz <dinis.cruz@owasp.org> wrote: > Hi, one option to reduce Brute force is to have a delay in the login > process. For example when I was developing TeamMentor we implemented that > using the PBKDF2 hashing process (see > https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31) which also gave us a strong method to store user's passwords.. > > At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see > this blog post for more details (and the unit tests we created to check its > timings): > http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html > > You should also monitor your logins, like ETSY does it: > http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ > > Btw, note that if you are blocking your users accounts after a number of > failed password attempts, you have created a potential DOS (Denial of > Service) vulnerability (since an attacker will be able to block your users > if he/she is able to find out valid usernames) > > Dinis > > > Dinis Cruz > > Blog: http://diniscruz.blogspot.com > Twitter: http://twitter.com/DinisCruz > Web: http://www.owasp.org/index.php/O2 > > > On 19 May 2013 16:13, 谭翔宇 <buptisc_txy@yahoo.com.cn> wrote: > >> Dear all: >> >> I work for a online financial company. As a financial company, we accept >> little risk. So,our strategy was designed strictly that our clients >> always need to input the recaptcha code to login, and the account will >> be locked if the password errors exceed the limit. But nowadays, we want >> to improve the user experience somehow, like google who avoids the recaptcha >> code if the login is normal. If we choose to show the recaptcha image by >> the rule of ID login error sum and IP login error sum, hacker can still >> run the attack by switching the proxy and reducing the trial times per >> ID. >> Is there any better way to recognize the brute force attack? Thanks. >> >> Eric Tan >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >

RP

Rohit Pitke

Fri, May 24, 2013 10:18 PM

In my opinion, combination of server-side lockout + captacha + artificial system to detect alarms like geo-location, unusual transactions, frequency of transactions should help in recognizing Brute Force attacks

Rohit

From: Ryan Dewhurst ryandewhurst@gmail.com
To: Stephen de Vries stephendv@gmail.com
Cc: Webappsec Group websecurity@webappsec.org
Sent: Wednesday, May 22, 2013 3:13 AM
Subject: Re: [WEB SECURITY] How to recognize brute force attack

I noticed this afterwards. It seems the epoch is just so the browser doesn't cache the request. The request itself must be used to start the timer on the server which is then stored against the user's session on the server.

On Wed, May 22, 2013 at 11:54 AM, Stephen de Vries stephendv@gmail.com wrote:

On 21 May 2013, at 23:44, Ryan Dewhurst wrote:

If you send the AJAX request with the unix epoch in the past and then send the login request afterwards. Does this not defeat the timing security mechanism?

Basic sequence:

GET /demo2/loginwall.php?_=1369171933073
POST /demo2/process.php

Presumably the AJAX request doesn't contain the time, it's just a ping request to indicate that the server-side should start the timer, e.g.:

GET /demo2/starttimer?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu
POST /demo2/dologin.php?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu

On Tue, May 21, 2013 at 11:14 PM, Omer Granot omer@loginwall.com wrote:
Hi Dinis,

I agree with your solution direction and I did it with another tool which gave me additional options but the brute force protection is similar.

We built in LoginWall a system which includes the time element in the password and in addition I am sending pings to the server when the user starts to type his password, if the time between the type start and the password sending is too short I ignore the password, if it’s more than X second I am checking the characters and the time elements. In this case there isn’t any option to attack my password with brute force and I don’t need to block users at all. In addition with my complicated passwords the database is also protected because it impossible to find the original password after I hashed it together with the time elements.

I think that we solved the brute force threat in our system and I will be happy to share my experience with all of you (including free system testing).

I will be happy to hear your comments about the method and about our technology, more details at www.loginwall.com .

Omer Granot

LoginWall.com – CTO

M: +972-54-6618185

From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Dinis Cruz
Sent: Tuesday, May 21, 2013 8:51 PM
To: 谭翔宇
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] How to recognize brute force attack

Hi, one option to reduce Brute force is to have a delay in the login process. For example when I was developing TeamMentor we implemented that using the PBKDF2 hashing process (see https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31 ) which also gave us a strong method to store user's passwords..

At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see this blog post for more details (and the unit tests we created to check its timings): http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html

You should also monitor your logins, like ETSY does it: http://codeascraft.com/2011/02/15/measure-anything-measure-everything/

Btw, note that if you are blocking your users accounts after a number of failed password attempts, you have created a potential DOS (Denial of Service) vulnerability (since an attacker will be able to block your users if he/she is able to find out valid usernames)

Dinis

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 19 May 2013 16:13, 谭翔宇 buptisc_txy@yahoo.com.cn wrote:

Dear all:

I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID.

Is there any better way to recognize the brute force attack? Thanks.

Eric Tan

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

In my opinion, combination of server-side lockout + captacha + artificial system to detect alarms like geo-location, unusual transactions, frequency of transactions should help in recognizing Brute Force attacks Rohit ________________________________ From: Ryan Dewhurst <ryandewhurst@gmail.com> To: Stephen de Vries <stephendv@gmail.com> Cc: Webappsec Group <websecurity@webappsec.org> Sent: Wednesday, May 22, 2013 3:13 AM Subject: Re: [WEB SECURITY] How to recognize brute force attack I noticed this afterwards. It seems the epoch is just so the browser doesn't cache the request. The request itself must be used to start the timer on the server which is then stored against the user's session on the server. On Wed, May 22, 2013 at 11:54 AM, Stephen de Vries <stephendv@gmail.com> wrote: >On 21 May 2013, at 23:44, Ryan Dewhurst wrote: >> >> If you send the AJAX request with the unix epoch in the past and then send the login request afterwards. Does this not defeat the timing security mechanism? >> >> Basic sequence: >> >> 1. GET /demo2/loginwall.php?_=1369171933073 >> 2. POST /demo2/process.php > >Presumably the AJAX request doesn't contain the time, it's just a ping request to indicate that the server-side should start the timer, e.g.: > >1. GET /demo2/starttimer?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu >2. POST /demo2/dologin.php?pre-login-sessionid=sdfkhwehwekrhwkrwereouoiu > > > > > > >> >> >> On Tue, May 21, 2013 at 11:14 PM, Omer Granot <omer@loginwall.com> wrote: >> Hi Dinis, >> >> >> >> I agree with your solution direction and I did it with another tool which gave me additional options but the brute force protection is similar. >> >> >> >> We built in LoginWall a system which includes the time element in the password and in addition I am sending pings to the server when the user starts to type his password, if the time between the type start and the password sending is too short I ignore the password, if it’s more than X second I am checking the characters and the time elements. In this case there isn’t any option to attack my password with brute force and I don’t need to block users at all. In addition with my complicated passwords the database is also protected because it impossible to find the original password after I hashed it together with the time elements. >> >> >> >> I think that we solved the brute force threat in our system and I will be happy to share my experience with all of you (including free system testing). >> >> >> >> I will be happy to hear your comments about the method and about our technology, more details at www.loginwall.com . >> >> >> >> >> >> Omer Granot >> >> LoginWall.com – CTO >> >> M: +972-54-6618185 >> >> >> >> From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Dinis Cruz >> Sent: Tuesday, May 21, 2013 8:51 PM >> To: 谭翔宇 >> Cc: websecurity@webappsec.org >> Subject: Re: [WEB SECURITY] How to recognize brute force attack >> >> >> >> Hi, one option to reduce Brute force is to have a delay in the login process. For example when I was developing TeamMentor we implemented that using the PBKDF2 hashing process (see https://github.com/TeamMentor/Master/blob/master/Web%20Applications/TeamMentor.CoreLib/TM_AppCode/Utils/Crypto.cs#L31 ) which also gave us a strong method to store user's passwords.. >> >> >> >> At the moment we have the PBKDF2 hash to last between 200ms and 500ms, see this blog post for more details (and the unit tests we created to check its timings): http://blog.diniscruz.com/2013/03/how-pbkdf2-interactions-affected.html >> >> >> >> You should also monitor your logins, like ETSY does it: http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ >> >> >> >> Btw, note that if you are blocking your users accounts after a number of failed password attempts, you have created a potential DOS (Denial of Service) vulnerability (since an attacker will be able to block your users if he/she is able to find out valid usernames) >> >> >> >> Dinis >> >> >> >> >> Dinis Cruz >> >> Blog: http://diniscruz.blogspot.com >> Twitter: http://twitter.com/DinisCruz >> Web: http://www.owasp.org/index.php/O2 >> >> >> >> On 19 May 2013 16:13, 谭翔宇 <buptisc_txy@yahoo.com.cn> wrote: >> >> Dear all: >> >> >> >> I work for a online financial company. As a financial company, we accept little risk. So,our strategy was designed strictly that our clients always need to input the recaptcha code to login, and the account will be locked if the password errors exceed the limit. But nowadays, we want to improve the user experience somehow, like google who avoids the recaptcha code if the login is normal. If we choose to show the recaptcha image by the rule of ID login error sum and IP login error sum, hacker can still run the attack by switching the proxy and reducing the trial times per ID. >> >> Is there any better way to recognize the brute force attack? Thanks. >> >> >> >> Eric Tan >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > _______________________________________________ The Web Security Mailing List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org