FreeRadius or something else, for MFA without a PIN code?

Codefighter

I have setup a pfSense firewall with OpenVPN and FreeRadius, and it's all working great. But I do have a problem with the fact that the FreeRadius users require a PIN code to enable MFA (mOTP or Goggle-Authenticator).

I use Google Authenticator and Microsoft Authenticator for services like Google, ZoHo, GitHub, Microsoft O365, GoDaddy, DigitalOcean and more, and none of them require a PIN from me. FreeRadius PIN management is a problem as users forget them, can't change them, and as an admin I should not know a users PIN.

Given that most phones have some form of access control like FaceID, fingerprint reader or lockscreen PIN, it seems like requiring another PIN is just an annoyance, especially since it's not needed by the services I listed above.

I see someone requested this same feature in 2020, but it's just 'Open':
https://redmine.pfsense.org/issues/10377

So, is there any pfSense plugin, FreeRadius plugin/setting, or 3rd party cloud provider that would allow me to simply generate TOTP for a user in my setup without requiring them to use a PIN?

NetCoreIT

It's been a while since this thread was opened, and having encountered this issue myself, I want to share the solution with others.

Summary:
pfSense version: 2.8.1
FreeRADIUS version: 0.15.14

To make FreeRADIUS accept only the OTP code without requiring a PIN prefix, you need to make two modifications:

1️⃣ Modify /usr/local/etc/raddb/scripts/googleauth.py:

#!/usr/local/bin/python3.11

import sys
import time
import struct
import hmac
import hashlib
import base64
import syslog

def authenticate(username, secretkey, code_attempt):
    tm = int(time.time() / 30)

    secretkey = base64.b32decode(secretkey)

    # try 30 seconds behind and ahead as well
    for ix in [-1, 0, 1]:
        b = struct.pack(">q", tm + ix)
        hm = hmac.HMAC(secretkey, b, hashlib.sha1).digest()
        offset = hm[-1] & 0x0F
        truncatedHash = hm[offset:offset+4]
        code = struct.unpack(">L", truncatedHash)[0]
        code &= 0x7FFFFFFF
        code %= 1000000

        if ("%06d" % code) == str(code_attempt):
            syslog.syslog(syslog.LOG_NOTICE, "freeRADIUS: Google Authenticator - Authentication successful for user: " + username)
            return True

    syslog.syslog(syslog.LOG_ERR, "freeRADIUS: Google Authenticator - Authentication failed for user: " + username)
    return False

if len(sys.argv) != 4:
    syslog.syslog(syslog.LOG_ERR, "freeRADIUS: Google Authenticator - wrong syntax - USAGE: googleauth.py Username, Secret-Key, Auth-Attempt")
    exit(1)

auth = authenticate(sys.argv[1], sys.argv[2], sys.argv[3])

if auth:
    exit(0)

exit(1)

2️⃣ Modify /usr/local/etc/raddb/mods-enabled/googleauth:

Locate the exec googleauth section and update it to remove the PIN parameter:

exec googleauth {
    wait = yes
    program = "/usr/local/etc/raddb/scripts/googleauth.py %{request:User-Name} %{reply:MOTP-Init-Secret} %{request:User-Password}"
}

Note: The key change is removing %{reply:MOTP-PIN} so FreeRADIUS will use only the OTP.

After these modifications, FreeRADIUS will accept only the OTP when connecting via OpenVPN, without requiring a PIN. Remember to restart FreeRADIUS after making these changes.

BONUS TIP
When using FreeRADIUS on pfSense with Google Authenticator, the OTP QR code generated from the GUI shows a default naming convention like "FreeRadius: {username}". This is controlled by the provider parameter in the JavaScript that generates the QR code.

If you want to customize the issuer name that appears in the Authenticator app, you can edit the file: /usr/local/pkg/freeradius.xml

Specifically, you should modify the provider parameter in the genOTPQR() JavaScript function as follows:

