X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C87A53.C43E60E6@onstor-exch02.onstor.net>; Thu, 28 Feb 2008 14:49:17 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Cougar migration issue
Date: Thu, 28 Feb 2008 14:49:16 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E089F1773@onstor-exch02.onstor.net>
In-Reply-To: <20080228133140.2f08277e@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cougar migration issue
Thread-Index: Ach6UU62Va4useWvRsC94Gjm5lXoWwAAkTVg
References: <BB375AF679D4A34E9CA8DFA650E2B04E04344BF1@onstor-exch02.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E12BFA8@onstor-exch02.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E089F1523@onstor-exch02.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E089F1569@onstor-exch02.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E089F15B9@onstor-exch02.onstor.net> <20080228133140.2f08277e@ripper.onstor.net>
From: "Eric Barrett" <eric.barrett@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Narain Ramadass" <narain.ramadass@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>,
	"dl-Cougar" <dl-Cougar@onstor.com>,
	"Sripal Surendiran (HCL)" <sripal.surendiran@onstor.com>,
	"Sudharsan Srinivasan" <sudharsan@onstor.com>

Get this -- setting a new root password is not only not encouraged, it's
*not supported*.  Support will help customers who want to do it, but
it's officially not an allowed procedure.  I absolutely agree that
changing it should be a requirement of installation.


-----Original Message-----
From: Andy Sharp=20
Sent: Thursday, February 28, 2008 1:32 PM
To: Eric Barrett
Cc: Narain Ramadass; Tim Gardner; dl-Cougar; Sripal Surendiran (HCL);
Sudharsan Srinivasan
Subject: Re: Cougar migration issue

On Thu, 28 Feb 2008 10:05:35 -0800 "Eric Barrett"
<eric.barrett@onstor.com> wrote:

> Well, crypt() is one-way -- so we don't know the password.  (crypt()
> is a misnomer; it's actually generating a hash.)  Password

I think hash is the misnomer, but anyway....

The security hole only exists for the moment that we are doing the
migration and we ask the user to enter new passwords because we can't
verify the old ones.  Ideally what we want to do is ask the user to
enter the old passwords, verify they are correct, and then set the
new passwd/shadow entries appropriately.  But reasons of practicality
all we can do is prompt the user for new ones and "trust" that the user
doing the migration is not a malicious hacker on the loose bent on
creating an FMD (Filer of Mass Distruction).

I don't see any reason to not prompt the user for new passwords at
migration time.  I think someone mentioned just leaving the system
with default passwords and hope the customer remembers to change them or
read the migration guide and change them.  No reason I can think of to
take that route.

> authentication works by hashing the password the user typed in and
> seeing if it matches the hash that's on record.  In a comptent
> password scheme, you can't go from the hash back to the plaintext.
>=20
> Even on BSD, we can't convert the Blowfish hash over to MD5, because
> that would require knowing the original plaintext.  (Unless there's
> some cryptological wiz-fu I'm missing here.)  You can really only
> implement Blowfish as a PAM module (I'm assuming), or go with what
> Tim suggested and have the users re-type all passwords.  I'd favor
> the former but of course it would require time which we may not have
> -- not my call.

There's only two passwords at play here, root and admin.  Shouldn't be
a big deal.

BTW, I crossed paths with someone who knows how to search for such
things, and he showed me a web site that listed our default root
password.  Is there any part of our FTI or migration process that
forces the customer to set a new root password?  It's very important
that we do that.
