summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: f1fd6cf)
raw | patch | inline | side by side (parent: f1fd6cf)
author | hickert <hickert@594d385d-05f5-0310-b6e9-bd551577e9d8> | |
Thu, 19 Jul 2007 05:51:52 +0000 (05:51 +0000) | ||
committer | hickert <hickert@594d385d-05f5-0310-b6e9-bd551577e9d8> | |
Thu, 19 Jul 2007 05:51:52 +0000 (05:51 +0000) |
Updated password method hash names to uppercase :
{crypt} to {CRYPT} and so on
TICKET DESC :
Currently some password classes use a lowercase password hashing scheme string in the userPassword attribute whilst others use an uppercase hashing string. rfc2307 and rfc2307bis do not dictate a standard but the uppercase string is a representation that is being used historically by different vendors, including OpenLDAP itself.
I propose to use uppercase everywhere (see attached patch). Since openldap/slapppaswd uses the uppercase notation itself I do not suspect any regressions on any deployed systems will occur.
I know of an application that syncs passwords from LDAP for internal usage and trips over lowercase representation (which is a bug in that program ;-) ). That bug showed me that GOsa didn't handle this consistently.
git-svn-id: https://oss.gonicus.de/repositories/gosa/trunk@6916 594d385d-05f5-0310-b6e9-bd551577e9d8
{crypt} to {CRYPT} and so on
TICKET DESC :
Currently some password classes use a lowercase password hashing scheme string in the userPassword attribute whilst others use an uppercase hashing string. rfc2307 and rfc2307bis do not dictate a standard but the uppercase string is a representation that is being used historically by different vendors, including OpenLDAP itself.
I propose to use uppercase everywhere (see attached patch). Since openldap/slapppaswd uses the uppercase notation itself I do not suspect any regressions on any deployed systems will occur.
I know of an application that syncs passwords from LDAP for internal usage and trips over lowercase representation (which is a bug in that program ;-) ). That bug showed me that GOsa didn't handle this consistently.
git-svn-id: https://oss.gonicus.de/repositories/gosa/trunk@6916 594d385d-05f5-0310-b6e9-bd551577e9d8
include/class_password-methods-crypt.inc | patch | blob | history | |
include/class_password-methods-md5.inc | patch | blob | history | |
include/class_password-methods-ssha.inc | patch | blob | history |
index c3d21c8b459ed958299380681a97fc04f93194fb..28cda87e04f7bf496a09e19a7343189de7c5cf41 100644 (file)
function generate_hash($pwd)
{
- return "{crypt}".crypt($pwd, substr(session_id(),0,2));
+ return "{CRYPT}".crypt($pwd, substr(session_id(),0,2));
}
}
index caf714753a401749875bec2d7965fda20c731c84..43b3ec74c5b9811b6ddfe8163ff70ee53268401e 100644 (file)
function generate_hash($pwd)
{
- return "{md5}".base64_encode( pack('H*', md5($pwd)));
+ return "{MD5}".base64_encode( pack('H*', md5($pwd)));
}
}
index e80e566514f365fde1aabf880fd75519af6e0bc6..1f68192726b69a88c148677dd854daed2e4261f3 100644 (file)
if (function_exists("sha1")) {
$salt= substr(pack("h*", md5(mt_rand())), 0, 8);
$salt= substr(pack("H*", sha1($salt.$pwd)), 0, 4);
- $pwd= "{ssha}".base64_encode(pack("H*", sha1($pwd.$salt)).$salt);
+ $pwd= "{SSHA}".base64_encode(pack("H*", sha1($pwd.$salt)).$salt);
return $pwd;
} elseif(function_exists("mhash")) {
$salt=mhash_keygen_s2k(MHASH_SHA1,$pwd, substr(pack("h*",md5(mt_rand())),0,8),4);
- $pwd= "{ssha}".base64_encode(mhash(MHASH_SHA1, $pwd.$salt).$salt);
+ $pwd= "{SSHA}".base64_encode(mhash(MHASH_SHA1, $pwd.$salt).$salt);
} else {
print_red(_("Can't use ssha for encryption. (Missing function mhash / sha1)"));
return(false);