Bug #12786
closed
MFA auth allows reveal of other admins PIN and INIT-SECRET
Added by Aaron Shaffer over 2 years ago.
Updated over 2 years ago.
Description
I have MFA working in pfSense with Google Authenticator but I just noticed what I consider to me a major security flaw: any admin can reveal any other admin's PIN and INIT-SECRET.
This allows for any admin to easily impersonate any other admin. This means that it is not possible to be 100% sure that activity undertaken by any given admin was actually done by that admin. This makes pfSense non-complaint with basic security requirements for NIST/CMMC and probably many other security frameworks with similar requirements to tie activity to a specific individual.
I suspect this was maybe just overlooked? A quick fix would be to simply make it impossible to reveal another admin's PIN or Init-Secret or both.
Thank you for your help!
Aaron
- Status changed from New to Not a Bug
- Priority changed from High to Normal
Password field content is already hidden from the GUI when the fields are defined as a password type, but if the admin can take any action that can read config.xml (e.g. make a backup, run a shell command, etc) they can read the items that way.
If you don't trust someone to see that, don't allow them access to the pages that can display it.
The PINs can't be stored as hashed because they are required in order to validate the authentication.
https://docs.netgate.com/pfsense/en/latest/backup/password-security.html
If you don't want anyone to be able to access that then you can move the RADIUS part off to a different secure server.
I think you're missing the point. I am not concerned with config.xml nor with password fields, nor did I mention them.
I'm talking about simply clicking a button in the pfSense interface which should never exist in the first place named "Show OTP Secret". It should never be that easy. An admin should be able to reset the OTP secret, but never view it after it has been set.
A button like that should never exist in any admin interface anywhere, on any website, or on any operating system for any OTP secret. OTP secrets are intended to be secrets, and if they can be revealed they do not serve their intended function of tying a specific logon to a specific individual.
Security by obscurity is not security. See my previous link.
Security by obscurity is not security. I totally agree with you and I read the link before replying to you.
What does weaken security is making it SUPER F'N OBVIOUS and as easy as humanly possible to find what someone's secret key is with a big "Show OTP Secret" button. It doesn't make sense for it to be there. Why should that button ever exist in the first place? It stands out as a glaringly poor design decision. I have never seen anything like it anywhere in any OTP system I have set up on any operating system or website anywhere. It's totally bonkers and should be removed.
- Project changed from pfSense to pfSense Packages
- Category changed from Authentication to FreeRADIUS
- Release Notes deleted (
Default)
It's there because for most use cases of the package users cannot login to the GUI to set their own MFA information. Admins have to set it for them and give them the details, QR code, etc. This is not a self-service interface, so it's already less secure by its nature. The way the package system pages work there isn't a way to present it just once and then never show it again, plus it's still stored in the clear in the backend. Per the previous link I shared, we don't like schemes that only superficially hide that kind of thing. It makes using it more of a headache for most admins.
Even if it was hidden any admin could reset the MFA code of another admin and then impersonate them that way. There isn't any fine-grained control in the package that prevents one admin from seeing or doing anything with another account. It isn't intended for that kind of role.
If the design is not something you like, use something different. There are plenty of other standalone RADIUS services out there.
I guess we'll just have to agree to disagree. I don't think it should be there and I don't think there is a way to convince me otherwise. It seems totally unreasonable to me.
RE: "Even if it was hidden any admin could reset the MFA code of another admin and then impersonate them that way."
This true only until the compromised admin tried to sign in the next day and realized that their OTP no longer works and had likely been compromised. At least then the admin would know something mischievous is happening with their account instead of the impersonating activity continuing for months on end with zero awareness and a false sense of security that they are protected by robust 2-factor.
Also available in: Atom
PDF
Updated by 
Updated by