[keycloak-dev] OTP string based secrets

[Dobbels, Andy]

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 at 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