Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

Setting Security it use sha1 but no salt.


Go to End


3 Posts   3280 Views

Avatar
Josh

SilverStripe Developer, 65 Posts

30 April 2008 at 4:34pm

Edited: 30/04/2008 6:08pm

Hey,

I'm trying to migrate a site from a CMS that uses straight SHA1 encryption - but can't get my SS site to encrypt in SHA1 only.

I have set the following lines in sapphire/_config.php

Security::encrypt_passwords(true);
Security::set_password_encryption_algorithm('sha1', false);

and also set the current values in Security.php

protected static $encryptPasswords = true;
protected static $encryptionAlgorithm = 'sha1';
protected static $useSalt = false;

however the site is not using straight SHA1. The salt column in the db is now NULL but it's still a strange encryption that won't match the old user passwords which are all sha1.

SS 2.2.1

Any ideas where i'm going wrong?

Cheers,
Josh

Avatar
Sam

Administrator, 690 Posts

9 May 2008 at 9:24am

The encrypted password is then packed into a base 36 number (0-9 then A-Z). I wouldn't have necessary built it this way, but it's difficult to change now without breaking everyone's sites.

// Convert the base of the hexadecimal password to 36 to make it shorter
// In that way we can store also a SHA256 encrypted password in just 64
// letters.
$password = substr(base_convert($password, 16, 36), 0, 64);

Perhaps we could add additional encryption types to the Password encryption column, like sha1-unpacked, which would skip this procedure? Using a string-suffix like this would require fewer API changes than adding a 3rd encryption parameter.

Avatar
Josh

SilverStripe Developer, 65 Posts

9 May 2008 at 11:06am

Thanks for pointing that out Sam, my problem is now solved!