Hi Bill, some answers inline. I forgot to add references.
--
abstractj
On January 27, 2014 at 1:53:39 PM, Bill Burke (bburke(a)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_Appli...).
>> # 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.