
Announcing Duo’s two-factor authentication for Unix - there
http://blog.duosecurity.com/2011/04/announcing-duos-two-factor-authentication-for-unix/
======
heyrhett
This is awesome. Truly a modern-day way of securing boxes.

Of course, it makes it more of a hassle to maintain a machine, and you might
get temporarily locked out if their VOIP line or whatever goes down, but the
same could be said about fingerprint readers. I personally try to avoid those
mechanisms if at all possible, but it's great that someone is offering this as
a simple service. Really cool!

~~~
JangoSteve
You actually don't get locked out if their service goes down (I happened to
have asked them this the other day), it fails the other way by default.

Edit: See jonoberheide's explanation below for more info.

~~~
zecg
That's a rather bad default. If you need two-factor authentication for a
system, you probably want it to remain locked.

~~~
JangoSteve
I disagree. Having a 2FA that sometimes (i.e. very rarely, but not never) goes
down is still safer than no 2FA, and I can never afford to be locked out of my
server.

However, I could also see the opposite case being made. And I assume this is
precisely why they made it an easy config change, to make it behave however
you prefer.

------
r00fus
This is more than just 2-factor auth, it's out-of-band auth, which means that
a MITM can't compromise without having your 2nd factor.

This is definitely awesome, but my remaining concern is, what happens if/when
duosecurity.com is DOS'd or is otherwise down?

~~~
jonoberheide
Check out the login_duo(8) man page. You can specify a failmode configuration
option to fail safe (allow access) or fail secure (deny access) if there is a
connectivity loss between your servers and Duo's service.

------
swolchok
Google's doing it too: <http://code.google.com/p/google-authenticator/>

Howto: [http://www.mnxsolutions.com/security/two-factor-ssh-with-
goo...](http://www.mnxsolutions.com/security/two-factor-ssh-with-google-
authenticator.html)

EDIT: per my post in a sibling thread, Dug Song points out in the comments at
the Howto that Google Authenticator can't be used as a second factor alongside
SSH public key authentication.

~~~
draebek
I haven't looked very hard at the Google stuff (thanks for pointing it out
because now it's on my radar) but if it's open source I'm hoping it's designed
in such a way that one could make a login_google that works similarly to
login_duo, which looks to me from the blog post to require authentication and
then exec your login shell upon success.

------
jvdongen
Implementing two factor auth on linux is actually fairly easy. We use a 15-odd
line pam_script script that for ssh logins:

\- checks to see if there is a authentication code in a hidden file in your
homedir

\- if not it validates the password you gave

\- if that succeeds generate a 6 digit random number and stores a hash of the
number in a hidden file in your homedir and sends it as an SMS to your mobile
phone (phone number comes from ldap)

\- rejects your login

\- you login again, now using the pincode send to your mobile as a password

\- the hidden file now exists and the pincode you entered is hashed and
compared to the hash stored in the file before

\- if they match, your allowed to login.

Simple to implement, fairly strong security wise, logical extension to
password-only authentication, no additional account management overhead over
standard ldap, reasonable user friendly and very cheap.

We use it also in combination with nomachines nx for remote desktop access.

[edit: formatting]

------
nwilkens
We have been testing this over at MNX Solutions, and really like the
implementation.

Central account management, logging, etc. is one area that is quite nice.

Of course jonoberheide mentions some others that are pretty compelling --
authentication methods, integration points and supported platforms.

------
oomkiller
This looks really cool, but does anyone else have a hard time handing over any
authentication responsibilities to a third party? What if they are compromised
or DDOSed, are you locked out of your box?

~~~
tuebor
The service was designed to isolate trust to only secondary login verification
via a user-enrolled device. If any part of the system (including the user's
phone) were to be compromised or disabled, an attacker would still need to
have stolen your primary credentials to log in.

The choice of being locked out or not on Duo failure is a configuration option
("failmode"), with a fail-safe default.

In any usable system, security is never absolute, but a calculated abatement
of risk (you still use HTTPS anyway, right? ;-). Two-factor auth protects
against the most common path to account takeover today (credential theft), and
Duo's approach intends to make it actually usable and deployable.

------
tshtf
Looks neat. Can anyone think of a reason to prefer this over Google
Authenticator (which also has nice PAM plugins)? The risk of a outage with
duosecurity.com concerns me.

~~~
jonoberheide
Duo offers a number of features above and beyond Google Authenticator:

\- more flexibility in choice of authentication method (voice, SMS, soft
token, hard token, Duo Push)

\- more supported mobile platforms (Android, iPhone, Blackberry, WinMo, Palm
WebOS, Symbian, J2ME)

\- more integrations (VPNs, UNIX logins, web apps, etc)

Not to mention all the features that come along with being a fully-fledged
authentication service such as account management, fraud alerting, logging,
etc. Feel free to give it a shot and decide for yourself. :-)

Disclaimer: if it's not obvious from my gushing, I'm affiliated with Duo. ;-)

------
zokier
"This also works for user-local installations (e.g. $HOME/bin) without root
access in shared web hosting environments just specify the location of
login_duo.conf with -c."

Sounds interesting. Does this mean that users can setup Duo by themselves?
What happens if many (>10) users use their own Duo accounts on the same host?

edit: One more question: if users use the mobile app for generating passcodes,
is the system still dependent on Duo's servers?

~~~
tuebor
Yes, users can set up Duo by themselves. If 10 users use their own Duo
accounts on the same host, they're replicating the work to manage their own
Duo configurations, is all (and there's no centralized management of those
users' credentials by the system administrator).

Currently, duo_unix does not have a non-service option to use manually-
configured local secrets. It's something that could be added easily, but at
the expense of centralized management, logging, audit, enrollment, etc.

Folks who only want to use one-time credentials they need to manually
provision for each account are probably better off using OPIE or Google
Authenticator for now.

------
jm3
I use Duo to harden ssh connections from work to my box at home since I don't
like leaving my home network unsecured. When people hear my iPhone buzz with
the Duo authenticator callback when I open an ssh connection, they pretty much
freak out at how cool it is.

------
mstanislav
Duo's offering is much better than anything else (Yubikey, Google
Authenticator, etc.) I've tried. The management of accounts, easy SSH
integration, and multiple-method authentication allow me to actually _use_
two-factor rather than fight with it.

------
mmalik
really interesting how cloud and managed services are slowly making their way
to enterprise security

~~~
JakeSc
Interesting, and a bit scary, wouldn't you say? Not with Duo necessarily, but
I've always been wary of someone else having physical control over my data.

------
smcp
Will be testing it soon I think

