
<html><head></head><body><div>The current KeyCloak HOTP implementation assumes that a HOTP key (aka<br class="-x-evo-wrap-br">seed, aka initialization vector) is stored as string, and thus contains<br class="-x-evo-wrap-br">only printable characters. However, the HOTP standard (RFC 4226)<br class="-x-evo-wrap-br">doesn't impose any restrictions on key material; any arbitrary byte<br class="-x-evo-wrap-br">array is acceptable.</div><div><br></div><div>Moreover, many hardware HOTP tokens are pre-programmed at the factory,<br class="-x-evo-wrap-br">and do contain non-printable seeds. Even though KeyCloak doesn't<br class="-x-evo-wrap-br">support hardware tokens out of the box, developers could implement it<br class="-x-evo-wrap-br">by extending KeyCloak and employing existing algorithms. Unfortunately,<br class="-x-evo-wrap-br">the existing convention (to store HOTP seeds as printable strings)<br class="-x-evo-wrap-br">makes this impossible.</div><div><br></div><div>For the "password" credential type, the "value" field is already stored<br class="-x-evo-wrap-br">as Base64. I think "hotp" credentials could also be stored as Base64 or<br class="-x-evo-wrap-br">hex; another option would be to store the "value" field as BLOB (like<br class="-x-evo-wrap-br">it's already done for the "salt" field).</div><div><br></div><div>I think I could produce a PR for this, I only need to know which<br class="-x-evo-wrap-br">scenario is preferred.</div><div><br></div><div>Cheers,</div><div>Mitya</div><div><br></div></body></html>