Re: [keycloak-dev] Storage protection

BTW the interface I proposed wouldn't work with a HSM, they do the encryption/decryption on board don't they? So it would be something like: public EncryptionProvider { public void generateKeys(RealmModel realm); public byte[] encrypt(byte[] b); public byte[] decrypt(byte[] b); public byte[] sign(byte[] b); } or something along those lines ;) ----- Original Message ----- > From: "Bruno Oliveira" <bruno(a)abstractj.org&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt;, "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 30 January, 2014 1:22:35 PM > Subject: Re: [keycloak-dev] Storage protection > > 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? First app startup I'd say. OOTB experience should be as simple as possible. Probably just bootstrap it in: https://github.com/keycloak/keycloak/blob/master/server/src/main/java/org... and set the location to ${jboss.config.dir}/keycloak.secret or something? > > -- > abstractj > > On January 30, 2014 at 8:12:44 AM, Stian Thorgersen (stian(a)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); >> } > >