Passwords

[David G. Koontz]

In article <BZS.91Apr15150237 at world.std.com> bzs at world.std.com (Barry Shein) writes:


>Years ago I suggested on this list that vendors modify the password
>algorithm so that at system installation a key could be entered which
>perturbs its behavior on a per-machine basis (obviously a system admin
>could choose to use the same key on every machine in an area so
>password files could be shared.) This would frustrate the possibility
>of someone on the outside picking up the encryptions and working on it
>on another machine.

>The hostname isn't a great idea because everyone knows the hostname.
>I'd lean towards a key that was entered (possibly into NVRAM, tho
>other schemes could be devised) when the system was installed.

>From there on it would just be automatically used to encrypt tries.

>Standardization is a wonderful thing, but perhaps some things just
>shouldn't be so standardized.

It doesn't follow that having a secondary keying feature to 
differentiate password algorithms between different machines in 
the same community provides any security.  Without enforcement a
user is likely to use the same password on two different machines.

With salting, as with a secondary keying feature, the password file
entry passwd would more than likely be unique.  Finding the password
on any of the machines in a community would encourage the hacker
to try that same plaintext (read source) password on another machine
with the same user name.

With the availability to the nonprivledged user of such commands
as makekey or libcrypt (which is used by programs to verify access
to a user by comparing the encrypted password entry to one supplied
by the user and encrypted) make secondary keying variables such
as using a non ZERO value for the initial data value in crypt(3)
risky cryptographically.  Imagine if you will that the identity
for a crypt() call is the returned value for a NULL salt and NULL
password.

Even easier, a disassembler will tell you what the value is.

Non public password files seem a better solution.  They tend to
be harder to get to, in general requiring a sys admin error.
Sun Micros hidden password system requires root privledge to get
a password entry (even your own).  A public password file can
be used for verification by a program not owned by root.

It would be nice if the same password were not used in both.