Bug 33 - complete the passwordHashAlt (ha1b) support
Summary: complete the passwordHashAlt (ha1b) support
Status: NEW
Alias: None
Product: repro
Classification: Unclassified
Component: proxy (show other bugs)
Version: unspecified
Hardware: All All
: P1 minor
Assignee: Owner of all unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-17 16:47 CDT by Daniel Pocock
Modified: 2015-10-20 11:57 CDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Pocock 2012-08-17 16:47:59 CDT
repro currently stores a passwordHashAlt value in the users database, equivalent to the ha1b value in some other SIP proxies

It is calculated

H(A1b) = H(user@realm:realm:password)

The authentication code doesn't actually use this value though unless a custom auth query is specified in repro.config using the parameter MySQLCustomUserAuthQuery - however, when it is used in that manner, then the regular passwordHash is ignored

A complete solution needs to check an authentication attempt against both possible hash variations, and succeed if either is matched.
Comment 1 Daniel Pocock 2015-10-20 11:55:22 CDT
Note that when clients send auth username = "user@domain", the current implementation of the code is duplicating the domain in the SELECT query, e.g. it looks like this in the logs:

SELECT passwordHash FROM users WHERE username = '$user' AND domain = 'sip5060.net@sip5060.net'

With the workaround, setting 

Database1CustomUserAuthQuery = ALL SELECT passwordHashAlt FROM users WHERE username = '$user' AND domain = 'sip5060.net'

it runs a query like this:

SELECT passwordHash FROM users WHERE username = '$user' AND domain = 'sip5060.net@sip5060.net' UNION SELECT passwordHashAlt FROM users WHERE username = '$user' AND domain = 'sip5060.net'

and the second part of the UNION query finds a result.
Comment 2 Daniel Pocock 2015-10-20 11:57:24 CDT
More about the CustomUserAuthQuery workaround

When a custom user auth query is specified, an SQL UNION query is used to run both the built-in query and the custom query.  SQL doesn't specify the order of results from a UNION query and it is non-deterministic.  I've observed that running the query on MySQL it tends to return the passwordHash before passwordHashAlt but when doing the same query on PostgreSQL, it appears to sort the results alphabetically, probably because UNION does DISTINCT by default.  A partial workaround for that on PostgreSQL is to change UNION to UNION ALL, this can be achieved by putting ALL before the SELECT string in the CustomUserAuthQuery, e.g.

Database1CustomUserAuthQuery = ALL SELECT passwordHashAlt FROM users WHERE username = '$user' AND domain = 'sip5060.net'


and repro will then execute the query

SELECT passwordHash FROM users WHERE username = '$user' AND domain = 'sip5060.net@sip5060.net' UNION ALL SELECT passwordHashAlt FROM users WHERE username = '$user' AND domain = 'sip5060.net'

Technically, the result set is still meant to be non-deterministic, but it appears to behave like MySQL when done this way.