feat(oauth2) optionally hash client secret

[bungle]

Summary

This was originally implemented with #4866 by @janza.

After some review comments, and the introduction of DAO transformations, I decided to make changes, thus opening this new PR.

This PR adds a new boolean column hash_secret to oauth2_credentials that is used to determine whether or not the client_secret will be hashed.

The PR adds support for pbkdf2 (and contains code for argon2, and bcrypt if we want to enable them later). The plugin will also check if the client_secret needs to be rehashed (on usage). One caveat. If you run this on cluster and some nodes have argon2 and some don't, it is possible that you cannot use the credentials on those that don't. So keep your environments similar.

Issues resolved

Close #4866, Fix #1237 (at least on OAuth2)

[p0pr0ck5]

Why are we supporting more than one hash algorithm? It seems to complicate things substantially and I don’t see it being configurable. And argon it not used anywhere else in this project- let’s not add another dependency if we don’t need it?

[p0pr0ck5]

Also, what is the logic behind making hash behavior configurable? We don't have such an option for basic-auth.

[bungle]

Why are we supporting more than one hash algorithm? It seems to complicate things substantially and I don’t see it being configurable. And argon it not used anywhere else in this project- let’s not add another dependency if we don’t need it?

bcrypt is also not used anywhere. The reason was:

1. argon2id is recommended and probably gonna be NIST (EE can ship it) (https://password-hashing.net/)
2. bcrypt will install properly by with just luarocks and not NIST compatible (argon2-ffi and lua c-wrapper still need system library too)

[bungle]

Also, what is the logic behind making hash behavior configurable? We don't have such an option for basic-auth.

In many places like:

1. bintray
2. luarocks

etc.

You can go to your settings and fetch the API key (and I would say it is very handy albeit less secure). In some contexts like Github I think the flow is: create app secret and it shows you after creation, and after that it is impossible (very cumbersome as you probably also need to configure this and that, that you already had to one which key you cannot get anymore, but yes, more secure too). So because there is legacy in this plugin we wanted to keep it optional and backward compatible and support both scenarios.

Both scenarios have good and bad sides, even other than what I explained above.

[bungle]

Also, what is the logic behind making hash behavior configurable? We don't have such an option for basic-auth.

For basic-auth I think we didn't even think about that during that point. It is also using hashing function (basic sha1 hash with salt, non-pbkdf2 type) that is not particularly made for hashing passwords. Also it is rare to see any use to store password in plain (e.g. with keycloak I cannot find my password anywhere, but I can see clients and their secrets).

[bungle]

At some point if @fffonion can provide us password hashing functions with lua-resty-openssl, I guess we can remove these dependencies, though we might need to write migrations then.

[fffonion]

@bungle lua-resty-openssl 0.6.0rc0 now has kdf which supports PBKDF2 and others. 😄

[bungle]

@fffonion, ok perhaps we should then wait for lua-resty-openssl bump.

[fffonion]

@bungle I just released 0.6.0, the kdf api should be available now : )

[bungle]

This is now updated to use pbkdf2 with lua-resty-openssl. Other algorithms are disabled, but can be enabled if we need to support them at some point. The new dependencies were removed from .rockspec (so brypt or argon2-ffi is not included anymore there).

PBKDF2 will output hash like this (contains default settings):

$pbkdf2-sha512$i=10000,l=32$RsW9il33SHbxQzywGmNkRw$EnvHL59Y0vyxTmjuiArdi6Kmxk3/6TrM1q9bIR3d/zw