Freeradius and 2 Factor Authentication

[Nick Owen]

On Mon, Jun 6, 2016 at 9:32 PM, Peter Lambrechtsen <peter at crypt.nz> wrote:
> On Tue, Jun 7, 2016 at 2:22 AM, Nick Owen <owen.nick at gmail.com> wrote:
>
>> On Sun, Jun 5, 2016 at 5:17 PM, Peter Lambrechtsen <peter at crypt.nz> wrote:
>> > How is that any different to SecurID, safeword,Vasco or any of the other
>> > commercial token vendors?
>>
>> We are a vendor that uses asymmetric keys generated on the
>> devices/your on-premises server designed exactly to avoid this
>> 'vendor-in-the-middle' threat.   So, that's different.
>>
>
> But WiKiD is a public / private key solution where the client needs to
> communicate with the server. There doesn't seem to be any way to enroll a
> token without some sort of network connectivity back to the server.

That is correct.  This comes up in pre-sales sometimes, but not in
operation. I know that some markets it will never work, but most it
does fine.  People use 2FA to connect so they usually have a
connection.

We have a fall-back to a challenge-response mode for authentication if
the token device is out-of-coverage but no one has had to use it to my
knowledge.

>
>
>> >
>> > By it's very nature the secret needs to be kept somewhere. Yes Yubikey is
>> > marginally better as you can generate your own.
>> >
>> > But the CD that comes with your hard token had to be written somewhere
>> and
>> > the vendors keep a copy. I have in the past been able to get replacement
>> > keys when rebuilding a SecurID and Vasco box so it would surprise me if
>> > they destroyed all copies of the token data. The historic SecurID hack
>> > seems to indicate they didn't then.
>> >
>> http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-compromised/
>> >
>> > The beauty in soft tokens is it's trivial to reenroll everyone on next
>> > login. "Sorry our db with hashed passwords and otps got hacked. Please
>> > reenroll by scanning the qr and remove the old one."
>>
>> This is why I think the OTP algorithm is not that important.  The
>> important protocol for most orgs is radius, b/c it  will allow you to
>> move between auth servers easily.
>>
>
> This is where I fundamentally disagree with you. By using an open RFC
> standard algorithm it means I can easily move between hardware / software
> manufactures without being locked into any particular vendor. I could
> choose to allow end-users to enroll software tokens using a their phone, or
> have them bring their phone to a central location to be enrolled for them
> or build your own app to securely enroll them over SSL. Or use hard tokens
> and issue them that way. By using the same open algorithm you are no longer
> constrained to one vendor on one platform.

I agree with you in principal and we have looked at publishing the
algorithm. I'm still open to it.  We may have missed that boat. I
think most people don't care, just like they don't care about what
type of encryption you use. We could add TOTP to our server or support
yubikey as well.

>
>
>> > I see it no worse than any other OTP solution as the secret needs to be
>> > kept secret.
>>
>> I'll just say that I am very glad to not have possession of all our
>> customers' shared secrets.  It helps me sleep at night.
>>
>
> But you do require the client and server to be connected at some point and
> I couldn't see any offline / disconnected enrollment process. And if the
> server gets compromised the public keys can be rebuilt from the private
> keys.
>
> So there are pros & cons with each solution. But having an open standard
> that means you are vendor agnostic is surely a good thing?

yes, all things considered.  My experience is that they often are not.
Most of our pre-sales questions are "Does you system work with my
Cisco VPN?". To which I respond knowingly "does it support radius?".

So please know how much I appreciate this intelligent discussion!




-- 
--
Nick Owen
WiKID Systems, Inc.
http://www.wikidsystems.com
Commercial/Open Source Two-Factor Authentication