Look at
http://www.ngssoftware.com/papers/NISR-AntiBruteForceResourceMetering.pd
f
I am actually pretty impressed with the idea. Simple and effective. From
the paper, it seems to be able to extend to smtp and http usage. Not
sure how well it can integrate into others.
In this case, you can increase the number of attempts before account
lockouts.... or disable account lockouts altogether (not sure whether
this is a good idea).
> -----Original Message-----
> From: Andrew van der Stock [mailto:vanderaj_at_greebo.net]
> Sent: Thursday, April 14, 2005 7:11 AM
> To: 'Jason binger'
> Cc: webappsec_at_securityfocus.com
> Subject: RE: User ID generation
>
> Let the users select their usernames.
>
> Don't force them to use your scheme. That will introduce a great deal
of
> randomness and make it next to impossible to brute force via an
algorithm
> other than starting from "AAAAA" and working through.
>
> Don't let help desk staff trust the usernames, for surely the users
will
> select "admin" or "root" given half a chance.
>
> This is documented in the latest version of the OWASP Guide 2.0a7,
which
> you
> can get from here:
>
> http://www.greebo.net/owasp/
>
> Look in the authentication section.
>
> As authentication often goes to SQL, LDAP or might be transmitted via
XML
> web services, do not allow HTML, SQL, LDAP or XML special characters
in
> the
> usernames:
>
> * & | < > @ % ( ) = .
>
> With the possible exception of ' which should be escaped correctly.
The
> best
> bet is not to restrict by blacklisting, but validate by whitelisting.
Ie,
> accept only:
>
> [A-z,0-9,_, ]
>
> The regex should be tested, not replacing with "safe" blanks - if they
get
> it wrong, they try, try again until they get it right before their
input
> touches your interpreters.
>
> Canocalize the input to ensure that there is no UTF or URL double (or
> n-deep) encodes.
>
> I also like to restrict usernames to 20 characters, enforced server
side.
> It's possible to do SQL or LDAP injection in 20 characters, but what
is
> possible is dramatically limited compared to longer strings.
>
> thanks,
> Andrew
>
> > -----Original Message-----
> > From: Jason binger [mailto:cisspstudy_at_yahoo.com]
> > Sent: Tuesday, 12 April 2005 6:26 PM
> > To: webappsec_at_securityfocus.com
> > Subject: User ID generation
> >
> > I have a customer that generates UserIDs as numbers
> > sequentially for a critical application. They
> > implement account lockout and I am concerned that
> > someone could launch a DOS and lockout all the user
> > accounts.
> >
> > What would people recommend for a user ID generation
> > method.
> >
> > I was thinking UserIDs should be randomly generated
> > from a large alpha-numeric keyspace, but how big
> > should the keyspace be?
> > What would the size of the keyspace need to be if it
> > was only numeric?
> >
> > Any other thoughts appreciated.
> >
> > Cheers,
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Small Business - Try our new resources site!
> > http://smallbusiness.yahoo.com/resources/
Received on Apr 13 2005
Intro
