[plug] Apache & htpasswd

[Simon Scott]

	how hard would it actually be to rebuild the password file? It would
be the quickest way out, and you should change the passwords regularly
anyway.

	Perhaps change everyone's password to their birthdate, and write a
password change script to get them to set their own password?

	I dont know which would be more insecure - changing everyone's
password to their birthdate temporarily or leaving everyone to use the same
password forever.



	From:	Brian Tombleson <brian at paradigmit.com.au> on 21-05-2001
11:27 AM
	Please respond to plug at plug.linux.org.au@SMTP at Exchange
	To:	plug at plug.linux.org.au@SMTP at Exchange
	cc:	 

	Subject:	Re: [plug] Apache & htpasswd

	Hi Christian,

	Appreciate you trying, but I have more questions :) ..

	From: "Christian" <christian at amnet.net.au>
	> On Mon, May 21, 2001 at 09:30:50AM +0800, Brian Tombleson wrote:
	> > error_log entry:
	> > [Sun May 20 10:08:59 2001] [error] [client 203.59.147.233] user
junior:
	> > authentication failure for "/restricted/toolbar_restricted.htm":
	password
	> > mismatch

	<snip>

	> The final option is to use the crypt() library function which is
	> basically the same hashing algorithm used for user's login
passwords on
	> the system.  Although from my quick skim of the manual page I
can't find
	> this stated, I have a feeling that this is the default algorithm
so if
	> you've just been using htpasswd without either of the other
command line
	> options then your passwords are probably hashed with this.

	I believe this to be the case also.

	> Now, I'm almost 100% positive that Apache includes some
information at
	> the start of the hash in the password file that identifies which
hash
	> was used (the same way as in /etc/shadow).  What this means is
that it
	> shouldn't just randomly fail if one of the different hash
algorithms
	> mentioned above has been used since the program can tell how the
	> password was hashed and automatically use the correct algorithm.

	The /etc/shadow does include information at the start of the
password
	string, presumably a reference to the encryption algorithm.
Unfortunately,
	the current apache htpasswd file does not, although it can when you
change
	algorithm via the switches.

	Password Entry from the old schema (majority in this format)
	junior:jutt65bRqol9h9SQRsNR5aX/

	A different one from old schema (some in this format):
	test1:4Ot32i2AbtEQo

	New one added with -m param
	testing:$apr1$f8039/..$uXy6ZEf8z9m7OCZDxVVME.

	New one added with -s param
	testing:{SHA}GvF+c3IdvgxAARuC7Uuxp9vjzik=

	New one added with -d param
	testing:6P/OqUAOM4ykY

	New one added with no htpasswd params.
	testing:LMevUHwLm/bOw

	From this and looking at man 3 crypt (".. encrypted  password ..  a
series
	of 13 printable ASCII characters .."), I'd say that the current
system is
	using the system's crypt() routine by default and the old system was
at one
	stage using the same and then changed to the alternative 3DES
encryption.
	It also means that changing to MD5 or SHA isn't the answer. What a
mess :(

	<snip assuming MD5 - which it's not>

	> The only real solution would be to configure the new system to use
the
	> older DES-based crypt().  This means that user passwords on the
system
	> will be restricted to 8 characters or less and will be slightly
easier
	> to break using a dictionary attack.  Otherwise it should be
business as
	> usual.  You can change the system's crypt() algorithm either by
editing
	> /etc/login.defs and disabling MD5_CRYPT_ENAB or editing
/etc/pam.d/login
	> and removing the reference to 'md5' in the password entry.

	Hmm .. well, there's no references in /etc/login.defs appropriate,
and
	/etc/pam.d/login seems to externalize the authentication config to
	/etc/pam.d/system-auth.
	Here are the two files :

	[root /etc/pam.d]#cat login
	#%PAM-1.0
	auth       required     /lib/security/pam_securetty.so
	auth       required     /lib/security/pam_stack.so
service=system-auth
	auth       required     /lib/security/pam_nologin.so
	account    required     /lib/security/pam_stack.so
service=system-auth
	password   required     /lib/security/pam_stack.so
service=system-auth
	session    required     /lib/security/pam_stack.so
service=system-auth
	session    optional     /lib/security/pam_console.so

	[root /etc/pam.d]#cat system-auth
	#%PAM-1.0
	# This file is auto-generated.
	# User changes will be destroyed the next time authconfig is run.
	auth        sufficient    /lib/security/pam_unix.so likeauth nullok
md5
	shadow
	auth        required      /lib/security/pam_deny.so
	account     sufficient    /lib/security/pam_unix.so
	account     required      /lib/security/pam_deny.so
	password    required      /lib/security/pam_cracklib.so retry=3
	password    sufficient    /lib/security/pam_unix.so nullok
use_authtok md5
	shadow
	password    required      /lib/security/pam_deny.so
	session     required      /lib/security/pam_limits.so
	session     required      /lib/security/pam_unix.so

	The authconfig(8) manpage doesn't mention anything about config of
crypt(),
	just the system-level authorization config.  I'm confused over
whether this
	is relevant or not (?)

	> Of course, it could easily be something completely different...
I'm
	> assuming you've checked other things like the versions of the
server
	> software etc.  Also, try adding a new user to your htpasswd file
and see
	> if you can log in as this user.  Also, compare the first part of
the
	> password hash for the new user against the older users.  For
memory the
	> part of the hash between the $'s identifies the hashing algorithm
used.

	If I add a new user to this htpasswd file, they authorize correctly
- ie.
	correct password allows, incorrect password fails.

	So what I think I need is the same version of crypt() (or compile
apache
	with this mechabism) that is configurable to generate 24-character
encrypted
	password strings instead of the 13-character that it currently is.

	I have alooked through all the compile options in apache and can't
find
	anything related to this apart from switching to MD5 - which is not
a
	solution.

	Can anyone help me further?

	- Brian.





**********************************************************************
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************