2.x.x (and earier?): yet another decoding SSHA issue

[Stefan Winter]

Hi,

>> SSHA1-Password will then hold the raw octet value of the hash. Unfortunately
>> I believe that rlm_pap has it's own normalization logic, 
>> so may still attempt to decode the raw octets as hex or base64 *sigh*. 
> 
>   Only if the data is longer than the length of the binary hash.
> 
>   i.e.
> 
> - length == length of hash ---> DONE
> 
> - length is 4/3 (or so) + other stuff.. --> base64
> 
> - starts with "0x" and length is 2x the length of the hash --> hex
> 
>   It should be pretty fail-safe.

Really? This is *salted* SHA; and the salt gets prepended (or appended)
to the hash value. Since the length of the salt is arbitrary, the length
of the resulting attribute value is also arbitrary (well, lower bound is
the size of the unsalted hash of course).

Even the 4/3 rule breaks at that point...

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20130716/8f1c1cf7/attachment.pgp>