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

[Arran Cudbard-Bell]

On 22 Jul 2013, at 10:45, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:

> 
> On 22 Jul 2013, at 10:43, Stefan Winter <stefan.winter at restena.lu> wrote:
> 
>> Hi,
>> 
>>>       expand: %{control:RESTENA-SSHA1-Password} -> oPQYKSRg5w8XWEiJCcNtzKRhUhtJMUQ/WjdCWlVQS2JWN2Qz
>>>       expand: 0x%{base64tohex: %{control:RESTENA-SSHA1-Password}} -> 0xffff18292460ff0f175848ff09ff6dffff61521b4931443f5a37425a55504b6256376433
>> 
>> when I take this base64 and use an online base64-decode service such as
>> http://base64decode.net/ and use its output with an online hex-encoder
>> such as http://convertstring.com/EncodeDecode/HexEncode I end up with
>> the string
>> 
>> 203F182924603F0F1758483F093F6D3F3F61521B4931443F5A37425A55504B6256376433
>> 
>> The bit-diff to what the FreeRADIUS fucntion produces is like:
>> 
>> 203F182924603F0F1758483F093F6D3F3F61521B4931443F5A37425A55504B6256376433
>> ffff18292460ff0f175848ff09ff6dffff61521b4931443f5a37425a55504b6256376433
>> ***---------*---------*---*---*-*---------------------------------------
>> 
>> (I was wondering from the start why there are many more FF's in the
>> FreeRADIUS version than what probability would suggest)
> 
> 
> Yes that was the first thing I did. I suspected the base64 decoder (it's new), but, I just tested with rlm_pap in version 3.0 which uses that decoder and it works fine. The code is pretty simple... I'll keep digging.

sprintf "%02x" was giving the wrong result. I'm not sure why. I've switched to our own internal hex encoder which is probably faster anyway, and it gives the correct hex encoding.

Using your hash and example password, authentication now succeeds.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team