Ok... since we're talking old *nix here, I thought I'd add my 2-cents
worth...
Short & sweet: The password entries for your OLD system should import to
the new one without issue. The new system will already know how to use
the OLD password format, but when users change their passwords, the NEW
ones will be stored in the $1$ (MD5) format automatically.
How or Why you ask? read on... (otherwise, just accept that you don't
have to do anything else -- just import the passwords -- & move on)
The problem you describe arises from the "evolution" of storing hashed
passwords. Not encrypting -- encrypting implies that there is a DECRYPT
algorithm. Let it be known throughout the land: there is NO known way
(other than brute force "guessing") to derive a password from a stored
hashed password. NOT even from the old CRYPT format to the newer ones.
(NOTE: This is what would be necessary to "convert" the old passwords to
the newer $1$ (MD5) format.) If you have user's hashed passwords you
CANNOT convert them to another format. Not no way, not no how.
Some background: The /*original*/ (1970's) way to store passwords on
*nix systems was to store the 11-character ASCII-ized (base-64) output
of CRYPT, a DES-based hashing algorithm. The hash was created by
supplying a string of 0's as input and using your password as the hash
key: thus the 8-character limit on passwords. The hash results were
ASCII-ized (converted to Base-64 printable characters) & stored in
/etc/passwd. To check a password, you just repeat the process, using the
password-guess as the key, and if the results match, the passwords
matched & the user is authenticated. It didn't take long (into the
mid-1980's) to add a 2-character SALT to the beginning of the password
field, thus making any given password "storable" in up to 4096 different
ways.
Skip ahead to the 90's, and note that over time 3 steps have been taken
to "more better" secure *nix authentication methods: First, we moved
password data from the "MUST be publically readable" /etc/passwd to the
"not publically readable" /etc/shadow file. Then, we changed to a
stronger hash algorithm (MD5), and finally, we used the password as the
input, and used a longer/larger random value for the SALT (the odds of
getting the same SALT grew from 1-in-4096 to 1-in-nearly 280
quadrillion). Since the password itself is now the entry string (vs.
part of the key) it can be nearly ANY length (typically up to the 128
chars of the typical TTY buffer).
Because of the changes, the FORMAT of the password/shadow file had to
change: it's no longer just the ASCII-ized hash output, nor a
fixed-length SALT. Instead, the $'s are field delimiters. $1$ is tells
the system to use the MD5-based algorithm (a $2a$ value would indicate
use of the Blowfish hash algorithm). The next field (between the $s) is
the random SALT. The normal length is 8 base-64 chars, thus the 1-in-280
quadrillion chances of duplicates, but it is adjustable. The last field
(23 chars for the MD5-based algorithm) are hashed password itself.
So, as the AUTH part of a program, when I look at the stored password,
if the password field has 3 $s, then I know it's an "advanced" password.
If it is 11 chars, then I know it's an OLD password. The 13 you showed
indicates an OLD DES-type password with a 2-character SALT. In the case
of an "advanced" password, I'll need to have the appropriate hashing
algorithm for the code in the first field. (Interestingly, Mac OS-X uses
the old CRYPT with 2-SALT character method, and DOESN'T ship with the
MD5 algorithm installed. You CAN add it, but you have to add MD5 before
you reconfigure your auth configs!)
So, when the authlibs in QMail Toaster authenticate users, the encrypted
passwords can be in either:
- The original 11-character format, or
- The 13-character (2-char SALT + 11 char result) format, or
- The $1$ (MD5 advanced) format
By default (in the QMT), new passwords will be stored in the $1$ format.
I hope this helps explain WHY it'll work with BOTH kinds of passwords
simultaneously!
Dan
IT4SOHO
Myers, Jon W wrote:
________________________________________
From: Jake Vickers [EMAIL PROTECTED]
Sent: Friday, November 21, 2008 6:47 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] moving domain from old to new qmail toaster
On Thu, 2008-11-20 at 23:28 -0500, Myers, Jon W wrote:
......snipped
I'm moving a domain from a very old qmail setup (which does indeed use vpopmail) over to the new
qmail toaster box. Things look pretty straight forward, as the vpopmail database is easy to read.
The one issue that I'm not sure about is passwords. My old database has encrypted passwords with
13 characters (uppercase/lowercase/letters/numbers/special chars/etc..) (aka, not clear text). The
new database uses encrypted passwords that start with "$1$" and are i think 34 characters
long. I do remember in all my Unix days that the "$1$" denotes a particular algorithm.
So, is there an easy way to convert from the 13 character to the "$1$" flavor??
Jake wrote:
....snipped
As far as your passwords are concerned; the backup script will backup the whole
DB. The restore script will drop whatever DB for vpopmail you currently have
and import the backed up copy. In theory this should carry the passwords over,
but it will erase any data you have in the new DB so I would plan this out a
little before just jumping in.
-------
Ok, thanks for the info about the backup scripts. Sounds like they would not
work in this case, because the password formats are different. Sure, it'll
move the database, but the new vpopmail is expecting a different password
format. I'll see if I can trace through the vpopmail changelogs to see if
there is a proper way to convert between the two password encryption types.
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
