Login security - phishing resistant MFA
-
@jeffsmith82 said in Login security - phishing resistant MFA:
In the real world though these things happen and then what you do you look at the root cause and make sure it doesn't happen again. So training for the user and roll out phishing resistant authentication is what we are doaing. So im here asking for fishing resistant auth for something thats important in our infrastructure.
I get what your saying. Whatever security tools you used, failed you. So thats problem 1.
You have not set up 2FA on the firewall which you can do with the link i provided.I only take issue with your below statement.
@jeffsmith82 said in Login security - phishing resistant MFA:
It doesn't look good that such an important security appliance to most doesn't have the most basic security measures that are required these days.
This just objectively isnt true. By all measures, pfSense is very secure. Having additional security checks that you want are fine but do not take away from what the product - pfsense - already has at its core which is security.
-
I don't think anyone really disagrees that it would be good to have some form of native MFA in pfSense.
-
@jeffsmith82 said in Login security - phishing resistant MFA:
It doesn't look good that such an important security appliance to most doesn't have the most basic security measures that are required these days.
This just objectively isnt true. By all measures, pfSense is very secure. Having additional security checks that you want are fine but do not take away from what the product - pfsense - already has at its core which is security.
So 2FA isn't built in to the core product which is by all measures these days it's not secure. Try and get cyber insurance if you don't say you use 2FA and see what you get quoted compared to if you do have it as proof of this.
https://redmine.pfsense.org/issues/4242 here is an 8 year old issue raised asking for 2FA for the admin login that is still open and not confident this is going to happen any time soon but worth asking right.
Implementing SAML so pfsense doesn't have to deal with authentication and push it off to a third party service like Azure would be a great option too. Someone made a project that implements everything that's required as far as I can see https://github.com/jaredhendrickson13/pfsense-saml2-auth This should have been made part of the core product. https://redmine.pfsense.org/issues/11920 2 year old issue here pointing this out.
I have used pfsense since about 2008 and I do really like it but it's okay to admit it has faults and not having decent 2FA is a big one. Not having a decent 2FA option for any of the out of the box VPN's is number 2 on my list of issues. https://www.netgate.com/blog/freeradius-on-pfsense-for-2fa having to manully recreate a user list and somehow hand out the QR codes to register users isn't exactly easy.
-
@stephenw10 said in Login security - phishing resistant MFA:
I don't think anyone really disagrees that it would be good to have some form of native MFA in pfSense.
100%
-
@jeffsmith82 No argument from me that there should be some level of modernization in the base code.
I would welcome SAML support wholeheartedly. -
@stephenw10 said in Login security - phishing resistant MFA:
I don't think anyone really disagrees that it would be good to have some form of native MFA in pfSense.
Someone has already done the hard work and written a package for it https://github.com/jaredhendrickson13/pfsense-saml2-auth would be great to see this either become a supported one by netgate or just migrate it into the core.
-
There's an open feature request for that too: https://redmine.pfsense.org/issues/11920
Comments welcome. That was discussed internally though and there were some issues with it making it non-trivial.
Steve
-
@stephenw10 Would be interested to know what the non-trivial issues are.
-
I wasn't involved directly, might be better to ask about that on the ticket. Unless one of the developers chimes in here....
-
@jeffsmith82 said in Login security - phishing resistant MFA:
not sure why your attacking me
How is this attacking you? How does "Sorry to learn of this despite the careless picture it paints..." turned to attacking you? How did you interpret it as an attack on you? Did I said YOU ARE CARELESS...no. Does the hacking appears to paint careless imagery...it sure does...doesn't it?
-
@jeffsmith82 After extensive research, the passkey actually appears best suited for a firewall, whether one is surfing or working the web...maybe as a package or if pfSense continues its plan to add API for WebAuthn and to store the public keys, rather than say icloud keychain or Google or Microsoft. Thank you for bring it up.
-
I decided to take on implementing this feature as a personal project because I want it on my Netgate 6100.
The request has a working pull request against RELENG_2_7_2 - https://redmine.pfsense.org/issues/15244I hope it gets approved for everyone to use as it's very convenient :)
-
Looks promising.
-
@TheUniquePaulSmith Since you have incorporated WebAuthn, it should be now possible for it to store all private key on the firewall, isn't it? Thank you for your hard work and commitment.
-
@NollipfSense said in Login security - phishing resistant MFA:
@TheUniquePaulSmith Since you have incorporated WebAuthn, it should be now possible for it to store all private key on the firewall, isn't it? Thank you for your hard work and commitment.
No, only the public keys are stored on the pfsense system, which while ideally should be kept confidential, has little to no implication of being exposed publicly (hence public key).
The private key is kept and stored on the authenticator (Windows Hello\Android\iOS) typically via hardware backed TPM and usually not accessible or exportable by the user.Most authenticators (and through part of the defined standard) are enforcement of user attestation that requires a factor of authentication to be used before transacting with the private key on the authenticator (such as biometrics/pin).
This helps prevent lost or stolen authenticators being used by malicious actors. A lot of the authenticators also employ techniques like anti-hammering to prevent hardware-based attacks like PIN brute forcing.Authenticators meet the requirements of multifactor authentication.
They are "something you have" such as hardware backed TPM device which would be difficult to "clone"
Then "unlocked" via "something you are" usually via biometrics (FaceID, Fingerprint, even palm vein readings!
)
Or by something you know such as a convivence PIN (whereby a 4-digit PIN with FIDO is more secure than say a 20-character generated static password)Which then performs an authentication against the site (pfsense webui) similar to mutual-TLS.
This authentication method also defeats common phishing attacks, since the registration is tied to the "website FQDN" making authentication to phishing sites almost pointless & useless.
More Info:
https://fidoalliance.org/how-fido-works/
https://www.microsoft.com/en-us/security/business/security-101/what-is-fido2
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/faq#why-a-pin-is-better-than-an-online-password -
@TheUniquePaulSmith said in Login security - phishing resistant MFA:
No, only the public keys are stored on the pfsense system,
Actually, that's what I meant, the public key...sweet!!!
-
@TheUniquePaulSmith that looks amazing many thanks for pushing this forward.
Was wondering how you deal with having multiple servers in a HA cluster, From what I understand you can set multiple "Relying party" entries so in theory you could allow multiple addreses to use the same key and get the public key replicated for the users.
-
@jeffsmith82, that's a great question and needs to be something that is tested. I haven't gotten a chance to test pfsense in HA-cluster.
Depends on how the HA-cluster works, if it's multiple servers behind one shared front-end FQDN (like load balancers) then it should be fine. If it's different FQDN web portals that replicate the config, then you would need to register on each different FQDN web portal as the authenticator is directly tied to the "site". This is all under the assumption that the config gets replicated to each server in HA-cluster.
The address needs to be a FQDN, not an IP address. Accessing via IP addresses will not permit WebAuthN in most browsers, I believe that is part of the defined standard.
-
@TheUniquePaulSmith So my current setup has 2 server like this.
fire01.internal.companyname.com
fire02.internal.companyname.comFrom what I understand you can list multiple sites against the same key at creation time though I might be wrong. That would be the best approach if it's possible. Then you can just do this on the primary server with an option of adding extra sites on creation and it will replicate the public key to all the servers and should allow login.
If this is not possible then probably need a way to allow creation of multiple keys on the master with a custom site. If you create on the secondary it will get overwritten by when the config syncs from the primary to secondary i would assume.
-
@jeffsmith82 said in Login security - phishing resistant MFA:
....
From what I understand you can list multiple sites against the same key at creation time though I might be wrong.I don't believe the standard allows you to do this. Each passkey\registration is tied to a relying party which would be the current site you are accessing. You need to directly access the other servers (over HTTPS) to create registrations unique to them. If for example you access https://fire01... then the passkeys are scoped only to that FQDN and won't be presented when attempting to login to https://fire02... You would need to register a key for each server, or a common front-end that they all share.
If you create on the secondary it will get overwritten by when the config syncs from the primary to secondary i would assume.
It should not, my pending implementation allows you to register multiple times for the same user, which in theory should allow for other sites to be used.
The only potential challenge I see is that my implementation verifies the FQDN for registration based off the configuration files (system/hostname + system/domain) . So i'm not sure how your HA deployment deals with that on the config side for both servers. Something that would need to be tested.
