OAuth2 client secret hashing

[Pavel Grachev]

Hi everyone,

Keycloak stores OAuth2 client secrets in plain text in DB. Also client secrets are displayed in Admin Console. But client secrets are client credentials so it is almost the same as user passwords. Maybe Keycloak should use the same approach to storing secrets in DB? Maybe it should be hashed as user password before saving it to DB?

I know that there are plans to provide some ability to delegate encryption / decryption to an external provider ( https://issues.redhat.com/browse/KEYCLOAK-10774 ). Is there plans to change client secrets storing approach in common? For example, hash them mandatory.

[Stian Thorgersen]

To be honest I don't see much value in hashing client secrets as these are not used outside the context of Keycloak, there are also better ways to securely authenticate clients (jwt or mtls), which eliminates the need for a shared secret between the client and Keycloak. I would rather see a push towards leveraging stronger client authentication, than worrying about how client secrets are stored ;)

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/d194ab76-2bca-4aba-9e1c-3284ab8b689an%40googlegroups.com.

[Pavel Grachev]

Just a way to improve state of affair because I think there are a lot of clients who uses classical client authentication. But I definitely agree that jwt or mtls is mainstream and more secure.

I got your point. Thanks for the answer :)

среда, 17 марта 2021 г. в 14:16:16 UTC+4, stho...@redhat.com:

[Julien.Pliss...@cdiscount.com]

I agree with Stian here. In addition being able to read back the secret
suits many use cases, and there might be performance issues if the same
complexity of hashing as users is required.

If such hashing is ever implemented, it would be nice to make that
optional through e.g. realm configuration.

--
Julien Plissonneau Duquène

[Stian Thorgersen]

Good point - for client credential grant the hashing will have significant impact on performance, as it would need to do this every time a client requests an access token. For users this is much less of an issue due to they are establishing an SSO session, and the password checking is much less frequent.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/b1d3725dd8187b78d454d26d218370d48bd67974.camel%40cdiscount.com.

[Pavel Grachev]

Yes, but at the same time it is requirement of specification related to OAuth2 protocol - https://tools.ietf.org/html/rfc6819#section-5.1.4.1.3

четверг, 18 марта 2021 г. в 15:24:11 UTC+4, stho...@redhat.com:

[Bergmann Johannes (IOC/PAU2)]

Hi,

 

When Keycloak is operated as a service, it’s good when the service provider doesn’t have access to cleartext credentials. Of cause the clients could use other client authentication options, but that’s on their own responsibility. As a service provider it’s in my responsibility to make it hard to misuse my customer’s secret data. The pattern is used by often at cloud providers or services: Secret is displayed only once and probably stored as hash by the provider.

 

Best regards

Johannes Bergmann

(IOC/PAU2)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io
Tel. +49 7545 202-548 | Mobile +49 173 6953194 | Fax +49 7545 202-301 | Johannes...@bosch.io

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

​

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/91be1e02-e1ce-4312-80ed-f4fefecdf2f3n%40googlegroups.com.

[Stian Thorgersen]

Applying a strong hashing algorithm to client credentials would be very expensive, and would increase the CPU requirements for Keycloak significantly. All refresh token requests for example would result in an expensive hashing of the incoming client secret. We could of course use a more basic hashing algorithm like just a sha-256, but question then is it worth it? Is that strong enough to have any real value? Perhaps it would be since client secrets are randomly generated and considerably longer than most user passwords, so perhaps that is good enough, and is a fair compromise.

Honestly though, I don't really see what threats this would help against. Keycloak already doesn't return the secret over any REST APIs, other than the initial creation of the client. So to be able to access this secret you would need to gain access to the Keycloak server, or the database directly. If someone has access to the Keycloak server they can just get the secrets from incoming requests, and if someone has access to the database, well then they can do a lot of bad stuff. Bear in mind that we are talking about a credential that will never be re-used for other purposes.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/208d2e6357c9408da792ab620e7acec5%40bosch.io.

[Pavel Grachev]

The intruder may not have direct access to database but for example can steal database backup. So he is not able to do bad stuff in database directly, but now he has client credentials to authorize on the authorization server (Keycloak) and gain access to resources on resource server

понедельник, 22 марта 2021 г. в 14:17:37 UTC+4, stho...@redhat.com:

[Stian Thorgersen]

Database backups need to be kept as secure as the database itself, and should also be encrypted. 

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/f3bf0de7-9570-4a4e-8cc7-8af38cc934f5n%40googlegroups.com.