Hi,

...

The fix still needs config changes with a bit of a hackish workaround - read the thread til the end to get all the goodness. I tested some of the hashes that were giving me trouble and they all worked with the current branch version. I also read all the thread,

Glad to hear that :-) The remaining issue occurs only when the base64-encoded SSHA password starts with the two characters "0x" or "0X". In that case, FreeRADIUS thinks "oh, a hex number, let's decode it" - while the input is not a number at all. Doesn't lead to crashes, but auths going wrong. And, IIRC, that kind of failed decoding heuristics only happens inside the SQL module, so if you pull your SSHA hashes from elsewhere, it may not apply at all.

and some things were not so clear for me (sorry for the "noobiness"). Could you explain your final configuration state?

The problem is that SSHA1-Password's data type triggers the wannabe-decoding. The workaround was to define another attribute myself, with another data type, which stops this from happening; and later re-coding into the original attribute name explicitly in the config.

I saw the unlang:

update reply { SSHA1-Password := "0x%{base64tohex: %{control:RESTENA-SSHA1-Password1}}" }

And the SQL syntax:

SELECT id, username, 'RESTENA-SSHA1-Password', value, op FROM check_smtp_ssha1 WHERE username='%{SQL-User-Name}

Is these configurations obligatory? I'm using the standard radcheck table (id,username,attribute,op,value) and query that comes with freeradius. From what I understood, I need to create a VSA, assign my SSHA1-Password attribute to it and convert it to hex format using the unlang and xlat?

Without these extra configuration, the messages from authorization are now:

That's right, the RESTENA-* thing is a VSA. Not sure about the data type right now, not in the office. I think SSHA1-Password's failing one is "octets" and the VSA is "string" (or "text"?) instead. Ehm, the thread should tell you :-) If you have control over your database, it's obviously better to change the attribute name inside the DB to your VSA's attribute name, and to leave the standard queries in sql.conf untouched. In my setup, I did not have that luxury, thus the override of attribute name to a hard-wired "RESTENA-SSHA1-Password".

[pap] login attempt with password "senhasecreta" [pap] Using SSHA encryption. [pap] User authenticated successfully ++[pap] = ok

So the "Normalizing error" and segmentation fault isn't happening anymore.

With only those specific 0x/0X characters triggering failure, you'd see approx. 1 out of 16.000 hashes being affected. Depending on your deployment size, you may simply not have seen it yet :-) The normal non-debug log would not produce any clue that something went wrong (aside from auth failed), as the error would be an "SQL query error" - even though the query is perfectly fine; it's the post-processing that goes wrong. HTH, Stefan