Comment by bubblethink

> Can't get why large companies/universities have boners for proprietary crap like duo.

It's like the classic HN argument of "Why don't you just use rsync/sftp vs dropbox" - because it's easier. For users, for admins, for the business.

The biggest problem with rolling out 2FA is onboarding and adoption.

Onboarding people is a massive pain in the arse. Issuing hardware tokens to people is even more of a giant pain in the arse, particularly if you have more than a handful of people in more than one city or country.

We deployed Duo because it allowed us to add 2FA reasonably easy to a wide range of services. It allowed us to require our contractors in countries like India and the Philippines to use it. They all have phones, even basic android devices can run it.

Rolling out physical tokens requires us to mail them out to people. Everything we sent to our offices in Spain larger than a letter got caught in customs for three months and/or "lost". Even USB thumb drives.

I've worked with people who are continually losing or destroying phones, keys, wallets, etc. Making them carry a hardware token, which will also get lost/destroyed means you're now constantly issuing them a new one.

On the systems side of things - it allowed us to add 2FA to devices that don't support it, or don't support the same 2FA you've chosen for everything else.

On the support side of things, it was dead easy to have automatic enrolment/signup based on existing processes (eg read LDAP/AD group membership), and it has a UI that actually allows us to properly delegate access to support staff.

Could we have rolled our own? Absolutely. But we'd have had to spend a lot more time, and a lot more money setting it up and maintaining it, and it gives good enough security.

Our biggest threat isn't a nation state or directed attack where someone can steal your phone and pull the token secrets.

Our biggest threat is Jim from Marketing who used the same damn password for his corporate email as he used when signing up for MarketingCon, and then having that registrant database leak.

The universities often receive "grants" from the vendors to foster initial development along with incentives provided based on adoption and usage.. https://www.azcentral.com/story/news/local/arizona-education...

It's not just universities, it's basically any Windows centric place that seems to gravitate towards packaged solutions rather than understanding or implementing the tech piecemeal.

> A company comes along and says, "Here's some textbook standard stuff, and here we add our lock-in on top of it. Would you like the lock-in ?" And everyone says, "Yes please."

That's not the sales pitch, _at all_, and you belie your inexperience in this understanding. Perhaps if you tried working for a big company or a university and began to understand the scale of the things they deal with in regards to identity and access management, you'd understand better. Let me expand on this.

What a company like Duo, OneLogin, Okta, IDaptive, etc. offers is not "textbook standard stuff". Sure, under the hood their system no doubt uses a ton of open source components, like anyone's does, glued together with their own secret sauce. That's the product. It's part of what they're selling you, but it's not all. You need to consider:

* Service operations and maintenance

* Security, scaling and capacity issues, upgrades, etc

* Ongoing development to keep the product current with the market (not much use to offer an authentication solution if it doesn't have the protocols and capabilities the other apps in the market that it is going to be interfacing with will require)

* Support and documentation

* Privacy and compliance

* Implementation and onboarding services, integration consultation and other professional services

The product itself is a turnkey solution, virtually guaranteed by the terms of service to be be fit for purpose, which means your overworked team has some hope of actually implementing it to the point of onboarding users within a quarter / semester or two rather than waiting for a slow project to even set up and get a proof of concept working with a home-built solution.

I'm not saying there isn't a place for home built solutions - I myself have authored extensive home-brewed configuration management software and workflow automation code in an academic environment. Still, there are certain critical pieces of infrastructure that are absolutely best left to purchasing solutions from teams of professionals that have invested their life's work into one particular concern or other.

That said:

> TOTP/HOTP don't provide phishing protection

This is not quite true. You can get a user's password, but the whole point of 2FA is that the password on its own should be useless. Of course, if you're re-using that password somewhere else where there is no 2FA, there is a vulnerability; however, almost all external services run by a competent IT org should be fronted by the same IDP at this point, and if you're not there yet you have to spend the cash to do it if you want meaningful security. Stealing the password should be pretty close to a non-impactful event at this point.

It is true that it is far better to have push-based authentication set up - something Duo pioneered, and most vendors have also implemented. For my current set of users, I've made it a mandatory policy; we don't allow SMS or DTMF auth at all. However, one could still be fooled by a phishing page that mimicks our login screen; it would be the absence of a working push that would have to tip the user off that something has happened. Some say "user education" is the key here, and I have had some mixed luck with that.

> However, it should all still be open standards based. Not some hacked up garbage that needs google play services.

If we want the convenience of push auth (which is actually better thought of as fingerprint auth, if you have MDM on your end-user's phones and push a policy that incentivizes the use of Touch ID by virtue of making the password too long for thenm to want to type it), then we need to deal with app stores. It's not like any IT-supported end user is going to have a phone that isn't either a well-supported Android or iPhone model; getting push services working basically requires going with what the Big Two want on that front. What choice do we really have?

> So the right way forward is hardware based keys.

I've maintained an RSA infrastructure, and have dabbled in Yubikeys, but the fact is: these things are expensive, they need to be replaced more often than we'd like, there are license costs for many of them, users lose them or leave them at home, you might un out of stock of them and have difficulties onboarding people, auditing their rollout and usage is more difficult, support for using them with a mobile phone is shit, etc. so many of the advantages over a phone app are moot.

They also aren't as physically secure as a phone, obviously. One can imagine a situation where a high value target is spearphished for their password and mugged for their RSA key in the building's parking lot one day. I'd far rather a physically secure, GPS-trackable, remote-wipeable iPhone get lost with their software token on it than a push-button RSA token.

Cryptocards that require a password are a solution some government agencies use, in my understanding; this is also obviously going to be a turnkey proprietary solution that costs even more than anything discussed above.