WebApp Sec mailing list archives
RE: User ID generation
From: "Thomas Ng" <thomas () singcert org sg>
Date: Thu, 14 Apr 2005 11:54:46 +0800
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/
Current thread:
- User ID generation Jason binger (Apr 13)
- RE: User ID generation Andrew van der Stock (Apr 13)
- RE: User ID generation Thomas Ng (Apr 13)
- Re: User ID generation Scovetta Labs (Apr 13)
- Re: User ID generation Andi McLean (Apr 14)
- Re: User ID generation Adam K (Apr 18)
- Re: User ID generation Scovetta Labs (Apr 18)
- Re: User ID generation Andi McLean (Apr 14)
- Re: User ID generation Paul M. (Apr 18)
- <Possible follow-ups>
- RE: User ID generation Murtland, Jerry (Apr 18)
- Re: User ID generation Andi McLean (Apr 18)
- Re: User ID generation Lucas Holt (Apr 20)
- Re: User ID generation Andi McLean (Apr 18)
- RE: User ID generation Andrew van der Stock (Apr 13)