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/jav a/org/keycloak/utils/TotpUtils.java 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