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@greebo.net]
Sent: Thursday, April 14, 2005 7:11 AM
To: 'Jason binger'
Cc: webappsec@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@yahoo.com]
Sent: Tuesday, 12 April 2005 6:26 PM
To: webappsec@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/
