Hodor: Custom credential provider API for Windows 10

Hodor addresses a specific, rigid pain point for Windows developers: the difficulty of implementing custom authentication triggers. By acting as a bridge between a Windows named pipe and the Local Security Authority (LSA), it allows developers to treat the Windows lock screen as a programmable target. Instead of fighting with the restrictive Windows Hello ecosystem, a developer can simply send a formatted string—containing credentials—to a pipe, and Hodor handles the hand-off to LogonUI.exe. Technically, the implementation is straightforward but effective. The use of a DLL running within the privileged context of LogonUI.exe is the only viable way to achieve this without triggering security warnings or requiring extreme kernel-level hacks. The developer has included critical safety measures, such as using FILE_FLAG_FIRST_PIPE_INSTANCE to prevent pipe squatting and SecureZeroMemory to clear passwords from RAM, showing a commendable understanding of the security implications of handling plaintext credentials in memory. However, the product introduces a significant architectural trade-off: security is shifted entirely to the application writing to the pipe. If a third-party app handles the 'Face Match' or 'NFC Read' and then sends a password in plaintext across the pipe, that app becomes the new primary attack vector. While the pipe DACLs restrict access to authenticated users and administrators, the reliance on a 'username:password' string format is inherently risky compared to the cryptographic assertions used by native Windows Hello. This is a powerful tool for system architects building kiosks, custom biometric integrations, or proximity-based unlock systems. It is less of a 'security product' and more of a 'connectivity shim' that grants developers the freedom to define their own authentication logic outside the Microsoft sandbox.