Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: User ID generation |
|---|---|
| Date: | Thu, 14 Apr 2005 09:10:30 +1000 |
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/
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | http://www.domainname.com./ (with the ending), Scovetta, Michael V |
|---|---|
| Next by Date: | RE: ColdFusion - CFID & CFTOKEN, Andrew van der Stock |
| Previous by Thread: | User ID generation, Jason binger |
| Next by Thread: | RE: User ID generation, Thomas Ng |
| Indexes: | [Date] [Thread] [Top] [All Lists] |