[RADIATOR] [Radiator] Problem with SHA hash

[Heikki Vatiainen]

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.