Auth_key_sha256 for password only

:bulb: Right now auth_key_sha256 should be sha256 for both username and password, I suggest splitting the 2

I don’t integrate tools into LDAP configs to keep failures isolated.
This means I have to do (and want to do) user (and password) management within RoR itself.
However, I would like people to be able to choose their own passwords.

So I would like to see a new auth_key option like auth_key_sha256_passwordonly that has the username as clear text and the password as a sha256 hash.
This way I have full control over the username, but people can send me a sha256 hash of their password.
This way I can manage usernames and passwords completely from RoR but I still wouldn’t know my users passwords.

With the current auth_key_sha256 theoratically people could send me a sha256 hash with a different username then I intentded for them.

This would make for a safer configuration as the administrator doesn’t need to know the users password at all

:eyes: Example

Have 2 options:
auth_key_sha256: EEECCE04C1ED7A63FCF96CC30E0DA747BEFCBC34F3B58E1266A2F52DC20053AE
sha hash containg username and password
auth_key_sha256_passwordonly: username:AD62252F71A484702B74F379EA3C3388AC8C147EF65A7D4F50BFA06D6D9AAF8B
sha hash containing only the password for a user.

:rocket: Let’s do this?

  • 1
  • 2
  • 3
  • 4
  • 5

0 voters

Would this not be a good candidate for the new “headers” rule?

@sscarduzio I don’t understand what you mean, can you elaborate?

Hi @ronald.vanboven, sorry I answered you too much in a hurry.
I was referring to the newly introduced headers rule.

However, if you are planning to use this for Kibana access with ROR PRO/Enterprise, it won’t log in users correctly, as the header value won’t become part of the resolved user identity.

Are you using ROR PRO/Enterprise?

No problem :slight_smile:
I am using ROR Pro.

So I would like user to make a SHA256 hash for their password.
They mail me their hashed password and I make a user(name) for them.
This way you have better security as only the user knows his own password, but I (the admin) have full control over usernames.

Got it. I guess we could add this.

@sscarduzio Any update on the above?

Unfortunately this task went buried. Fortunately now we have a backlog and I just added it to it. Thanks for pinging!

@sscarduzio Do you have any update on this?

yeah I have committed something today for supporting an alternative syntax for all the auth_key_sha* rules.

what ES version do you have? I could give you a pre build so you can test it

We just upgraded to 6.8 on production today.
So I can test, but it will take a couple of days before we can test on the test environment.

1 Like

6.8 seems to be stable.
If you want we can test the new keys on the test environment?

We tested this morning, it works perfect for our usecase:
auth_key_sha256: sha256 with username:password works
auth_key_sha256 username:sha256 with password works

Looks good to me!

1 Like

OK will be then officially released in 1.18.2. Thanks for testing :slight_smile:

@sscarduzio Can this same feature be extended to keystore_pass and key_pass attributes?

@askids how would that look like? I don’t understand, ROR needs the password in clear to open the key store. Generally conf keys like these are handled via environmental variables, so it’s not in the config file.