freeradius and yubikeys

Arran Cudbard-Bell a.cudbardb at freeradius.org
Sat May 10 20:01:48 CEST 2014


On 10 May 2014, at 17:01, Frederic Van Espen <frederic.ve at gmail.com> wrote:

> On Sat, May 10, 2014 at 2:44 PM, Arran Cudbard-Bell
> <a.cudbardb at freeradius.org> wrote:
>>> I don't believe the configuration was changed, and it was working on
>>> 3.0.2 with the password and token splitting done in the vhost config.
>>> I'll test later today with version 3.0.2 again to confirm.
>> 
>> OK.
>> 
> 
> Confirmed, without even touching the rlm_yubikey config file and
> simply downgrading the packages, authentication works fine. The API
> key was not changed in the config files.
> 
>> 
>> Thanks.
>> 
>> Hm, fixed that one issue, doubt it would of cause a validation error though.
>> 
>> The rest of the output was false positives. The server just exits without
>> attempting to cleanup unless you specify -m.
> 
> That's weird. I did start it like this: valgrind --leak-check=full
> /usr/sbin/freeradius -Xx -m

I've noticed it doesn't always go down cleanly for some reason. I ran it on my Ubuntu VM and confirmed it wasn't leaking handles.

>> I've made it a bit more strict about starting up with invalid API keys, so if
>> it's getting the config from where other than where you think it is, it'll
>> refuse to start.
> 
> I took a few HTTP traces to compare the difference between 3.0.2 and
> 3.0.3. Here's the request for 3.0.2:
> 
> 48.948991 172.16.35.65 -> 103.6.213.69 HTTP 293 GET
> /wsapi/2.0/verify?id=<XXXXX>&nonce=rvepnyfmrllivnnlbuorqnpetedqwldn&otp=ccccccdbkebjdktflifkufelthvkbjucgfefkijlvrdc&h=V1HcnOhTiaW2mxs5Zgeg1VqFU5k%3D
> HTTP/1.1
> 
> And here's one for 3.0.3:
>  0.033011 172.16.35.65 -> 109.74.193.72 HTTP 264 GET
> /wsapi/2.0/verify?id=<XXXXX>&nonce=tughzbxuolnhvjqhyryljthvdkwwyjnu&otp=testingpassword&h=uJfyrooihrq7onQhW8coLiyWARE%3D
> HTTP/1.1
> 
> Looks like we're sending the user's password instead of the OTP :-)

That'd be a problem :P shame about the crap error message, it'd of been easier to figure out if their servers had sent back something meaningful, 'o' isn't even a modhex char.

> I
> guess that should be easy to fix?

Good catch. Half the original auth code got the passcode from char *passcode, and the other used VALUE_PAIR *request->password *sigh*. Ok, all uses passcode now, should work.

You know you can do the decryption locally right? You don't need to use their servers. The module didn't even have support for ykclient until they grumbled about it.

You can put the shared keys in LDAP as well, you just need to figure out a place to stick the replay counters.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140510/bf07809b/attachment-0001.pgp>


More information about the Freeradius-Users mailing list