10:17 a.m.
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