Re: [Pam-mysql-general] /etc/shadow -> mysql-pam Migration

[Oded A. <ode...@ty...>]

On Sunday, 2 =D7=91April 2006 19:59, Georg Wicherski wrote:
> we want to migrate the authentification mechanism in our organization
> from one central /etc/shadow file to pam-mysql. The problem I see
> here is that we use all different kind of hashes mixed in /etc/shadow
> (grown structures and such) ranging from DES to MD5. We would like to
> avoid forcing all users to retype their passwords.
>
> Is it possible to just copy the hash fields from /etc/shadow in the
> respective MySQL columns, set crypt=3DY and continue using it that way?
> How could we then enforce new / changed passwords would use SHA1?

I had a similar problem where I want to migrate from old mysql hashed=20
passwords to new mysql hashed passwords and then to sha1. My solution=20
was to setup, for each pam service, multiple auth handlers (with=20
use_first_pass) where the first auth handler was "required" and all=20
others where "sufficient". I don't know why, but for some reason it=20
works - it tries to auth with each handler and if one succeeds then you=20
can login but if all fail then you are locked out.

You then setup your password changing interface to use only sha1 for=20
setting the passwords - for this I used the pam passwd service which is=20
setup only for sha1.

=46or extra credit, I hacked pam-mysql to log the logged-in cleartext=20
password into a database table, and a scheduled background job uses the=20
clear text to create a new sha1 hashed password - so that over time all=20
the users will migrate to the sha1 storage even if they don't change=20
their passwords regularly, and it will allow you to dispose of the=20
duplicate auth setup at a later date. On the face of it, not that=20
secure, but with proper permissions and frequent runs of the rehasher=20
job the risk can be controlled.

=2D-=20
Oded

::..
"To sit alone with my conscience will be judgment enough for me."=20
	-- Charles William Stubbs