2.x.x (and earier?): yet another decoding SSHA issue
a.cudbardb at freeradius.org
Tue Jul 16 17:12:53 CEST 2013
On 16 Jul 2013, at 15:54, John Dennis <jdennis at redhat.com> wrote:
> On 07/16/2013 09:40 AM, Alan DeKok wrote:
>> Arran Cudbard-Bell wrote:
>>> 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.
>> - 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.
> I'm not a fan of heuristics, every time you think you've got the logic
> nailed down some corner case will prove you wrong. Plus it's magical, I
> don't like magic, I prefer explicit well defined behavior. Plus in this
> instance the behavior is tied to well known digests, what about all the
> other places where binary conversion from text encoding might be called
> for? Shouldn't everything obey the same rules?
> Is it possible to add a qualifier indicating the format of the item,
> e.g. base64, hex, etc.?
You could use as part of the atribute name to indicate a cast.
<string>SSHA-Password := <hash>
But it's still awful.
Anyway Stefan's point about SSHA is correct. Maybe an option to turn off the normalisation done by rlm_pap would be useful.
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team
More information about the Freeradius-Devel