[keycloak-dev] Storage protection

[Bruno Oliveira]

Hi Bill, some answers inline. I forgot to add references.

--  
abstractj

On January 27, 2014 at 1:53:39 PM, Bill Burke (bburke at redhat.com) wrote:
> > More comments inline responding to Bruno's email:
>  
> >> # 1
> >> - HSM or Java Security manager are perfect, but impractical  
> for regular devs, that would require a lot of maintanance (a dream)  
> >>
>  
> What is HSM? How could the Java Security Manager protect clear 

http://en.wikipedia.org/wiki/Hardware_security_module

> text
> private keys and OTP keys?

With Java Security Manager is possible to restrict code privileges to the resource specified (https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/5/html/Security_Guide/chap-Java_EE_Security_Manager.html).  

>  
>  
> >> # 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.
> >> -
>  
>  
> Stian suggested having an SPI for this sort of feature. Either  
> a
> password would be required at Keycloak server startup, or the  
> password
> would be stored in a property file.

Is not the same thing, but do you mean something like Maven does? (http://maven.apache.org/guides/mini/guide-encryption.html). Maybe a “master password” and have some sorta of keychain? For example:

1. Master password generates the symmetric key
2. Encrypt the key pairs
3. Decrypt the key pairs on the fly for digital signatures for example.

That’s what do you mean? 

>  
> >> # 4
> >>
> >> Generate the keys per session, instead of use it per realm (it  
> must be tested/implemented because that could slow down our  
> server)
> >>
>  
> Not sure this is feasible. In a clustered environment, you'd  
> need a
> trusted way of transmitting all the realm keys. You also would  
> need a
> way to transmit the public key of the realm to each adapter. Each  
> adapter could make an HTTPS call on bootup to retrieve all relevant  
> realm metadata, but you'd still have to provide a truststore  
> for the
> adapter so it could make a trusted HTTPS call that verified the  
> keycloak
> server's host. But maybe we need this truststore irregardless  
> :) ???
>  
> But, this still doesn't protect clear text OTP keys (i.e. "What  
> is your
> mother's maiden name?”)

Option 4 must be tested/elaborated better, if you guys think that some of the other options worth to try, just let me know. Other than that, I will try to help in whatever you guys think is the best.