[SR-Users] Kamailio/Asterisk combination + hashed passwords?

Daniel-Constantin Mierla miconda at gmail.com
Tue Jun 11 10:22:05 CEST 2013


On 6/11/13 10:10 AM, Daniel Pocock wrote:
> On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
>> [...]
>>> I also posted a query on the asterisk-users list about support for ha1b
>>> - would you know if that is something that still comes up in practice?
>>> It is in the Kamailio schema, but I have not encountered a device
>>> behaving that way in practice.
>> There are few devices, not remembering any at this moment that use
>> user value in authentication header as being username at domain.
>>
>> ha1 = MD5(username:realm:password)
>> ha1b = MD5(username at domain:realm:password)
>>
>> I hope I remembered correctly the order, by you get the idea.
>
> Oddly enough, I almost forgot to mention Lumicall is using the ha1b column.
:-)
>
> In Lumicall, it is explicitly configured in the phone settings:
>     authentication username = +41xxxxx at sip5060.net
>
> and it sends that whole value to the SIP proxy in the auth header
>
> To be clear, this was an administrative decision and not a
> device-specific issue.
>
> - instead of having a ha1b column (which is a hassle for sharing the
> database with Asterisk or other systems that don't know ha1b), maybe it
> is also useful to have an auth_user column or to have a flag in the
> domains table to indicate that the user at domain convention is used for a
> particular domain?
not sure it would be domain specific, but rather subscriber specific and 
even device -- eg., same user using a snom phone as well as lumicall.

You can update kamailio config file to use pv_auth_check(...) function 
where you give the password as parameter -- it is up to you from where 
you load it (e.g., using sqlops). Then based on format of the auth 
username, you load the appropriate value. But again, I'm afraid you 
would need both values stored anyhow, because same user can have many 
devices with different behaviour.

> - in other cases, do people expect this for administrative reasons or
> solely to support devices that are internally hard-wired to this behavior?

I guess it the past we met devices that had it hard-wired.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *




More information about the sr-users mailing list