Freeradius and 2 Factor Authentication

[Peter Lambrechtsen]

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.


> >
> > 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 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?