*lock* considered empty?

[Darren J Moffat]

On Sat, 18 Oct 2003, Jeff A. Earickson wrote:

>    This logic seems really fragile.  For crypt() based passwords,

What is fragile is the method of overloading the password field with
account status information.  Ideally locked should have been a separate
boolean all together.  In some systems it could be implemented that way
(eg if using things like PAM or BSD-Auth) but history means that at least
for the forseable future there is that overloading.

> I would think that "anything not 13 chars long is locked".  Isn't
> MD5 also a fixed length too, with the same idea?

An equally fragile assumption.  For example on Solaris 9 update 2 there
is the following:

NP	- Not Participating in UNIX authentication
	- Used to allow an account to run cron jobs or login with SSH
	  public-key but not with a UNIX password.
*LK*	- Locked
	  Can not be authenticated to with UNIX and should not be used
	  for running any processes.
	  It is really *LK* as a prefix that we check not just "*LK*".
*NP*	- No permission to read the password field (NIS+ or LDAP)
$1$....	- BSD MD5 crypt passwords
$2a$...	- BSD Blowfish crypt passwords
$md5$..	- Sun (Alec Muffett) MD5 crypt passwords

The crypt(3c) [ and crypt_gensalt(3c) ] interface is extensible (without
requring access to the source) via crypt.conf(4).

--
Darren J Moffat