Two-Factor Auth - Implementation details

[LukasReschke]

For ownCloud 8 we are aiming to implement Two-Factor authentication, the following requirements are given:

• Additions to core should be as minimal as possible. If possible parts should be implemented within an ownCloud application.
• Not to be implemented as \OC_User_Backend, this approach has been tried in the past but is a major hack
• Two-Factor Auth has to be compatible with all existing user backends without modifying them.
• Support application specific passwords (with Application we mean external application like mobile or web apps) - implementation should be generic to be able to reuse them for OAuth tokens (OAuth 2.0 support for ownCloud [$5] #10400). Application specific passwords will be valid for the whole ownCloud instance while OAuth tokens can be limited in the future then for specific scopes.
• The system should be pluggable to allow further authentication backends, per default it will support TOTP (Time-Based One-Time Password Algorithm) which is widely used.
• A personal console exists which:
  • Allows to register new token devices
  • Shows recently used token devices
  • Allows to revoke recently used token devices
• An administrative console exists which:
  • Allows admins to enforce enrollment for users
  • Allows admins to view enrollment status
  • Allows admins to view devices and revoke them
• If a revoked token is supplied the server will send back a statuscode which indicates that the token has been revoked

This issue is here to track the changes required for the change and also the required features. Any suggestions are welcome.

---

Todo:

• Refactor authentication from base.php into own classes (… in progress …)
• Add new authentication state ("2FA")
• Add code for 2FA app
• Add adapters for 2FA app
• Take pride and celebrate

[LukasReschke]

@MTRichards @karlitschek FYI

[PVince81]

So this means external apps do not need to send the user's password any more ? 😄

[LukasReschke]

So this means external apps do not need to send the user's password any more ?

Yes. - And if we implement this properly (aka: "plug OAuth above it") we can even limit the access scope of external applications 🎉

[karlitschek]

@LukasReschke Sounds good in general. I suggest to discuss this in a call the next few days.

[LukasReschke]

Sounds good in general. I suggest to discuss this in a call the next few days.

Sure. Feel free to make an invite.

[filippouni]

my two cents:
https://fidoalliance.org/specifications

[karlitschek]

Cool. Let´s implement this! 👍

[MTRichards]

Good stuff!

How do we handle this form of 2 factor for mobile and desktop? Do we need to consider adding an additional pin/something for the user to take advantage of 2 factor on the client too?

[LukasReschke]

How do we handle this form of 2 factor for mobile and desktop? Do we need to consider adding an additional pin/something for the user to take advantage of 2 factor on the client too?

Application-specific passwords, just like everybody else does it too. That should be sufficient for the first step. I'll ensure to return a proper status code to the client in case two-factor auth is needed so we can show a little popup like "Please generate a token at demo.owncloud.org".

Once everything is done we can think about implementing an OAuth like login approach for mobile devices. But I think we should get the basic right first :-)

I really don't want to throw too many different things together into this. - Would that work?

[MTRichards]

Out of the box, that would work.

Second step is, of course, to integrate with existing enterprise 2-factor systems for auth, such as RSA tokens or something like that. We should just make sure we have proper architecture to offload the 2 factor to an external system as well (or integrate with it), whichever makes more sense.

[LukasReschke]

Second step is, of course, to integrate with existing enterprise 2-factor systems for auth, such as RSA tokens or something like that. We should just make sure we have proper architecture to offload the 2 factor to an external system as well (or integrate with it), whichever makes more sense.

Sure. That is the goal, the whole system is meant to be pluggable. Throwing in your own self-made connector (SMS / Authy / SmartCard / whatever) should not be a problem with the architecture that I think of.

[leonardomarino]

Duo Security? They have libraries for php, see https://www.duosecurity.com/docs/duoweb

[Cysioland]

👍

[kriede]

Would love to see this!

[ghost]

@MTRichards I need a call regarding priority here

[MTRichards]

@LukasReschke this is related to what you discussed in Berlin, right? How does that relate to this? @karlitschek did you ever have the deeper conversation about how this impacts LDAP / AD?

@cmonteroluque unless I missed something, this is not ready for 8.2 certainly, and not required for 8.2.

[ghost]

@MTRichards ok, moved to 9.0

[PVince81]

Any progress here ?

Since we're past feature freeze, would move this to 9.1.