Final Word on the Password Problem

[Bill Vermillion]

On Tue, Jul 13 09:54 , Nancy Palmquist gie sprachen "Vyizdur zomen 
emororz izaziz zander izorziz", and continued with: 

> Here is my reply to my esteemed colleagues points and arguments:

[Much snipped - wjv]

> 5) Bob & Mark - I know that Unix will accept a long password
> but will only respect the first part of it. I know I assigned a
> very long password as the root password on a Unix system, such
> as "McDonaldSalesCompany". I have easily been able to login
> with only "McDonaldSales" with no problem. Not sure how many
> other letters I can drop to gain access.

What you knew about old Unix systems is not true of moden Unix
systems.  At one time no matter how long the password was only
the first 8 characters were used.  Unix systems and the world have
changed greatly in the past 10 years.  The DES encryption - still
used in some systems - it easy to crack with hardware off the
shelf.   DES uses only 4096 salts.   Far too few when cmoputers
are runing well past 3GHz.  

I just tested on one of my BSD server machines and changed a
20 character password to 33 characters and if you tried anything
less it failed.  The password limit is 128 characters on these
machines.  And if you do put in a password that long it MUST
be entered at that length.

And many system have changed from DES to MD5 with a few using
Bluefish.

This system is using MD5 - and I just computed that the number
of salts is a bit over 284 trillion.  The salts are still
in base-64 as in DES, but instead of 64^2 the MD5 default
id 64^8.

Those give sufficiently encrypted passwords that breakage is
unlikely unless the file with what is normallyh called 'the
encrypted password' is retreived.

Then all you have to do is use the 8 character salt to run against
common passwords and then compare with the stored 22 character
MD5 file.   

In the above line where I say 'encrypted password' it really isn't
that.  It is just the result for running the algorithms on the
password entered - and you run an entered password with the salt
from the file to see if the result matches that stored in the file.
There is no guarantee that any other string might match that
strings, but the odd are almost astronomical of finding one.

> BTW I did this to make it difficult for the customer to log in
> as root. IT did not stop them. And Mark before you panic, and
> post that the password is too easy to figure out, this system
> is totally internal and has no access to the outside world,
> you can't get too much more secure than that with regard to
> hackers.

In this day and age that is a rarity. A long time ago I had a Xenix
system that I got called from home at 630AM.   It turns out there
was NO password on the system.  When I asked why they said "we dont
want to bother with them".

I explained that if during bootup and if there is no password,
when the system comes up and says 'enter root password for
mainatence' or press enter to continue, that when you press enter
on a no-password machine it goes into single user mode.

The could not figure out why the console worked but nothing else
did.  So I told them to put in a root password, and if they liked
they could paste it to the monitor so they didnt' forget it.

They realized that their insistance of no-password to the person
who installed the machine had just cost them a decent amount of
money as 630AM calls - before my normal wakeup - get charged a
premium.

So that machine is pretty secure.  However - if it is on a local
network - and any of the other machines have outside access - make
sure they are well protected so that someone doesn't jump through
one machine to get to another.


> Employees own the place and in the 20
> years we have worked with them, no one has ever even tried to bother
> with the operating system.  Most stable computer system I ever
> installed.  They call to to ask how to reboot since they do it only
> every few years.  Love that Unix stuff.

I've had that too - and sometimes I get "Last time you were here
you did xxxx, could you do it again".  And there have been many
other machines in the interveing years and it's hard to remember
what I did on that specific machine.

If they are running older unpatches SCO's they need to reboot twice
each year - as there is a timer that overflows because it was
compiled as a signed int.  It's about 286 days when the timer goes
negative.  I'd tell my SCO customers to reboot for the holidays
every 4th of July and Christmas.  Newer versions don't have the
problem.

Bill
-- 
Bill Vermillion - bv @ wjv . com