[RADIATOR] [Radiator] Problem with SHA hash

[Alby]

Thanks very much for your help!
Alberto
2011/12/21 Heikki Vatiainen <hvn at open.com.au>

> 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.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20111223/0c83b06a/attachment.html