src/lib/libcrypt/crypt.c, branch releng/9.1

MFH r236751: document sha256 / sha512 support

2012-07-15T11:39:35+00:00

MFH r236892: remove mention of auth.conf from programs that don't use it
MFH r236963: remove dead code relating to auth.conf
MFH r236965 r236966 r236967 r237005 r237006 r237011: retire auth.conf

Approved by:    re

s/shaN_crypt/crypt_shaN/g to be a more consistent with the existing naming.

2011-05-05T01:09:42+00:00

Reviewed by:	markm

Add SHA256/512 ($5$ and $6$) to crypt(3). Used in linux-world, doesn't

2011-04-09T14:02:04+00:00

hurt us.

PR:		misc/124164
Submitted by:	KIMURA Yasuhiro < yasu utahime org >
MFC after:	1 month

Add a new hash type. This "NT-hash" is compatible with the password

2003-06-02T19:29:27+00:00

hashing scheme used in Microsoft's NT machines. IT IS NOT SECURE!
DON'T USE IT! This is for the use of competent sysadmins only!

Submitted by:	Michael Bretterklieber

No functional change, but big code cleanup. WARNS, lint(1) and style(9).

2002-03-06T17:18:09+00:00

Implement __FBSDID()

2001-09-16T21:35:07+00:00

Removed duplicate VCS ID tags, as per style(9).

2001-08-13T14:06:34+00:00

Add OpenBSD-style blowfish password hashing. This makes one less

2001-03-11T16:05:43+00:00

gratuitous difference between us and our sister project.

This was given to me _ages_ ago. May apologies to Paul for the length
of time its taken me to commit.

Obtained from:	Niels Provos /OpenBSD
Submitted by:	Paul Herman

Hindsight is wonderful, but I got cold feet over the crypt(3) default

2000-12-28T11:23:01+00:00

so I am backing it out for now.  The problem is that some random program
calling crypt() could be passing a DES salt and the crypt(3) library
would encrypt it in md5 mode and there would be a password mismatch as a
result.  I wrote a validater function for the DES code to verify that
a salt is valid for DES, but I realized there were too many strange things
to go wrong.  passwd(1), pw(8) etc still generate md5 passwords by default
for /etc/master.passwd, so this is almost academic.  It is a big deal for
things that have their own crypt(3)-ed password strings (.htaccess,
etc etc).  Those are the things I do not want to break.

My DES salt recognizer basically checked if the salt was either 2 or
13 characters long, or began with '_' (_PASSWORD_EFMT1).  I think it
would have worked but I have seen way too much crypt() mishandling
in the past.

Merge into a single US-exportable libcrypt, which only provides

2000-12-28T10:32:02+00:00

one-way hash functions for authentication purposes.  There is no more
"set the libcrypt->libXXXcrypt" nightmare.
- Undo the libmd.so hack, use -D to hide the md5c.c internals.
- Remove the symlink hacks in release/Makefile
- the algorthm is set by set_crypt_format() as before.  If this is
  not called, it tries to heuristically figure out the hash format, and
  if all else fails, it uses the optional auth.conf entry to chose the
  overall default hash.
- Since source has non-hidden crypto in it there may be some issues with
  having the source it in some countries, so preserve the "secure/*"
  division.  You can still build a des-free libcrypt library if you want
  to badly enough.  This should not be a problem in the US or exporting
  from the US as freebsd.org had notified BXA some time ago.  That makes
  this stuff re-exportable by anyone.
- For consistancy, the default in absence of any other clues is md5.  This
  is to try and minimize POLA across buildworld where folk may suddenly
  be activating des-crypt()-hash support.  Since the des hash may not
  always be present, it seemed sensible to make the stronger md5 algorithm
  the default.
All things being equal, no functionality is lost.

Reviewed-by: jkh

(flame-proof suit on)