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 13:29:09 -0400 |
Whilst talking about usernames, I was wondering what people's thoughts were on the following scheme. The users date of birth, Selected from drop down boxes, and entering a 4 digit random number, selected by the system, so username are unique. _________________________________________________ Andi, I would think that if your goal is to make your user names practically undetectable, then you would succeed. However, IMHO there are a couple of reasons why this may not be the best approach (at least not for my environment). 1) It takes away it's very purpose. User names are used as a quick reference while auditing logs to identify unusual access or identifying who was logged in at certain times. If you review your logs on a regular basis, whether by a SIM or by manual review, unless you know everyone's birth dates by heart, this standard would become useless. You would no longer be able to identify anomalies within the logs. I'm sure you could look each up if you were doing incident response to find out who is who, but that could be very time consuming and costly (unless you only have 3 people in the company). 2) Not all user ID's are directly related to a single person. This is obviously reflective of your development practice. But there could be times when either a standard ID is used to run maintenance, or scripts by a scheduler. You may not necessarily want something as generic as a backup process that could be run on a nightly process to be run with a specific user's login. This would be 1 way to identify if someone actually logs in vs. a scheduler process was running. It has it's inherit issues as well, but again it depends on your standards that you follow. These are just a couple of reasons, but enough for me to say it wouldn't be a good idea in my environment. --Jerry
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: webapp dependencies, moty yacov |
|---|---|
| Next by Date: | Re: User ID generation, Adam K |
| Previous by Thread: | Re: User ID generation, Paul M. |
| Next by Thread: | Re: User ID generation, Andi McLean |
| Indexes: | [Date] [Thread] [Top] [All Lists] |