RE: password complexity -- implementing security changes
- From: William B Ferguson <wbfergus@xxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 3 Mar 2006 06:58:24 -0700
All this password complexity and automatic account locking, password
history, etc. is one of the biggest loss of productivity efforts I've seen
to date.
We, (USGS) just opened up a big help desk for a considerable sum of money
(I wouldn't mind retiring on it), that's staffed with 30 contractors. The
bulk of their work will be restting passwords, though once in a while they
might actually get asked a question like "How do I change the font in
Word?". Supposedly, the help desk will be such a big boost to productivity
(i.e. resetting passwords faster?), that it will be used by all of DOI
(around 70,000 people), but I find that hard to believe. Just the common
Joe Blow user has to access his LAN, a Time and Attendance app, email, and
a payroll record for his own persoanl information. All of the systems have
different password requirements for complexity, history, and how often
they have to change them. Add to the mix the users that need access to
more databases and systems, and the problem grows.
I have several personal accounts across the web that I've had for around
10 years now. I selected a complex password for them (before it was in
vogue), and have never changed them. Also, those accounts have never been
hacked. I wonder what is the probability that if I changed them, it would
be to one closer in line to what a potential hacker would be ready to try,
instead of the ones that have never been hacked?
I wind up wasting at least 1 hour a month with password issues on systems
(hardware or software) for my own personal accounts and managing other
accounts, and I have a small number of users right now. Once my system
goes production, my number of users will jump at least tenfold, and I
imagine so will my 'password' headaches as well, since the help desk does
not, and will not have access to my database.
So much for my rant, and I suppose I should say that opinions expressed
above are just my own and in no way reflect upon USGS or the Dept. of the
Interior (or any other government entity).
------------------------------------------------------------
Bill Ferguson
U.S. Geological Survey - Minerals Information Team
PO Box 25046, MS-750
Denver, Colorado 80225
Voice (303)236-8747 ext. 321 Fax (303)236-4208
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ethan Post
> Sent: Thursday, March 02, 2006 4:14 PM
> To: Coleman, Kelley (HAC)
> Cc: shrekdba@xxxxxxxxx; cemail_219@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> Subject: Re: password complexity -- implementing security changes
>
> Perhaps we should look at this like logical IO's. Password
> resets seem like a minor thing, but consider all the 10's of
> thousands of helpdesks all resetting 10's of thousands of
> passwords, all that adds up to a big loss of productivity.
> Perhaps we don't need the GDP to grow, we just need to ensure
> password attempts is at least 50 (sorry for my US analogical
> *warning possible made up word* bias).
> We Oracle DBA's make up something like 40% of the market,
> just think about it, Oracle-L could change the entire world
> economy overnight..or not.
>
> On 3/2/06, Coleman, Kelley (HAC) <Kelley.Coleman@xxxxxx> wrote:
> > I'm with you, Ethan. Unfortunately, TPTB have mandated we go to 3
> > attempts. The number password reset calls I take has gone up
> > exponentially. And I'm really not being dramatic. I've
> gone from 3-5
> > per week to 7-8 per day. It's very frustrating. Most of my
> users are
> > not super users. They have password requirements that are
> very complex.
> > And like you, they have 10 different ones to remember and each
> > system's requirements are slightly different so it's rare that they
> > can use the same password on several systems.
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts: