A better way to think about passwords

Jean-David Beyer jeandavid8 at verizon.net
Fri Apr 22 02:58:56 CEST 2011

Hash: SHA1

MFPA wrote:
> Hi
> On Thursday 21 April 2011 at 2:20:51 PM, in
> <mid:4DB02F33.5010007 at verizon.net>, Jean-David Beyer wrote:
>> I do not think it is entirely not wanting to be
>> educated. But if the education takes several hours a
>> week to keep up with and to administer my own
>> responsibilities in the process( generating new
>> passwords, and different ones on a frequent basis,
>> finding some way to remember them other than writing
>> them on a post-it note on a monitor, keeping up with
>> password rules (Must have letters in both cases,
>> special characters, digits, at least some length, not
>> to exceed some other length, not a simple permutation
>> of the last few used on this system, etc. But some
>> require some or all of these. Some allow only letters
>> and digits, and so on. Who can keep up?), then
>> management would have to budget the time so I could do
>> it, and they will not. There has to be a better way,
>> and I do not know what it is.
> Your employee ID card acting as a hardware ID token,

Our ID cards were good enough for military security in the late 1950s.
They had no magnetic stripe, no machine readable bar codes, no nothing.
Later they got Polaroid cards that had color pictures of us on them.
Still nothing machine readable.

> a single
> passphrase to log onto your workstation,

No workstations in those days. ASR-33 teletypes that you did not log
into. Later some electronic junk remote terminals by Teletype Corp.
Remember that we were still using punched cards in those days for most
work. Only the far-out people got to use dumb terminals, such as ADM-3.
It was the computer at the other end, typically a cobbled up version of
System/360 TSS for some systems, UNIX for other systems, GECOS for the
GE 635s, all different. Some times we had to log into what would now be
called a LAN in the building where the server might be first, then dial
the number of the server on that LAN, then log into that server.

> and the administrators of
> each app taking care of which staff are allowed to use their system.
> No further passwords/usernames are necessary, just a short timeout
> feature to lock the workstation if the employee is stupid enough to
> leave their ID card inserted when they leave their desk.
Oh! Yes. Once I got stuck implementing security on a bunch of UNIX
servers on a battery of PDP-11/70s and Vaxes. I made it necessary for
each user to assign himself a password. I gave them 30 days and cut off
those who had not done it. I almost got lynched. I also put slowdowns in
the login program. If you got the password wrong, it waited a second
before you could try again. If you failed a second time, I doubled it,
etc. When it got up to a minute, I had it hang up on them.

People then got to leaving their terminals logged in, so I put a timer
in there and if they did no input for an hour, I logged them out. They
hated that too. That was not enough. Some @$$holes would wander around
and change passwords of people who deserted their terminals. I got so
many people mad at me that I was relieved of my responsibility for that,
thank goodness.

- --
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 20:45:01 up 6 days, 3 min, 4 users, load average: 5.48, 5.18, 5.01
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org/


More information about the Gnupg-users mailing list