Project

General

Profile

Actions

Feature #10377

open

Allow usage of TOTP (Google-Authenticator) without PIN

Added by Andreas Heckmann almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
FreeRADIUS
Target version:
-
Start date:
03/26/2020
Due date:
% Done:

0%

Estimated time:
Plus Target Version:

Description

Currently it is not possible to create a radius user with TOTP enabled without entering an additional pin.
So to authentiate as that user, you have to enter the minimum 4 digit pin + 6 digit TOTP as password.

For scenarios like "openvpn ssl/tls with userauth", it would be much more user friendly to only use the TOTP without an additional pin.
First factor ist the cert, second factor the totp-secret from the phone.

So it would be nice to allow an empty entry for the pin on the create/modify-user page if totp (Google Authenticator) mode is used
and to modify the totp-check to handle the case when no password is set.

Actions #1

Updated by Ben Cronce almost 4 years ago

Pardon my lack of experience using openvpn, but would this request mean all someone needs is the username? TOTP really only protects against drag netting. 6 digit TOTP is no stronger than a random 6 char pin. If you want convenience, just use that. And more convenient to boot. Don't need to look at your phone every time.

Actions #2

Updated by Jim Pingle almost 4 years ago

  • Priority changed from Normal to Very Low

While the GA script allows omitting the PIN I don't see why you'd want to reduce the security in that way. Part of the strength is that the OTP code is both something you know (your PIN) plus something you have (The OTP code/secret key). If someone snagged a device with the VPN TLS key and/or cert and the OTP code generator, they could still get access since both are something you have. The PIN makes that tougher since they'd need to have that as well and it isn't stored.

Ben Cronce wrote:

Pardon my lack of experience using openvpn, but would this request mean all someone needs is the username? TOTP really only protects against drag netting. 6 digit TOTP is no stronger than a random 6 char pin. If you want convenience, just use that. And more convenient to boot. Don't need to look at your phone every time.

In theory the OTP generated 6-digit codes are better than a static 6-digit password since they would be neigh impossible to brute force. The code is always changing. The odds of a brute force attempt guessing the same six digit code generated by the OTP process are low, though it is not impossible. I still wouldn't trust it alone without a PIN.

tl;dr If someone submits a PR, we can consider it, but not unless it also comes with a hefty security warning against doing that.

Actions #3

Updated by Andreas Heckmann almost 4 years ago

Thanks for your answers.

I would agree, generally the 4 digit pin + totp makes the system safer.

Here are our thoughts, why we would do it with plain totp:
The default setup of the openvpn client allows storing the password locally, so we do not want to use a fixed password for openvpn dialin.
Also in practice, many people tend to store pins/passwords unencrypted on the system so a fixed password or an additional pin (stored side by side with the tls cert) wolud not increase security.

Without plain totp the attacker must control both devices (totp-device vpn-device), hack or steel them to gain access.
In my opinion hacking phone and vpn-client device is much harder than only to hack the vpn-device alone (so totp on the phone increases security).
More easier might be to steal both devices, but then the attacker has a phone with minimum 4 digit pin or fingerprint to hack. (which also increases security)

For our scenario this would be ok.

I will have a look, if I can find the time to provide a PR, did not do that before, so if somebody is willing to help, i would be happy.

Security Warning makes sense ...

Actions #4

Updated by Jim Pingle almost 4 years ago

Since the user enters the PIN alongside the randomly generated OTP code (password=PIN+CODE) I am not seeing how any client could be storing that PIN unencrypted effectively.

Allowing weaker security because some users behave in an insecure manner seems backwards, too. This is about making them more secure, not about enabling their bad behavior.

Actions

Also available in: Atom PDF