[RADIATOR] [Radiator] Problem with SHA hash

Heikki Vatiainen hvn at open.com.au
Wed Dec 21 14:56:18 CST 2011


On 12/21/2011 09:25 PM, Dick Visser wrote:
> On 21 December 2011 15:16, Alby <alby26 at gmail.com> wrote:

>> 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.

In short, the example in the manual should start with {SSHA}. Please see
below why it still works.

>> 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=

Version 4.9 now has goodies/sha.pl and goodies/ssha.pl

% perl goodies/sha.pl fred
{SHA}MQF6ciZl5K/OWGlQ9ClEptMx2r8=

The two above methods are also useful to verifty you get the expected
output.

> 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.

Yes, the longer length is the reason. SSHA adds salt to the end of
binary value of hash. So when you base64 decode
'k1qAjger6rE9fhCrig+QPZ/HTrJhYWE=' you get binary output followed by
'aaa'. Here 'aaa' is the salt.

The example in ref.pdf should be {SSHA}k1qAjger6rE9fhCrig+QPZ/HTrJhYWE=
to make it less confusing, since the value is really a salted SHA, not a
plain SHA.

In other words, when Radiator sees {sha} or {ssha} it can run the same
password verify function. If the hashed value is longer than plain SHA
the remainder is considered as salt for SSHA.

Heikki


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


More information about the radiator mailing list