[RADIATOR] AuthSQLYubikey
Mike McCauley
mikem at open.com.au
Sun Oct 4 17:19:36 CDT 2009
Hello Jerome,
thanks for your note.
On Friday 25 September 2009 02:21:27 am jeje wrote:
> Hi there,
>
> I've found 2 more issues with AuthSQLYUBIKEY:
>
> - the code assumes the string sent by the key is 12 chars + 32 chars,
> otherwise the code thinks there's a static password in front
>
> This seems to be true only for "out of the box" keys, but when they
> are reprogrammed (using ykpersonalize in my case), the string can then
> be longer, up to 36 chars for the second part
>
> >From the help:
>
> Usage: ykpersonalize [options]
> -1 change the first configuration. This is the default and
> is normally used for true OTP generation.
> In this configuration, TKTFLAG_APPEND_CR is set by default.
> -2 change the second configuration. This is for Yubikey II only
> and is then normally used for static key generation.
> In this configuration, TKTFLAG_APPEND_CR, CFGFLAG_STATIC_TICKET,
> CFGFLAG_STRONG_PW1, CFGFLAG_STRONG_PW2 and CFGFLAG_MAN_UPDATE
> are set by default.
> -sFILE save configuration to FILE instead of key.
> (if FILE is -, send to stdout)
> -iFILE read configuration from FILE.
> (if FILE is -, read from stdin)
> -aXXX.. A 32 char hex value (not modhex) of a fixed AES key to use
> -cXXX.. A 12 char hex value to use as access code for programming
> (this does NOT SET the access code, that's done with -oaccess=)
> -oOPTION change configuration option. Possible OPTION arguments are:
> salt=ssssssss Salt to be used for key generation. If
> none is given, a unique random one will be
> generated.
> fixed=xxxxxxxxxxx The public identity of key, in MODHEX.
> This is 0-16 characters long.
>
> if you give a 16 chars fixed param, then it will break Radiator
> assumptions, the string generated by the yubikey will be 12+36 chars.
>
> Then Radiator thinks there's a static password for 2 factor auth, and
> the auth fails.
>
> I think this code has to be rewritten, sorry I have no clean patch to
> provide yet
Hmmm, this is a difficult problem: without some hard knowledge about the
length of the (optional) static password and/or the length of the string sent
by the key, it cant tell where the static password ends and the token string
starts.
If _all_ your keys are configured for the _same_ non-standard token string
length, then there might be a chance to add a new Radiator config parameter
that specifies how long your token string is. Is that viable?
>
> Second issue:
>
> I'm trying to use DBD::CSV for my tests, and when Radiator tries to
> update the database it does:
>
> Thu Sep 24 18:12:38 2009: ERR: do failed for 'update yubikeys set
> accessed=now(), counter=1, low=30090, high=253 where t
> okenId='SmVqZS5v'': Unknown function 'now'
>
> Thu Sep 24 18:12:38 2009: DEBUG: Radius::AuthSQLYUBIKEY IGNORE:
> Database update failed: jeje [jeje]
> Thu Sep 24 18:12:38 2009: DEBUG: AuthBy SQLYUBIKEY result: IGNORE,
> Database update failed
>
> And then the auth fails again...
>
> I don't think the function now() is standard SQL, probably the time
> should be done by Radiator, not assuming that the SQL frontend can do
> it lazily ;-)
The reason it is done this way it to support the case where multiple Radiator
hosts access a single SQL server. If the clocks on the Radiator hosts where
wrong, then clock skew could cause errors in the database.
We have now added to the AuthBy SQLYUBIKEY UpdateQuery parameter a new
positional parameter %5,
which is replaced by the current unix time on the Radiator host.
So now you could have something like:
UpdateQuery update yubikeys set accessed=%5, counter=%0, low=%1, high=%2 where
tokenId=%4
The change is now available in the latest patch set.
Cheers.
>
> Cheers,
>
> Jerome.
>
> On Thu, May 7, 2009 at 18:00, Sami Keski-Kasari <samikk at archred.com> wrote:
> > Hello,
> >
> > I am testing Yubikeys and find two issues:
> >
> > 1. Custom AuthSelect doesn't work because of this issue:
> >
> > --- Radius/AuthSQLYUBIKEY.pm-orig 2009-05-06 20:52:40.000000000
> > +0300 +++ Radius/AuthSQLYUBIKEY.pm 2009-05-06 20:53:14.000000000 +0300
> > @@ -17,7 +17,7 @@
> > use MIME::Base64;
> > use strict;
> >
> > -%Radius::AuthSQLDIGIPASS::ConfigKeywords =
> > +%Radius::AuthSQLYUBIKEY::ConfigKeywords =
> > ('AuthSelect' =>
> > ['string', 'SQL query that will be used to fetch Yubikey data from the
> > database. Special characters are permitted, and %0 is replaced with the
> > quoted user name. %1 is replaced with the token ID. The default works
> > with the sample yubikey database created by db_schema.sql from the
> > YubiKey Validation Server.', 0],
> > 'UpdateQuery' =>
> >
> > 2. Replay attack recoqnition is done now only via counter in Radiator.
> > I think that it should be done with counter, timestamp_low and
> > timestamp_high.
> >
> > Now the problem is that if you are using Replay attack recoqnition and
> > need more than one otp password you have to unplug and plug yubikey
> > everytime.
> >
> > Regards,
> > Sami
> >
> > _______________________________________________
> > radiator mailing list
> > radiator at open.com.au
> > http://www.open.com.au/mailman/listinfo/radiator
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Mike McCauley mikem at open.com.au
Open System Consultants Pty. Ltd
9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au
Phone +61 7 5598-7474 Fax +61 7 5598-7070
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, DIAMETER etc. Full source
on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
More information about the radiator
mailing list