[keycloak-dev] Storage protection

[Anil Saldhana]

It is going to be a choice between usability and protection.

Security sensitive deployments are going to be using HSM and vaulted 
networks.

For everybody else, best is to go with usability thereby choosing an 
approach that gives good-enough security.

One of the challenges we have faced is the non-availability of a 
database for default deployments and the use of filesystem as the 
default mechanism for storage. In the case of KeyCloak, it is using the 
DB as the storage mechanism.


On 01/27/2014 08:43 AM, Bruno Oliveira wrote:
> Good morning, I've been thinking about how to properly protect private key in a world where HSM is not an option. Currently a key pair is generated (https://github.com/keycloak/keycloak/blob/c0a1090733975977179662dd44fc3ac75e925cf0/services/src/main/java/org/keycloak/services/managers/RealmManager.java#L90) to cryptographically sign tokens (https://github.com/keycloak/keycloak/blob/0fe9318fa414d06fc39c83d91c78effe2ba25b2a/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java#L88) and the private key is stored into the database.
>
>
> Some of the possibilities to improve it:
>
> # 1
> - HSM or Java Security manager are perfect, but impractical for regular devs, that would require a lot of maintanance (a dream)
>   
> # 2
> - Entering a password for a PKCS#8/PBKDF2-derived key, also impractical assuming that someone would be required to enter the password at each app startup
>
> # 3
>
> - Not bullet-proof solution, but store the key into a text file that only sysadmins and the web server has access, doing our best with the usage of ACLs provided by environment.  I understand Bill's concern (http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001089.html) but at the same time, a file could have a very restricted access while the database is more acessible to developers.
> -
> # 4
>
> Generate the keys per session, instead of use it per realm (it must be tested/implemented because that could slow down our server)
>
> # 5
>
> Leave it as is.
>
> So what do you think? Ideas or tomatoes?
>
> --
> abstractj
>