Support TOTP as an authentication method

[dave (David Harper)]

Rationale

It would be great if Tryton allowed Time-based One Time Passwords (TOTP) to be used an authentication method. This would give system administrators an additional option when configuring Multi Factor Authentication (MFA), and could be used in addition (or as an alternative) to the Authentication via SMS provided by the SMS Authentication module.

Proposal

Add a new authentication_totp module which allows users to setup TOTP secrets, share them with their authenticator app / program, and use TOTP codes for authentication.

To do this the User model would need to store the user’s TOTP secret and restrict access to it.

A new authentication method called totp would require the user to provide a totp_code obtained from their authenticator app / program.

A new model would, along with passlib.totp, check whether the TOTP code provided by the user is valid. On successful attempts to authenticate, the new model would store the counter used to validate the TOTP code.
Authentication would fail if the same (or an earlier) counter has already been use. This is to stop replay attacks, so it might also be good to let the user know if this happens to alert them to the fact that their account may have been compromised?

A wizard would also be provided so users can setup a TOTP secret and share it with their authenticator app / program. Once the secret has been shown to the user, the user would have to enter in a valid TOTP code from their authenticator app / program, before the secret is saved. This would ensure that the user has correctly stored the shared secret.
This could be made easy for the user by showing them a trytond.tools.qrcode with the secret in a format that is commonly understood by authenticator apps / programs.

How should authentication for users that do not have a TOTP secret be handled? A user will not be able to set their own TOTP secret if they have not logged in, but may not be able to login without one?

Is this something that might be a good addition to the standard modules?

Implementation

TBC

[ced (Cédric Krier)]

@dave

it might also be good to let the user know if this happens to alert them to the fact that their account may have been compromised?

I think this could be a more general notification about authentication failure. For example we could send email to the user on authentication failure and/or on authentication from unknown device/network etc.

@dave

This could be made easy for the user by showing them a trytond.tools.qrcode with the secret in a format that is commonly understood by authenticator apps / programs.

I think there should be also the option to get the secret directly without qrcode as qrcode libraries may not be available or user may not have a device to scan qrcode.

@dave

How should authentication for users that do not have a TOTP secret be handled? A user will not be able to set their own TOTP secret if they have not logged in, but may not be able to login without one?

I think we have enough flexibility with the authentications parameter:

• totp,password for only TOTP or password
• password+totp for password and TOTP (fails for user without TOTP)
• password+totp,password for password and/or TOTP

So it is up to the administrator to decide how to bootstrap user authentication.
But we may add an option to totp to decide what to do for user without TOTP configured like ?enforced=0.

[htgoebel (Hartmut Goebel)]

Adding TOTP support is a Good Thing™.

Regarding the authentications parameter:

• totp does not make sense, as it eliminates the other factor (“something you know”)
• password+totp,password does not make sense either as it would eliminate the TOTP.

Depending on what API will be protected, we might need some token based authentication, too, to allow automated scripts to login.