[keycloak-dev] OTP string based secrets

Tue Jul 25 04:21:39 EDT 2017

Hi,

Did anyone have any thoughts on how to progress this?

thanks,

Andy

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Dobbels, Andy
Sent: 19 July 2017 09:38
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

Hi Bill, 

Could you give me a link to any of the undocumented SPI's for custom storage of secrets? I'll start with that first if that should fix my issue in the short term.

Stian, is there any work underway to denormalize OTP policy to allow over time migration of OTP secrets and parameters similar to passwords? Is there agreement that that's the way forward?
What's involved in that? We might be able to put a PR together depending on effort and complexity involved.

Thanks,

Andy

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: 14 July 2017 16:14
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

Our secrets are a string and the bytes of the string are converted to 
base32.   Andy Dobbels uses keys that are raw bytes, not strings.  See 
the difference?

On 7/14/17 12:14 AM, Stian Thorgersen wrote:
> The OTP strings we have today are already encoded with Base32 as the 
> OTP specs mandates [1] so I don't really understand what this whole 
> thread is about.
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/services/src/main/jav
> a/org/keycloak/utils/TotpUtils.java
>
> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
>
>> Hi Bill,
>>
>> Thanks for the response and sorry for the double post.
>>
>> My main concern is interoperability and not being able to import the 
>> secrets from existing OTP solutions even though they are all based on 
>> the same RFC. Creating an SPI to allow the secret to be stored as a
>> Base32 string instead of plain text doesn't seem right. The rest of 
>> the code is fine and it's all there. If you don't mind I would like 
>> to explore a few options that don't require an update of all existing credentials.
>>
>> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
>> That way we can keep the existing data as is. If the prefix isn't 
>> there then it's plain text.
>> or
>> 2: Add a column that indicates what format the credentials.value 
>> property is encoded in. Values could be Plain or Base32. Someone 
>> could easily add
>> Base64 or Hex if that helps their adoption/migration of otp. Perhaps 
>> later on this could open the door to encrypting the secret by having 
>> a value called "encrypted".
>>
>> Perhaps there are other options?
>> Is the undocumented SPI purely dealing with how the value is encoded?
>>
>> Thanks,
>>
>> Andy
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org
>> [mailto:keycloak-dev-bounces@ lists.jboss.org] On Behalf Of Bill 
>> Burke
>> Sent: 12 July 2017 23:16
>> To: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] OTP string based secrets
>>
>>
>>
>> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
>>> Hi,
>>>
>>> We are adopting Keycloak and are trying to move our OTP tokens over 
>>> to
>> Keycloak. However, Keycloak can only use secrets that are 
>> alphanumeric strings whereas our existing implementation and most 
>> hard and software tokens we have used use the full range of binary 
>> values when generating secrets.
>>
>>> 2 questions:
>>> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
>> Should it be a concern?  Its currently a randomly generated 20 
>> character alpha-numeric string.  That's not enough entropy?
>>
>>
>>> 2: If we provided a PR that migrated the existing data by 
>>> re-encoding
>> all existing secrets as Base32 and updated the code to assume Base32 
>> instead of string be acceptable?
>>> This would be a non breaking change but allow anyone using existing 
>>> OTP
>> tokens to migrate their secrets which I don't think they can at the moment.
>> We have undocumented SPIs to support other storage options for 
>> different credential types.  If you want to use the data model that's 
>> currently there you have to encode your secrets as strings. We're 
>> limited in the fact that our current OTP storage must be backward 
>> compatible.  Also, don't want to have to recalculate storage for 
>> every single OTP record of existing deployments when migrating.
>>
>> We could though absolutely change how future secrets are generated if 
>> you feel the entropy is a concern.
>>
>> Bill
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev