Hello.
Is there support in freeipa for howdy ? https://github.com/boltgolt/howdy
rpms are already available here: https://copr.fedorainfracloud.org/coprs/principis/howdy/
Would be nice if this would integrate with freeipa.
Rob
Rob Verduijn via FreeIPA-users wrote:
Hello.
Is there support in freeipa for howdy ? https://github.com/boltgolt/howdy
rpms are already available here: https://copr.fedorainfracloud.org/coprs/principis/howdy/
Would be nice if this would integrate with freeipa.
I wouldn't get your hopes up. Even the authors suggest that it isn't particularly secure, which is the IPA raison d'être.
If someone submitted fully working code and the howdy packages were available outside of copr, then maybe. As an optional method, disabled by default.
I didn't dig into how howdy stores its authentication information but it potentially brings with it privacy issues that we haven't had to deal with before.
rob
On ma, 10 tammi 2022, Rob Crittenden via FreeIPA-users wrote:
Rob Verduijn via FreeIPA-users wrote:
Hello.
Is there support in freeipa for howdy ? https://github.com/boltgolt/howdy
rpms are already available here: https://copr.fedorainfracloud.org/coprs/principis/howdy/
Would be nice if this would integrate with freeipa.
I wouldn't get your hopes up. Even the authors suggest that it isn't particularly secure, which is the IPA raison d'être.
If someone submitted fully working code and the howdy packages were available outside of copr, then maybe. As an optional method, disabled by default.
I didn't dig into how howdy stores its authentication information but it potentially brings with it privacy issues that we haven't had to deal with before.
Right. As of now, howdy is more of a local-only tool tied to a configuration and data available locally.
The way howdy is integrated into a system for authentication is by providing a barebone PAM module which during authentication step runs a Python script ('compare.py'). This script initializes camera and captures frames to see if there is a particular human pose is present at a frame and if a face there is one of the trained for in the local database. Since PAM module stack during login runs as root, this process would substantially increase an attack surface to cover all Python code involved. There is plenty of code here that most likely was not analyzed for security aspects.
Can this be turned into something that could be tied to a global (in FreeIPA sense) identity? User-specific trained faces' database is probably a privacy target as it could be (ab)used for detecting a person in a photo or video frame out of the contex of deploying howdy for login purpose. As such, I would not make it part of a user data in LDAP.
This makes centralized storage of this data questionable. Ok, if user has the information in their home directory, perhaps howdy could be used to consume that locally. This would be no different to authenticating a user with pam_unix.so, after all.
Converting the fact that a user was authenticated with howdy to something that would look as a centrally-issued mandate (Kerberos ticket) is a harder task. Sure, we authenticated locally akin to pam_unix.so, but this is not something that we can claim to a KDC in a request of TGT. Could pam_howdy.so be used to unlock access to a vault with, say, a PKINIT certificate for the user so that we would use this fact for acquring a Kerberos TGT? May be. It would certainly be a stretch of security trust here since there is literally nothing in howdy cryptography-wise to allow a leap of mathematically strong operation between face / pose recognition and a vault opening.
In Windows world how Windows Hello works in a domain environment is by tying the local authentication process into some known to a domain controller identity -- machine account of the system you are trying to login to. That identity is known and mutually authenticated to a domain controller and can ask for a ticket to itself on behalf of a user which was externally validated. The 'leap of trust' is a bit complex, with hardware requirement of TPM on the client, a lot of communication with a DC like in this diagram, and additional communication to the cloud AP to finally tie the domain identity to Azure AD identity: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-...
All this is done to allow different Windows Hello logon types, not just face recognition, to inherit domain-derived user properties for the particular logon. Howdy doesn't have any secure binding of the data used for authentication to a user account, and we cannot easily get a leap from 'user data exists in this home directory' to 'issue Kerberos ticket to this identity' without additional steps KDC could trust.
freeipa-users@lists.fedorahosted.org