[RADIATOR] [Radiator] Problem with SHA hash

[Dick Visser]

On 21 December 2011 15:16, Alby <alby26 at gmail.com> wrote:
> Hello,
> I'm storing in a SQL database the user's password in plain text format. I've
> tried to switch to hashed password, which is of course a more secure
> approach. I' ve some trouble with the SHA hash computation, because the one
> that Radiator computes is different from the mine. In the user's manual,
> there is an example that says that the SHA hash for the password "fred" is
> "k1qAjger6rE9fhCrig+QPZ/HTrJhYWE=". In fact, if I put this hash in the
> database, i can successfully log in with the password "fred". But using the
> Digest::SHA Perl  module, the OpenSSL commands (echo -n "fred" | openssl
> dgst -sha1) and some online tools the SHA hash for the password "fred" is
> always the same (31017a722665e4afce586950f42944a6d331dabf) but different
> from the one calculated by Radiator.
> By the way, with the MD5 algorithm this problem does not exist, but I would
> like to use SHA instead that is more secure.
> I don't understand what I'm missing...

The hash you're looking at is base64 encoded.

The good old LDAP utils use SHA1 and they give a similar hash, but different:

[visser at cajones ~]$ slappasswd -h {SHA} -s fred
{SHA}MQF6ciZl5K/OWGlQ9ClEptMx2r8=

This can be manually reproduced by issuing:

[visser at cajones ~]$ echo -n fred | openssl dgst -sha1 -binary | base64
MQF6ciZl5K/OWGlQ9ClEptMx2r8=

At this moment I can't tell how the radiator one
('k1qAjger6rE9fhCrig+QPZ/HTrJhYWE=') was generated.
It is a bit longer than a normal base64 encoded binary SHA1 hash, so
that might be a clue.



-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands
T +31 20 530 44 88 F +31 20 530 44 99
visser at terena.org | www.terena.org