Freeradius and 2 Factor Authentication
owen.nick at gmail.com
Tue Jun 7 16:27:25 CEST 2016
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
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
>> > 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
>> > 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.
>> > 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
> 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!
WiKID Systems, Inc.
Commercial/Open Source Two-Factor Authentication
More information about the Freeradius-Users