I just don't have the time to fully document this although its on my
long growing todo list. My suggestion is to walk through how the
authenticators work for password validation and otp validation and
derive things from there. I'm pretty sure and hopeful that the current
SPIs that exist are good enough. Just not sure yet which is why they
aren't documented, public, or have quickstarts or examples.
On 7/25/17 4:21 AM, Dobbels, Andy wrote:
> 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>> _______________________________________________
> keycloak-dev mailing list
>keycloak-dev at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-dev