[RADIATOR] AuthSQLYubikey

[jeje]

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

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 ;-)

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
>