[basicauth] Encrypt password field about kong HOT 10 CLOSED

public_key can't be the salt, its public, therefor not-secure. use the internal id (uuid) as salt

from kong.

Ah yes, it was with the id! Right, thanks

from kong.

I suggest using SHA1

from kong.

The only problem with encrypting keys is that the user will be able to retrieve it only the first time and never again. Of course this is not ideal.

I spoke with @thibaultcha and I agree that the only field that should be encrypted in the password in Basic Authentication, but not the secret_key for other authentication types.

from kong.

Any news on this? Non-encrypted secrets at rest are a giant audit flag (for me, in particular, for PCI).

I would suggest that both the basic_auth and secret_key be hashed; really, if you are not going to pass it back to the backend API, there is no good reason to store it plaintext, including not being able to retrieve it more than once; if the secret key is lost (or stolen or compromised) - you just generate a new one.

from kong.

@bortels we have setup a roadmap here. We're working around the clock to deliver many new features, unfortunately "encrypt password" is not planned for the next release.

However, if you guys can help with a PR along the way, we would be more than happy to merge it for the v. 0.5

from kong.

moving forward with this, first draft with basic authentication plugin

configuration will add a new key 'encryption_method' which will hold:

• plain - plain passwords - default, for backward compatibility
• sha1 - sha1 for salted password with consumer id.

some code related questions:

• is there a way to use plugin 'conf' in the api.lua. to get encryption_method .
• for sha1 i use open-resty bundled https://github.com/openresty/lua-resty-string
  there is no issue using this for test api using kong proxy.
  but when i run the tests - it was failing. first because package.path was not pointing directly.
  a manual fix was giving me error regarding no ffi (no Luajit) in tests.
  how can i solve this ?

from kong.

Shouldn't we use bcrypt?

from kong.

bcrypt is fine by me.
are you suggesting having it instead of sha1 or along side with it (letting the user to decide).

from kong.

Having both would be better of course yeah

from kong.