Icinga2: Allow to hash/encrypt credentials or use an external storage

Created on 22 Jun 2018  Â·  15Comments  Â·  Source: Icinga/icinga2

Targets

Any credentials stored in the configuration files.

  • ApiUser password
  • User defined custom attributes used for command arguments
  • User defined constants applied to object attributes

Ideas

Impact Analysis

  • Would this slow/halt config compilation/validation?
  • Evaluated at runtime only or pre-generated on the node which has access to external sources?
  • Simplified user interface possible? E.g. use a function, specific DSL variable, another extension
  • Security, disallowing to exploit this via DSL or at runtime
  • Distributed setups: Who's the authority of the credential value
  • REST API: How to set values at runtime, and via Director

Tasks

  • [ ] Common hash algorithm (#6278)
  • [ ] Creation/Encryption via CLI command
  • [ ] Hide credentials on the CLI and API (needs a flag in .ti)
  • [ ] Default handling of hashes or plain text (don't do this in OnConfigLoaded with OpenSSL functions)
  • [ ] Discuss this idea as password store with other feature requests
areapi corevaluate enhancement

Most helpful comment

💡 Just answered my own question: If it's reasonable enough for both Apache and nginx, it's also reasonable enough for us.

All 15 comments

The algorithm used was PBKDF2 following https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

This is still the best algorithm to use as it's implemented by openssl 1.0.2.

There was 6504606e23c9ce5f748925dc7445c0053d0f31e8 in v2.8.x which just has not been included in v2.9.0. What was the problem with that change?

6387 and #6278. Apart from that, this feature was introduced in a bug fix release (2.8.2) and was not tested well enough.

I found a tool that has a similar output to crypt. It is reasonable that a Linux user to install the tool.

jmueller@nb-jmueller:~$ openssl passwd -5 -salt saltvalue password
$5$saltvalue$rtc73UxmvUVY.aTgGqMbSvxXR7GSMnKoYEg6i3RRP0.
jmueller@nb-jmueller:~$ 

@lippserd Should we hash our passwords like that?

Yeah, looks good. It is ok for me that users have to generate password hashes on their own. We should document example commands with sane args though. We just have to support all key derivation functions supported by crypt (and openssl passwd).

@justinmueller05082000 Write a C++ program which one calls like this:

./theprogramfile password '$5$saltvalue$rtc73UxmvUVY.aTgGqMbSvxXR7GSMnKoYEg6i3RRP0.'

... and it exits with 0 – i.e. an immediately subsequent echo $? prints 0.

./theprogramfile wrongpassword '$5$saltvalue$rtc73UxmvUVY.aTgGqMbSvxXR7GSMnKoYEg6i3RRP0.'

... shall exit with 1.

Paste the source code as comment here.

#include <crypt.h>
#include <cstring>

int main(int argc, char *argv[]) {
    if (strcmp(argv[2], crypt(argv[1], argv[2])) == 0) {
        return 0;
    } else {
        return 1;
    }
}

The program takes two command line parameters and check if the password ( Argument 1) in plain text matches the hashed password ( Argument 2). To do that it converts the plain text into a hashed one and compare both with each other. If both passwords are equal the program returns 0 otherwise 1.

  • [x] Fork this repo
  • [x] In your fork create a new branch (same scheme as in your Go sort, also refs and fixes)
  • On this branch:

    • [x] Add a new attribute "password_hash" to the ApiUser class

    • [x] Make use of this attribute (if set) instead of the plaintext attribute "password"

  • [x] Create a PR and let me review

+1

@lippserd Is the following reasonable for a user?

$ htpasswd -bnBC 10 '' 123456 |tr -d ':\n'
$2y$10$Se/Zy0gzbMuuS4792CAdYuStiKMf9T3A3BfYs9SixginUlOmOV1u6
$

Why should we do that? 😆

To hash a password via bcrypt (available to C++ on *nix and WinNT!) w/o having Icinga 2 installed locally.

Just use the openssl example. We really should not break our head with other commands.

Unfortunately the generic crypt(3) isn't easily available on WinNT. bcrypt is available, secure and the CLI hasher htpasswd is also used for Apache and nginx. The only keed-to-know variable in my example is the password (123456).

💡 Just answered my own question: If it's reasonable enough for both Apache and nginx, it's also reasonable enough for us.

Was this page helpful?
0 / 5 - 0 ratings