Re: Epithet

[Jimi Thompson <jimit () myrealbox com>]

My point with this was that instead of devoting so much energy to 
assigning a random user id, you should probably be spending that energy 
in making sure that your authentication mechanism is secure.  Once the 
authentication mechanism is secure against brute force dictionary 
attacks, which very few are, you can start working on your user naming 
schemes. 

2 cents,

Jimi

Meritt James wrote:

> I found out over a decade ago that it does not work, especially when the
> one doing th 'crqack' doesn't know what SHOULD be.  All systems are
> equally obscure to those who do not know what "should" be, which makes
> renaming,... effective only a small bit against those who know enough to
> know what to expect but probably not enough to be dangerous.
>
>
> Jimi Thompson wrote:
>  
>
> > All,
> >
> > While I am never in favor of giving information to the "enemy", keep in
> > mind that "security by obscurity" is quite useless.  You can have the
> > most fabulous UID system on the planet, and I can still crack it  if
> > the  authentication mechanism can be brute forced.
> >
> > 2 cents,
> >
> > Jimi
> >
> > SMiller () unimin com wrote:
> >
> >    
> >
> > > Steve,
> > >
> > > I too have been doing this for a long time.  A few years ago I would not
> > > have hesitated to suggest that the userid match the user's name as closely
> > > as the system would allow.  However, I see far too many applications today
> > > that automatically cache this value, even when the user has elected not to
> > > cache the password (a practice BTW that I believe should barred by any sane
> > > security policy)  So I guess my best advice is to evaluate the
> > > administrative benefits of easy user identification by that string (also
> > > consider how easy or difficult it might be to create and maintain a
> > > separate table that would correlate a "random" id with user identity) with
> > > the incremental risk from id-caching applications.  In no case would I
> > > advise use of a unique and loaded value such as employee number as a user
> > > id.
> > >
> > > Scott
> > > "Specialists without spirit, sensualists without heart, this nullity
> > > imagines that it has attained a level of civilization never before
> > > achieved" - J. W. von Goethe
> > >
> > >
> > >
> > >                     Steve.Kirby@seale
> > >                     dair.com                 To:       security-basics () securityfocus com
> > >                                              cc:
> > >                     12/02/2003 12:36         Fax to:
> > >                     AM                       Subject:  Epithet
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > To the list:
> > >
> > > We are currently developing a meta-directory project. One data element that
> > > we may now be able to re-define, is that of a User's Identification (UID).
> > >
> > > There are many 'schools of thought' about what should, or should not make
> > > up a UID. Do you include all or part of a person's name, do you use
> > > initials, what about an employee number (and what if they're a contractor
> > > without one)? The permutations are endless.
> > >
> > > Having worked for many years in administration of systems,  I tend to think
> > > you should be able to derive who the user is - so you can ring them....
> > > just as you log them off!  But is it necessary to identify the user easily?
> > > Could a seemingly nonsensical code be used to preserve anonymity? Is a
> > > jumbled UID a better deterrent against someone trying to forge an identity
> > > into our systems because they wouldn't know how it was made up or verified?
> > >
> > > The questions are almost endless, but I would be very interested to hear
> > >      
> > >
> > > from others about their experiences or thoughts. No names, no packdrills,
> >    
> >
> > > but examples of how UIDs are made up or UIDs you've come across would be
> > > gratefully accepted.
> > >
> > > Regards,
> > >
> > > Stavros
> > >
> > > or should that be GX78F2792?
> > >
> > >
> > > ---------------------------------------------------------------------------
> > > ----------------------------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------------
> > > ----------------------------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> > >      
> > ---------------------------------------------------------------------------
> > ----------------------------------------------------------------------------
> >    
>
>  



---------------------------------------------------------------------------
----------------------------------------------------------------------------