Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: password complexity -- implementing security changes

RE: password complexity -- implementing security changes

From: William B Ferguson <>
Date: Fri, 3 Mar 2006 06:58:24 -0700
Message-ID: <>

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:
> [] On Behalf Of Ethan Post
> Sent: Thursday, March 02, 2006 4:14 PM
> To: Coleman, Kelley (HAC)
> Cc:;;
> 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) <> 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.
> --

Received on Fri Mar 03 2006 - 07:58:24 CST

Original text of this message