Auth_key_sha256 for password only

New Features Ideas
1

: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

2

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

3

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

4

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?

5

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.

6

Got it. I guess we could add this.

7

@sscarduzio Any update on the above?

8

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

9

@sscarduzio Do you have any update on this?

10

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

11

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

12

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
13

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

14

https://readonlyrest-data.s3-eu-west-1.amazonaws.com/build/1.18.2-pre1/readonlyrest-1.18.2-pre1_es6.8.0.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJEKIPNTOTIVGQ4EQ/20190620/eu-west-1/s3/aws4_request&X-Amz-Date=20190620T145825Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=ec1f25ead61bd990b01f8ad8948472be7c8ff4aca006861fb8caa65ddd3c7b8f

15

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

Looks good to me!

1 Like
16

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

17

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

18

@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.