[jonoberheide]

Sorry to hear about your experience, Jarwain!

Duo offers a choice of authentication methods, depending on the usability and security requirements of your application or organization.

Duo Push is actually one of the easiest (and most secure) authentication methods, as one of the commenters pointed out:

https://www.youtube.com/watch?v=tPLxe9HUDjY

It might be worth pinging your IT/security dept to ask about enabling Duo Push as an option or to change the policy for SMS passcodes (eg. you can just have one passcode sent instead of ten).

- Jon Oberheide, Co-Founder & CTO @ Duo

[Bamberg]

Duo does work as advertised, and my uni uses it, but the privacy policy allows for a lot of personal data collection.

tldr: "Duo Security does not sell, rent, or trade and, except as described in this Privacy Policy, does not share any Personal Information with third parties for their promotional purposes." But Duo still collects A LOT of data on you.

From the policy: "Device-Specific Information: We also collect device-specific information (e.g. mobile and desktop) from you in order to provide the Services. Device-specific information includes:

attributes (e.g. hardware model, operating system, web browser version, as well as unique device identifiers and characteristics (such as, whether your device is “jailbroken,” whether you have a screen lock in place and whether your device has full disk encryption enabled)); connection information (e.g. name of your mobile operator or ISP, browser type, language and time zone, and mobile phone number); and device locations (e.g. internet protocol addresses and Wi-Fi). We may need to associate your device-specific information with your Personal Information on a periodic basis in order to confirm you as a user and to check the security on your device."

The policy continues to state that Duo may use this data for analytic/advertising purposes (although only in-house) as well as to comply with legal requests, subpoenas, NSLs etc.

Duo isn't collecting your data for nefarious purposes or to sell it to other companies but they still are collecting A LOT of it. Other two factor methods, like the one's used by Google and Facebook, allow clients to install their own code generators that don't collect personal data or even need access to the internet. Of course these methods don't have push requests that you can just approve rather than type in the code.

[tripzilch]

also, if it's a US company and it ever goes bankrupt/sells its assets, third party buyers aren't bound by any privacy policy whatsoever. yes, this is crazy and it means US privacy policies are basically meaningless; best just don't give them your data, but what can you do. personally I believe that collecting the data and pretending a privacy policy makes it okay, is nefarious by itself already.

[jonoberheide]

I think that's a fair read. The primary use of that data is for security use cases. Eg. if you're coming from an out-of-date browser or have risky Java/Flash plugin versions, we can notify you to update/remediate.

Another way to look at it: We collect security-relevant information on your device, but not your _personal_ data. In other words, we don't collect your email, photos, contacts, user-generated data, etc.

[samch]

I'm at a large research university, and we use Duo across the institution. It really does work as advertised. The Duo Push feature combined with my iPhone's TouchID is very convenient (Duo Push also works on other devices).

Most importantly to me, though, the system has thus far been completely reliable. I haven't yet heard of a single case where somebody couldn't log in because of Duo. I'm not sure what our enterprise agreement is / how much this all costs, but it's a very good system for us.

[paulmd]

cc: @jonoberheide

My Duo hardware token (the code generator with the button and the LCD) tends to "desynchronize" after long periods where you don't use it. The internal clock gets off, so it drifts in what token it returns vs what the server thinks it should be returning, and then it stops working.

Normally, if you log in on a regular basis the server corrects for this drift. There is probably a sliding window of N valid keys (say 10) and using one of them tells the server what the internal clock state is. But if you don't use it for a long time (more than 30 days in my experience), the clock drifts, you start going outside the window and it refuses to let you log in.

If your IT desk is open, they can "resync" it by typing in a couple numbers in a row, which lets the server scan the key sequence and find where your token is.

Use-case: We don't have Duo tokens rolled out system-wide, they are only issued for admin tasks and we have separate admin accounts for these with the Duo attached. I'm an "occasional sysadmin" who administrates several stable servers that mostly don't need to be touched.

As I don't need to use it day-to-day, my key desynchronizes quite often for me, I have had it happen at least 3 times. It would be bad if I had an after-hours emergency with my Duo token, I do not trust it. The hardware tokens are not reliable, in my book.

edit: The fix for me would be for the token to automatically resynchronize on the fly. Just like the IT guys can do, but over-the-wire. If the server sees (f.ex) three sequential login attempts with valid-but-stale keys, with the proper order and timing pattern, then it accepts them and resynchronizes the key window.

To prevent replay attacks, you would also need to add a constraint that the keys be newer than one ones last used for a sucessful login, but it should be doable. You would also want to avoid causing an account lockout as you type in the invalid keys.

[jonoberheide]

Hi Paul! I believe your token should automatically resync if you enter three consecutive correct passcodes that are outside (but forward of) the current valid window.

[Jarwain]

Huh, I never would've expected to hear from the CTO just from making this post.

Thanks for the reply! I'll definitely get in contact with the school's OIT to figure out alternate options for authentication

[jonoberheide]

No prob! I can't claim to be a HN veteran (/me glares at @tqbf), but if I hear people are having issues, happy to help.

[Jarwain]

So it turns out I can still use the Duo Mobile app. I have to re-add the device. Not the most intuitive but then again I figured it out on my own -shrugs-

[bkoehler]

I was a huge fan an evangelist of Duo up until the Duo Mobile 3.15.0 update December 13, 2016, which disabled the ability to approve Duo Push from a locked phone (lock screen, Android Wear). That change was horribly communicated and has been inadequately defended when challenged, and has shaken my faith in Duo.

[voidlogic]

Can Duo be used to Google Authenticator or do you have to use "Duo Push"?

[Jarwain]

Cannot use Google Authenticator. Can't even use Duo Push; this is the SMS functioniality.

I do plan on getting in contact with the schools OIT for enabling alternatives

[intrasight]

I hadn't heard of Duo. Just looked briefly at the site. Does anyone have a TL;DR on that? Why would one use that rather than the native 2FA?

[Bamberg]

They can send push requests that you can just approve on your mobile device, no typing in those codes. They also have backup methods that work w/o needing internet access on your phone.

I think institutions also use Duo because Duo takes care of the whole think whereas traditional 2FA isn't trivial to implement for the institution (generating tokens and all of that). At least that's what I was told by my institution when they made us start using Duo.

[intrasight]

> takes care of the whole thing But I would have assumed that there is considerable work necessary on the backend for a web server to integrate with Duo.