<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Dennis,<br>
<br>
</div>
<blockquote type="cite"
cite="mid:0160e80a-e09d-a9b8-510d-9ba41f29b6be@cineca.it">Yes!
<br>
<br>
That was the problem!
<br>
</blockquote>
Thanks for the positive feedback. Maybe it would be helpful to set a
explizit remark in ref.pdf about the secret encoding (imho, there is
something in goodies, but not in ref.pdf if I remember correctly)<br>
<br>
Some BTWs for others, who might find this useful:<br>
<br>
- People using Radiator in a more LDAP driven way (ie AD
backend) may wonder, why TOTP needs a SQL. Reason is afaik to keep
track of used tokens to avoid replay attacs and to blackout users
using wrong tokens (brute force attacs)<br>
- if you run with a LDAP based user directory, in my
mind the TOTP secret should be stored on the directory as well. Our
solution is to retrieve the secret during the LDAP backend
communication<br>
and store/update it in SQL(ite) database used for
AUTHBY SQLTOTP afterwards using AUTHBY GROUP. So no maintenance of
the SQL is needed then.<br>
- Permissions on directory should be adjusted on the
attribute holding the secret to avoid exposure (Example: the way AD
protects user certificates within AD)<span style="font-size:
14.000000pt; font-family: 'Helvetica'; font-weight: 700"><br>
</span><br>
- Any RFC compliant token generators do work (soft tokens on
mobile phones, PC OS, perl scripts) as well as hardware tokens
(Feitian C200 for example)<br>
- google uses HMAC SHA1 and 30sec. timestep, which is
also the default in Radiator AUTHBY SQLTOTP. Other token generators
may differ and it can be adjusted in radiator sql db in field 7 and
8 (algorithm and timestep) on a per user basis, too.<br>
<br>
cheers<br>
Martin<br>
</body>
</html>