[keycloak-dev] OTP string based secrets

[Stian Thorgersen]

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/java/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
>