<script type="text/javascript">
    var qrcode = new QRCode(document.getElementById("qrcode"), {
            width : 200,
            height : 200,
    });
    function genOTPQR() {
            if ($('#varusersauthmethod').val() != "googleauth") {
                    return;
            }
            var provider = encodeURIComponent($('#description').val());
            if (provider.length == 0) {
>> ***         provider = encodeURIComponent("***CUSTOM PROVIDER***"); 
            }
            var user = encodeURIComponent($('#varusersusername').val());
            var key = encodeURIComponent($('#varusersmotpinitsecret').val());
            if ((user.length == 0) || (key.length == 0)) {
                    return;
            }
            qrcode.makeCode("otpauth://totp/" + provider + ":" + user + "?secret=" + key + "&issuer=" + provider);
            $("#qrcode").show();
    }
</script>

This change allows you to replace "FreeRadius" with any custom name you prefer in the Google Authenticator app.

johnpoz

I don't really understand this use case to be honest. If you want/need multifactor to auth to your vpn. How is a requiring username and password along with having the required cert not meet 2fa? If you want another put a password on your cert.

Doesn't the issued cert from the owner of the openpvn server meet the 2fa requirement?

I mean hey you do you - but I don't get it.

I mean you have 1 factor with something you know, ie your username and password. Having to have an issued cert along with this is something you have = 2fa.. If you also required a password on the cert you now are at 3fa.

NetCoreIT

@johnpoz
Hi, thanks for your input!

Actually, in this case we are talking about MFA (Multi-Factor Authentication), not just 2FA. By adding an additional layer of security to VPN authentication, like a dynamic OTP, even if someone steals the username and password or the certificate itself, they cannot generate the OTP on their own.

Many commercial solutions, such as Stormshield, Fortinet, and others, implement OTP as an additional security layer for remote VPN access. This approach effectively adds another layer of protection, making it much harder for an attacker to gain access, even if one factor is compromised.

Applying the Zero-Trust concept, the level of security is never “enough” and never 100% guaranteed. Every additional layer (like OTP) helps reduce risk and strengthens the overall security posture.

johnpoz

@NetCoreIT there is zero trust and then there is lets make this so freaking hard to use that the users won't ever use it ;)

But hey you do you. We require OTP to get into a specific vpn network, but you only have to auth every 60 days - not every freaking time.. And you can also have it generate a phone call to you to get the code, etc.

Like I said require a password on the cert and you are at min 3fa, if you don't even count the username/password/pin to login to the device that will be used to get to the vpn that has the cert on it.

So lets explore the factors;

Auth to get on the device with the vpn software, and info on where to connect.
Have username/password for the vpn
Have a specific signed cert, which to be honest shouldn't be on the laptop that has the vpn details
Now have a password on the cert.

Now require OTP, so yeah another device that has the software to generate this, which you prob have to auth to, and your authentication software should also require auth..

Get my point?? Your not launching the nukes.. You want a secure way for users to get work done - not making sure they are authed to launch the end of the world.

But hey you do you - maybe setup for them to submit blood sample or dna as well ;)

NetCoreIT

@johnpoz
I understand your point, and I get that it might seem like an unnecessary complication, but I don’t see why I should avoid enabling OTP on a corporate VPN connection just because you find it inconvenient.
Today, all MFA systems rely on OTPs in addition to username, password, and trusted devices.
Personally, I don’t find entering an OTP code inconvenient at all. In fact, considering that the average user usually checks “remember credentials,” I strongly believe OTP should be mandatory. Any preset password or static code can be compromised — OTPs cannot.
I firmly believe in this approach. If you disagree, that’s your personal opinion — valid or not, others will decide.

Codefighter

@NetCoreIT
I agree with NetCoreIT here.

True, we are not launching nukes, but remote workers can be responsible for millions of dollars and various accounting transfers. I would not want to walk into the owners office and tell them I didn't do everything I could to create a more secure environment.

While I do find entering the OTP inconvenient, I feel more comfortable using it than not.

Codefighter

@NetCoreIT

And, thanks for your post. I am a little hesitant to start altering the source code, only because I fear I might forget to review/repeat it after an update. But I will certainly review and consider your submission, thank you.

NetCoreIT

@Codefighter

Thanks @Codefighter, you’ve nailed it.
I totally agree that for home use, OTP can feel like overkill. But when it comes to small, medium, and large businesses, we’ve got a real responsibility to keep networks and systems secure. We can’t afford to be casual or underestimate the risks out there.
Honestly, I’d much rather hear a few grumbles from employees about typing in an OTP every time they hop on the VPN than have to sit in a meeting with the board explaining why we didn’t do enough to prevent and mitigate a cyberattack.