[keycloak-dev] Storage protection

[Bruno Oliveira]

I think that’s just fine, where developers will store their private keys is their decision: db, text file or fancy hardwares.

My only suggestion is to generate these keys with some KDF function, maybe during the first application setup? What do you have in mind Stian? command line, web interface, integrate with jboss-cli?

--  
abstractj

On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian at redhat.com) wrote:
> > We should do it as an SPI to make it extensible. This would allow  
> admins to integrate it best into how they manage sensitive data.  
> I don't know what common practices are, but I imagine there are  
> many ways to do it.
>  
> As I said before I think our options OOTB are either to just store  
> in clear-text, or generate a master password and write to a known  
> location (/standalone/data/realm.secret?).  
> Anything more than that would make it hard to use for development.  
>  
> I believe it is safer store a master password in a file (and an additional  
> layer of defence to storing in clear-text to RDBMS, which can  
> be compromised through SQL-injection attacks that non-shared  
> file systems are not prone to).
>  
> The master password location can be configurable through a system  
> property. Admins can place this file on an encrypted location,  
> this would be recommended. I don't think its any better to provide  
> the master password as a argument or system property at startup  
> than it is to store it in a file on an encrypted drive. The reason  
> being is that if someone gains admin access to the server, they  
> will be able to read the file, sure, but they can also get the arguments  
> used to start the server just as easily. If the server is turned  
> of neither properties or an encrypted drive will help them. Admins  
> already have mechanisms in place to manage encrypted drives  
> on servers, so we'd rely on them to know how to do that themselves.  
>  
> For future and more improved solutions we can add whatever mechanisms  
> users are asking for through the SPI. Enterprises can also implement  
> their own.
>  
> The SPI could be something as simple as:
>  
> public interface PrivateKeyProvider {
> public PEM getPrivateKey(RealmModel realm);
> }