[TYPO3-core] RFC: Feature Request #7139: Integration of fe_users password encryption

Ernesto Baschny [cron IT] ernst at cron-it.de
Tue Jan 15 19:10:45 CET 2008


Steffen Kamper wrote: on 15.01.2008 00:41:

> Ok. I had a first look to that. There are some issues have to be respected.
> 
> - method for salted password compare should be general in 
> t3lib_userauth::compareUident to have no doublecoding for the same method 
> (BE & FE)
> - method for generate salt should be a static method, maybe t3lib_div, as 
> it's needed in tceforms and other places. I like Ingmars+Dmitry's proposal 
> to generate it the way
> $saltKey = uniqid('',true);
> $password = (string)md5($password . $saltKey) . '@' . $saltKey;

Please consider here that md5 works with bytes, but the user input is 
encoded in some way. This is hopefully UTF8 on any new installation, but 
there might be people wanting to migrate "latin-1" based sites to UTF-8. 
Without considering this, any password with non-ASCII characters won't 
work when migrating. This might even be a problem if the BE has multiple 
character sets, depending on the users language setting.

So my idea would be to anways hash the UTF-8 version of the password (we 
have good methods for conversion in core already), so that it doesn't 
matter what BE-character encoding the user is using.

> or should it be like the configvar i introduced in this patch to have three 
> states
> $TYPO3_CONF_VARS['FE']['passwordType'] = 'plain|md5|salt';
> Then it would make sense to use the same for BE (without plain)
> $TYPO3_CONF_VARS['BE']['passwordType'] = 'md5|salt';

As Ingmar already wrote, md5_salt is more precise, because we later 
might want to have blowfish_salt or other "salted" methods.

Cheers,
Ernesto


More information about the TYPO3-team-core mailing list