[keycloak-dev] usability vs. security

[Bill Burke]

Ya, Marek's right, we'd also have to store non-hashed passwords which we 
don't want to do :(

On 10/8/2013 4:12 AM, Stian Thorgersen wrote:
> We could auto-generate the application password by default. Then there's an option to either reset the password to a new generated password, or to manually enter one. If it's a generated password the password is stored in plain text, and is also added to the config files. If it's not a generated password it's stored salted/hashed in DB, and hence not available in the config files. Personally I think that's a nice compromise between convenience and security.
>
> BTW Others I've come across so far (Google, Facebook, Twitter, GitHub, Kinvey, StackMob, etc, etc.) all just provides a generated client id and secret, which are available in plain-text through the respective dev consoles.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 8 October, 2013 8:50:01 AM
>> Subject: Re: [keycloak-dev] usability vs. security
>>
>> On 7.10.2013 16:14, Bill Burke wrote:
>>> I'd like to have it that when an application is created in the admin
>>> console, the admin can view the exact configuration files needed to
>>> install in their application to enable security.
>>>
>>> Unfortunately, this would involve populating application credentials in
>>> the config file which would require exposing the application credentials
>>> through a REST interface albeit secure REST interface.
>> Security is one thing and another important thing is that application
>> credentials are actually saved in Picketlink DB (and I am doing
>> similarly for Mongo impl) in the form of salted hash and it's not
>> possible to restore original plain-text password from DB. Maybe we can
>> fill all things into configuration file except the password/totp and
>> this will be only thing which would need to be manually added into
>> configuration file by user himself? So generated config files could
>> possibly look like this:
>>
>> {
>>     "realm" : "demo",
>>     "resource" : "customer-portal",
>>     "realm-public-key" :
>> "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
>>     "auth-url" :
>> "http://localhost:8080/auth-server/rest/realms/demo/tokens/login",
>>     "code-url" :
>> "http://localhost:8080/auth-server/rest/realms/demo/tokens/access/codes",
>>      "ssl-not-required" : true,
>>      "credentials" : {
>>         "password" : "<REPLACE WITH YOUR PASSWORD>"
>>      }
>> }
>>
>> I think that auto-generation of credentials through the Admin UI would
>> be also nice feature. After triggering auto-generation from admin UI,
>> password could be saved into underlying storage and displayed to user in
>> plain-text just once so that he can fill it into configuration file.
>>
>> Marek
>>>
>>> Do you think it is such a big security hole to allow for this?  I've
>>> been trying to keep the mantra to not expose credentials anywhere if
>>> possible, yet this is a very nice security usability feature.  We could
>>> even have it that an application password, totp, and/or cert is auto
>>> generated.
>>>
>>> Thoughts?
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com