Use pba authentication instead of authutils

[nichtsfrei]

To be able to verify new password hashes and update old ones gvmd is
using passwordbasedauthentication of gvm-libs.

This is depending on: greenbone/gvm-libs#484

What:

Why:

How did you test it:

Before you login with your previous account verify the hash is following the old pattern:

> docker-compose exec gvmd psql -d gvmd -c "SELECT * FROM users;"

login and verify if the hash is following the pattern $6$rounds=20000$.....

Then create a user and verify that the new user has the new hash format as well.

To verify the new parameter --pepper and --hashcount you can create a user with pepper and one without and then verify the password hash. The user with pepper should contain: 0000$ to indicate a 4 byte pepper within the db.

> docker-compose -p docker-companion exec gvmd gvmd --pepper DOCK --hashcount 42000 --create-user=testpepper --password=password
> docker-compose -p docker-companion exec gvmd gvmd --create-user=testwopepper --password=password
> docker-compose -p docker-companion exec gvmd psql -d gvmd -c "SELECT name, password FROM users;"
     name     |                                                        password
--------------+-------------------------------------------------------------------------------------------------------------------------

 testpepper   | $6$rounds=42000$UzzzRFyz76I20000$GYnQjEwC8XeTqcoyXhuN04yMRwrwm5ZdqCaYqvo/pEF5T80SC/gh8eumv.CtXwENzKXO0Z6RwdUPx/ex.GHiR0
 testwopepper | $6$rounds=20000$xZtz6zzztdoOmzzz$mDxidDdLgHJTQYoBq6K7lL.Vyu21B0rnuBKdd7BE/N6kSvFY754WIqznUKLnj.AQ5UktUIYI7rNapmySccrd71

Checklist:

• Tests
• CHANGELOG Entry

[timopollmeier]

Is there a reason you handle the authentication config so it has to be passed to manage_option_setup and all the manage_... functions instead of handling it like other options?

If it's necessary to do it that way, it would be good if you could add line breaks to the extended function parameter lists so the lines are 80 characters or less.

[nichtsfrei]

Is there a reason you handle the authentication config so it has to be passed to manage_option_setup and all the manage_... functions instead of handling it like other options?

If it's necessary to do it that way, it would be good if you could add line breaks to the extended function parameter lists so the lines are 80 characters or less.

I'm not sure how the other options are handled, I need it within: managq_sql.c hence I copied the way how const db_conn_info_t *database is handled since they all call manage_option_setup I assumed that this is the way to go; if there's a more generic option to handle that I would like to change that but I am not aware of one.

In the meantime I will add line breaks.

[timopollmeier]

I was thinking of using getter and setter functions like get_scanner_connection_retry and set_scanner_connection_retry in manage.c and making sure the options are processed before any of the manage_... calls that use them.

[nichtsfrei]

I was thinking of using getter and setter functions like get_scanner_connection_retry and set_scanner_connection_retry in manage.c and making sure the options are processed before any of the manage_... calls that use them.

I don't think this is a good solution in this case because

• it would either require to verify if that set method has been called or rely on a implicit contract
• it is alien to manage_sql.c as far as I can tell all settings are either set in init_manage_internal or manage_option_setup

Since manage_option_setup is calling init_manage_helper which then is ending up in init_manage_internal it would have the same effect from an API point of view.

Although I agree that it is weird to introduce authentication settings to DB specific manage construct in my opinion it would not make it easier to maintain when we introduce a setter construct on top within manage_sql.c.

[nichtsfrei]

Another way to handle that could be create a separation of the actual authentication and information gathering for the authentication process; I think that could be achieved when separating authenticate_any_method I would need to look into that from a data point of view (to see how complex it is to fetch necessary information so that this could run independently) and may come back with a solution for that.

However I'm not sure if it would be a good idea to do such a massive change for 20.08 which is also targeted by this hash update pull request.

A middle ground could be to start a manage_authentication setup but just deal with password based authentication for now to not have to deal with authentication settings within manag_sql but just verify and create hash. That way the intrusion is limited and the footprint of the existing manage_* methods are reduced.

[timopollmeier]

Moving the authentication to a separate source and header file to make it clearer that the options need to be initialized sound like a good idea. I think we should go ahead with that.