You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2001/09/22 19:47:34 UTC
[PATCH] apr_password_validate with LIBEAY des_fcrypt support
Hi,
Couple of months ago I've posted a patch that enables WIN32 to deal with
crypt() encrypted passwords.
Here is a patch that uses dso to load a libeay32.dll from openssl an enables
apr to validate a password using des_fcrypt.
It would be much easier to implent that enhancement if apr_password_validate
function will has the apr_pool_t as a parameter.
Index: apr_md5.c
===================================================================
RCS file: /home/cvspublic/apr/passwd/apr_md5.c,v
retrieving revision 1.15
diff -u -r1.15 apr_md5.c
--- apr_md5.c 2001/08/06 15:46:04 1.15
+++ apr_md5.c 2001/09/22 17:29:07
@@ -101,6 +101,7 @@
#include "apr_strings.h"
#include "apr_md5.h"
#include "apr_lib.h"
+#include "apr_dso.h"
#if APR_HAVE_STRING_H
#include <string.h>
@@ -669,6 +670,12 @@
return APR_SUCCESS;
}
+#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
+typedef char* (*fp_des_fcrypt)(const char *,const char *, char *);
+static int passwd_pool_initialized = 0;
+static apr_pool_t *passwd_apr_pool;
+#define LIBEAY_DSO_NAME "libeay32"
+#endif
/*
* Validate a plaintext password against a smashed one. Use either
* crypt() (if available) or apr_md5_encode(), depending upon the format
@@ -680,7 +687,10 @@
const char *hash)
{
char sample[120];
-#if !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
+#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
+ static apr_dso_handle_t *libeay;
+ static fp_des_fcrypt des_fcrypt = NULL;
+#else
char *crypt_pw;
#endif
if (!strncmp(hash, apr1_id, strlen(apr1_id))) {
@@ -694,7 +704,20 @@
* It's not our algorithm, so feed it to crypt() if possible.
*/
#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
- apr_cpystrn(sample, passwd, sizeof(sample) - 1);
+ /* It would be better to get the pool from the function call */
+ if (!passwd_pool_initialized) {
+ if (apr_pool_create(&passwd_apr_pool, NULL) != APR_SUCCESS) {
+ return APR_ENOPOOL;
+ }
+ ++passwd_pool_initialized;
+ if (apr_dso_load(&libeay, LIBEAY_DSO_NAME, passwd_apr_pool) ==
APR_SUCCESS)
+ if (apr_dso_sym((void **)&des_fcrypt, libeay, "des_fcrypt")
!= APR_SUCCESS)
+ des_fcrypt = NULL;
+ }
+ if (des_fcrypt)
+ apr_cpystrn(sample, (des_fcrypt)(passwd, hash, sample),
sizeof(sample) - 1);
+ else
+ apr_cpystrn(sample, passwd, sizeof(sample) - 1);
#else
crypt_pw = crypt(passwd, hash);
apr_cpystrn(sample, crypt_pw, sizeof(sample) - 1);
MT.
Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 24 September 2001 12:42 pm, Mladen Turk wrote:
> > > > I dislike this. My concern is that if you take the same binary to
>
> 2
>
> > > > different Windows machines, you will get two different results.
>
> [Mladen Turk]
> Don't we always do :-) ?
>
> > > > I would prefer to just have APR always use md5 hashes to protect
>
> passwords. We
>
> > > > could basically just document the des option as depricated, and
>
> only
>
> > > > provided for backwards compat with older systems.
>
> [Mladen Turk]
> OK. I can accept that. But could you guys vote on that or whatever is
> needed to make a decision, so that someone willing to help doesn't waste
> time going into dead ends. I don't recall seeing that thoughts before.
The problem is that I didn't start thinking about this problem until this patch.
This is kind of what happens, most of us can't really handle all of the
bandwidth on the list, so we try to keep an eye on all of the e-mail, but
for the most part we skim it. Then, when things get closer to fruition, we
try to make sure we see what is happening. At least that is what I have
been forced to do because of time constraints recently.
> On the other hand why not be able to be a backward compatible on WIN
> too? That is the purpose of the patch I wrote, to enable you to be a
> compatible if that's what you _want_.
But we have never supported DES on Win32, so that doesn't really fit under
backwards compat.
> Backward compatibility IMO should be defined in compile time and stated
> as such in the documentation, so my suggestion is to drop the crypt from
> other platforms too, and live it as a compile-time option, and the
> password validation would be consistent on all platforms.
That is a very valid option. Let's hear what other people think, and I will
implement it next week, unless there is a veto.
> > > Huh? Are you suggesting that des is depricated on Win32, or _ALL_
> > > platforms?
> >
> > I'm suggesting that DES is depricated on all platforms, but APR still
>
> provides
>
> > a way to use DES on non-windows platforms, for backwards compat.
>
> [Mladen Turk]
> If MD5 hashing is going to be the only core password protection, then we
> should drop all the other algorithms from the htpasswd utility too.
> Further more IMO if there is passwd_verify then there should be
> passwd_make, just like there is file_create and file_delete. That would
> require only couple of lines of code to wrap the apr_md5_encode, and
> made password management utils a lot simpler and cleaner from user point
> of view.
I need to look at how that would work, but I think it is probably a good idea.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
RE: [PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 23. rujan 2001 17:09
> To: William A. Rowe, Jr.; Mladen Turk; Justin Erenkrantz
> Cc: APR Dev List
> Subject: Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt
support take 2
> > > > Nothing happens!
> > > > It falls back to the original behavior if the dll coudn't be
loaded at
> > > > runtime.
> > >
> > > I dislike this. My concern is that if you take the same binary to
2
> > > different Windows machines, you will get two different results.
[Mladen Turk]
Don't we always do :-) ?
> > > I would prefer to just have APR always use md5 hashes to protect
passwords. We
> > > could basically just document the des option as depricated, and
only
> > > provided for backwards compat with older systems.
[Mladen Turk]
OK. I can accept that. But could you guys vote on that or whatever is
needed to make a decision, so that someone willing to help doesn't waste
time going into dead ends. I don't recall seeing that thoughts before.
On the other hand why not be able to be a backward compatible on WIN
too? That is the purpose of the patch I wrote, to enable you to be a
compatible if that's what you _want_.
Backward compatibility IMO should be defined in compile time and stated
as such in the documentation, so my suggestion is to drop the crypt from
other platforms too, and live it as a compile-time option, and the
password validation would be consistent on all platforms.
> >
> > Huh? Are you suggesting that des is depricated on Win32, or _ALL_
> > platforms?
>
> I'm suggesting that DES is depricated on all platforms, but APR still
provides
> a way to use DES on non-windows platforms, for backwards compat.
[Mladen Turk]
If MD5 hashing is going to be the only core password protection, then we
should drop all the other algorithms from the htpasswd utility too.
Further more IMO if there is passwd_verify then there should be
passwd_make, just like there is file_create and file_delete. That would
require only couple of lines of code to wrap the apr_md5_encode, and
made password management utils a lot simpler and cleaner from user point
of view.
MT.
Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Posted by Ryan Bloom <rb...@covalent.net>.
On Sunday 23 September 2001 05:04 pm, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <rb...@covalent.net>
> Sent: Sunday, September 23, 2001 4:16 PM
>
> > On Sunday 23 September 2001 01:24 am, Mladen Turk wrote:
> > > > -----Original Message-----
> > > > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > > > Sent: Sunday, September 23, 2001 12:51 AM
> > > > To: Mladen Turk
> > > > Cc: APR Dev List
> > > > Subject: Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt
> > > > support
> > > >
> > > > > Here is a patch that uses dso to load a libeay32.dll from
> > > >
> > > > openssl an enables
> > > >
> > > > > apr to validate a password using des_fcrypt.
> > > >
> > > > What happens if this dll is not available? I don't think we're
> > > > enforcing users to have OpenSSL.
> > >
> > > Nothing happens!
> > > It falls back to the original behavior if the dll coudn't be loaded at
> > > runtime.
> >
> > I dislike this. My concern is that if you take the same binary to 2
> > different Windows machines, you will get two different results. I would
> > prefer to just have APR always use md5 hashes to protect passwords. We
> > could basically just document the des option as depricated, and only
> > provided for backwards compat with older systems.
>
> Huh? Are you suggesting that des is depricated on Win32, or _ALL_
> platforms?
I'm suggesting that DES is depricated on all platforms, but APR still provides
a way to use DES on non-windows platforms, for backwards compat.
> > If we do this, then we shouldn't need DES on Windows.
>
> True.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Sunday, September 23, 2001 4:16 PM
> On Sunday 23 September 2001 01:24 am, Mladen Turk wrote:
> > > -----Original Message-----
> > > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > > Sent: Sunday, September 23, 2001 12:51 AM
> > > To: Mladen Turk
> > > Cc: APR Dev List
> > > Subject: Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support
> > >
> > > > Here is a patch that uses dso to load a libeay32.dll from
> > >
> > > openssl an enables
> > >
> > > > apr to validate a password using des_fcrypt.
> > >
> > > What happens if this dll is not available? I don't think we're
> > > enforcing users to have OpenSSL.
> >
> > Nothing happens!
> > It falls back to the original behavior if the dll coudn't be loaded at
> > runtime.
>
> I dislike this. My concern is that if you take the same binary to 2 different
> Windows machines, you will get two different results. I would prefer to just
> have APR always use md5 hashes to protect passwords. We could basically
> just document the des option as depricated, and only provided for backwards
> compat with older systems.
Huh? Are you suggesting that des is depricated on Win32, or _ALL_ platforms?
> If we do this, then we shouldn't need DES on Windows.
True.
Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Posted by Ryan Bloom <rb...@covalent.net>.
On Sunday 23 September 2001 01:24 am, Mladen Turk wrote:
> > -----Original Message-----
> > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > Sent: Sunday, September 23, 2001 12:51 AM
> > To: Mladen Turk
> > Cc: APR Dev List
> > Subject: Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support
> >
> > > Here is a patch that uses dso to load a libeay32.dll from
> >
> > openssl an enables
> >
> > > apr to validate a password using des_fcrypt.
> >
> > What happens if this dll is not available? I don't think we're
> > enforcing users to have OpenSSL.
>
> Nothing happens!
> It falls back to the original behavior if the dll coudn't be loaded at
> runtime.
I dislike this. My concern is that if you take the same binary to 2 different
Windows machines, you will get two different results. I would prefer to just
have APR always use md5 hashes to protect passwords. We could basically
just document the des option as depricated, and only provided for backwards
compat with older systems.
If we do this, then we shouldn't need DES on Windows.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
[PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: Sunday, September 23, 2001 12:51 AM
> To: Mladen Turk
> Cc: APR Dev List
> Subject: Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support
> > Here is a patch that uses dso to load a libeay32.dll from
> openssl an enables
> > apr to validate a password using des_fcrypt.
>
> What happens if this dll is not available? I don't think we're
> enforcing users to have OpenSSL.
Nothing happens!
It falls back to the original behavior if the dll coudn't be loaded at
runtime.
> > It would be much easier to implent that enhancement if
> apr_password_validate
> > function will has the apr_pool_t as a parameter.
> If it is needed, now is the time to do it before we freeze the API.
Well, I'm creating right now an extra static pool when the apr_password get
called for the first time.
The solution is to use either the pool that could come from function call or
to use the global pool from apr_initialize.
I was thinking to load the libeay32.dll inside the apr_initialize function.
Using that approach an extra pool will not be needed.
Here is the solution that doesn't require API changes. It's much more
simpler but requires apr_initialize patch.
Index: start.c
===================================================================
RCS file: /home/cvspublic/apr/misc/unix/start.c,v
retrieving revision 1.53
diff -u -r1.53 start.c
--- start.c 2001/08/31 06:07:34 1.53
+++ start.c 2001/09/23 08:03:35
@@ -60,11 +60,16 @@
#include "misc.h" /* for WSAHighByte / WSALowByte */
#include "locks.h" /* for apr_unix_setup_lock() */
#include "internal_time.h"
+#include "dso.h"
-
static int initialized = 0;
static apr_pool_t *global_apr_pool;
+typedef char* (*fp_des_fcrypt)(const char *,const char *, char *);
+static apr_dso_handle_t *libeay;
+fp_des_fcrypt des_fcrypt = NULL;
+#define LIBEAY_DSO_NAME "libeay32"
+
APR_DECLARE(apr_status_t) apr_initialize(void)
{
apr_status_t status;
@@ -100,6 +105,12 @@
if ((status = apr_pool_alloc_init(global_apr_pool)) != APR_SUCCESS)
return status;
+
+#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
+ if (apr_dso_load(&libeay, LIBEAY_DSO_NAME, global_apr_pool) ==
APR_SUCCESS)
+ if (apr_dso_sym((void **)&des_fcrypt, libeay, "des_fcrypt") !=
APR_SUCCESS)
+ des_fcrypt = NULL;
+#endif
apr_signal_init(global_apr_pool);
Index: apr_md5.c
===================================================================
RCS file: /home/cvspublic/apr/passwd/apr_md5.c,v
retrieving revision 1.15
diff -u -r1.15 apr_md5.c
--- apr_md5.c 2001/08/06 15:46:04 1.15
+++ apr_md5.c 2001/09/23 08:04:21
@@ -101,6 +101,7 @@
#include "apr_strings.h"
#include "apr_md5.h"
#include "apr_lib.h"
+#include "apr_dso.h"
#if APR_HAVE_STRING_H
#include <string.h>
@@ -669,6 +670,10 @@
return APR_SUCCESS;
}
+#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
+typedef char* (*fp_des_fcrypt)(const char *,const char *, char *);
+extern fp_des_fcrypt des_fcrypt;
+#endif
/*
* Validate a plaintext password against a smashed one. Use either
* crypt() (if available) or apr_md5_encode(), depending upon the format
@@ -694,7 +699,10 @@
* It's not our algorithm, so feed it to crypt() if possible.
*/
#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
- apr_cpystrn(sample, passwd, sizeof(sample) - 1);
+ if (des_fcrypt)
+ apr_cpystrn(sample, (des_fcrypt)(passwd, hash, sample),
sizeof(sample) - 1);
+ else
+ apr_cpystrn(sample, passwd, sizeof(sample) - 1);
#else
crypt_pw = crypt(passwd, hash);
apr_cpystrn(sample, crypt_pw, sizeof(sample) - 1);
MT.
Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt support
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Sep 22, 2001 at 07:47:34PM +0200, Mladen Turk wrote:
> Here is a patch that uses dso to load a libeay32.dll from openssl an enables
> apr to validate a password using des_fcrypt.
What happens if this dll is not available? I don't think we're
enforcing users to have OpenSSL.
> It would be much easier to implent that enhancement if apr_password_validate
> function will has the apr_pool_t as a parameter.
If it is needed, now is the time to do it before we freeze the API.
-- justin