Announcing Duo’s two-factor authentication for Unix | Hacker News Reader

Announcing Duo’s two-factor authentication for Unix

blog.duosecurity.com

67 pointsthere23 comments

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!

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.

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

For strictly secondary authentication, it's much more likely that an admin will lock themselves out through local misconfiguration than an attacker will find the mechanism disabled.

It's also a one-line configuration change.

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.

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?

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.

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

Howto: http://www.mnxsolutions.com/security/two-factor-ssh-with-goo...

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.

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.

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]

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.

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?

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.

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.

Well, Dug Song of Duo Security points out that you can't use Google Authenticator and public key authentication in conjunction with each other over SSH at the bottom of this howto: http://www.mnxsolutions.com/security/two-factor-ssh-with-goo...

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. ;-)

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

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.

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.

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.

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

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.

Will be testing it soon I think

Reply on news.ycombinator.com