Login security - phishing resistant MFA
-
@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.
