API key generation security

[janhaesen]

Digging the plugin.

I was wondering whether it would be possible, difficult for me to answer due to lack of full Keycloak knowledge, to have the option of having a strategy to influence the way the API key is generated. Currently it is a UUID, but perhaps a strategy of generating a random secure string would also be nice to set the size of the key.

Similarly, I see that currently the API key would be stored plain text, would it be possible to store this encrypted with the option to obtain this API key again?

Perhaps above strategy could also resolve the comment on the blog post:

Just so you know, this implementation is vulnerable to timing attacks. The best way I have seen to handle this is to split the API key into two pieces: a prefix and a suffix. Index and select using the prefix (sacrificing that entropy to timing attacks) and treat the suffix as a password, complete with hashing, etc.

Reason being is that a UUID is time based and server oriented, meaning it could be derived given that information.

[zak905]

Hi @janhaesen,

Thanks. When it comes to API key generation we have total freedom, we can plugin any random generation strategy and even bring external libraries .

By the way, the generated API Key is not an UUID, but rather a random series of alpha numeric characters as you can see here which is generated by this keycloak utility: https://github.com/keycloak/keycloak/blob/main/common/src/main/java/org/keycloak/common/util/SecretGenerator.java

Similarly, I see that currently the API key would be stored plain text, would it be possible to store this encrypted with the option to obtain this API key again?

I see no technical obstacle towards achieving this. Keycloak uses already RSA for signing the JWTs, but I guess here we need some symmetric cryptography like bcrypt or argon2. The question is where will the salt be stored. This would need some design

Reason being is that a UUID is time based and server oriented, meaning it could be derived given that information.

now I get it. Thanks

[janhaesen]

Thanks for getting back to me.

You're right, I was looking at the wrong property and mistaken the setId with the value for the API key. Regarding strategy for the value I think it is fine as it's also a secure random.

Storing the API key encrypted would be a requirement as otherwise upon a breach the API keys would be out in the open without any additional security layer.

When it comes to the storing there is however an issue when it comes to my request, as I noticed that you are doing authentication based of the value of the API key and querying that against the database. If the API key is in fact stored encrypted, which I would prefer/suggest given security, you would also have to search the database for the encrypted value.

This poses 2 things that would have to be considered:

1. Will this pose significant load for the server running the Keycloak instance. Given that the request count can be step and thus for each call encryption has to be executed
2. What will the performance be of the lookup given that the value of the user_attribute table is not indexed.

I personally believe that even with a large amount of users (well in the 100 thousands) it will still be just fine, especially given current generation hardware. But it would be good to consider.

That being said, given the request, do you believe that it is something you see could be incorporated?

Lastly, can you confirm that I'd only need the api-key-module dir/package for including the extension in my local Keycloak distribution to get it up and running?

[zak905]

Interesting thanks. Well, if you are already clear on what should be done, why not submit a patch ? This would benefit also the others who are using the module. Broadly speaking, I know that Keycloak have already internal providers to manage Credentials and how they are stored (e.g PasswordCredentialProvider), maybe this can be leveraged to achieve what we are aiming for.

and yes, If you want to use the extension you only need the api-key-module jar.