Re: [keycloak-dev] OTP string based secrets

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/o... On 13 July 2017 at 17:17, Dobbels, Andy <adobbels(a)bottomline.com&gt; 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(a)lists.jboss.org [mailto:keycloak-dev-bounces@ > lists.jboss.org] On Behalf Of Bill Burke > Sent: 12 July 2017 23:16 > To: keycloak-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev