Wrong password column used for authentication

[korsteve]

OpenSIPS branch 1.8

I am running into the same issue as described in bug #477. Are there any updates on this issue? I am having trouble finding the problem in the code as I am unfamiliar with the db/auth modules. It could be a while before I find a solution. Thanks for any support you can give me.

Description: When I authenticate two clients (one client with the digest username: "user1", and the other with the username: "user2@sip.domain.com"), the second client authentication fails. From debug messages, it seems that once a password column is used once (ha1 or ha1b), it will be used in all following queries even if the other password column should be used.

Relevant debug:
First authentication (Success, generates new query) :
DBG:auth_db:get_ha1: username: user2
DBG:auth_db:get_ha1: domain portion: sip.domain.com
DBG:auth_db:get_ha1: calc_ha1: 0
DBG:auth_db:get_ha1: using pass column 2 ha1b
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f674f42ec98 (tail=140081688144552) MC=0x7f674f430ee8
DBG:db_mysql:db_mysql_do_prepared_query: new query=|select ha1b from subscriber where username=? AND domain=?|
DBG:db_mysql:re_init_statement: query is , ptr=(nil) DBG:db_mysql:db_mysql_do_prepared_query: new statement(0x7f674f441238) on connection: (0x7f674f42ec98) 0x7f674f42eaa8 DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 DBG:db_mysql:db_mysql_val2bind: added val (1): len=14; type=254; is_null=0 DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result DBG:db_mysql:db_mysql_do_prepared_query: doing to BIND_PARAM out ... DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f674f440ef8 DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f674f440f40 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f674f440f48)[0]=[ha1b] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f674f440f78 DBG:db_mysql:db_mysql_str2val: converting STRING [a05a32187aab07c37c874b311bf5cc36] DBG:auth:check_response: our result = '416f60b359e7e74f6c427044addd80c1' DBG:auth:check_response: authorization is OK Second authentication (Failure, note that no new query is prepared and the result column name is ha1b) : DBG:auth_db:get_ha1: username: user1 DBG:auth_db:get_ha1: domain portion: DBG:auth_db:get_ha1: calc_ha1: 0 DBG:auth_db:get_ha1: using pass column 1 ha1 DBG:db_mysql:has_stmt_ctx: ctx found for subscriber DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f674f42ec98 (tail=140081688144552) MC=0x7f674f430ee8 DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run DBG:db_mysql:db_mysql_val2bind: added val (0): len=8; type=254; is_null=0 DBG:db_mysql:db_mysql_val2bind: added val (1): len=14; type=254; is_null=0 DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f674f440cf8 DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f674f440f40 DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f674f440f48)[0]=[ha1b] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7f674f441940 DBG:db_mysql:db_mysql_str2val: converting STRING [a05a32187aab07c37c874b311bf5cc36] DBG:auth:check_response: our result = 'bc17e12c512d25b469d6d131221b2ee9' DBG:auth:check_response: authorization failed

[korsteve]

I've found the problem in modules/auth_db/authorize.c:get_ha1.

There should be two prepared statement variables in the function. One for the ha1 statement and a second for the ha1b statement.

Right now there is only one prepared statement variable (static db_ps_t auth_ps) so after the function is called once it sets which result column will be returned no matter which one is passed in on future calls.

[bogdan-iancu]

Hi, thanks a lot for your report and troubleshooting - indeed, there was a case which was never considered, leading to using 2 different types of queries in the same time.

I made a fix on the trunk version (see 8d74b95 or 8d74b95).

Could you please validate my fix before doing the backport to 1.9 and 1.8 ?

Thanks and regards,
Bogdan

[korsteve]

I have verified that the fix works correctly. Thanks!

[bogdan-iancu]

Thanks, all backports done !