Hello everybody, with a bit of tinkering, I was able to get the multi-factor authentication running. Of course, being a OS level program, the OS is taking care of multi-factor authentication. It would be interesting if the security measure can be done on the hardware-based firmware/interface, disk encryption, and disk-based GNU Grub bootloader level. Of course, I might be asking for too much since access to files is required after an unforeseen unloggable error occurs. Close call scenario! Some crashable programs need to be researched and reconsidered before use. I’m looking at (more like pointing fingers and accusing) Simple Screen Recorder! Although, I should have at least remove the program while it looked like it was bugging out.
Anyways, things are moving along, more or less.
The only remaining afterthought is a question left.
I see multiple pages regarding multi-factor authentication. Some of them mentioned two authentication mechanism modes. Those modes are either ‘client’ or ‘challenge-response’ value. According to these pages, the client mode value sends a client request to the multi-factor authentication server(s) for verification and requires pressing the key of the multi-factor authentication device; Internet connection is required for client mode. The challenge-response mode value sends a user request to the multi-factor authenticated operating system for verification and does not allow pressing the key of the multi-factor authentication device; Internet connection is not for challenge-response mode. Given the facts, the client mode value would appear to be the most secure option. I would usually opt for the client mode value, but I also consider situations without Internet connectivity.
|
This forum topic did not mention the multi-factor authentication mechanism modes, but the pages that I scoured through imply that the client mode value is the default multi-factor authentication mechanism mode value. Challenge-response mode value requires manual configuration. Can you confirm this assumption?
Here are the reference material.
https://adl1995.github.io/passwordless-logins-with-yubikey.html
https://www.redhat.com/sysadmin/mfa-linux
–
A bit off-topic. A encrypted disk is still at risk from UEFI’s automated external device boot execution acting as OS installers or live OS environments/operations. With live OS environments/operations, one can access the encrypted disk after bypassing disk-based security measures. I would rather prevent such devices to interfere with the hardware-based firmware/interface in the first place. I recommend to apply at least a firmware-based administration passphrase prompt along with setting the UEFI boot sequence to Legacy boot option with all external device check flags unchecked, leaving the internal disk drive check flag checked. If you only have Legacy boot sequence, just uncheck all device check flags. The next computer boot with set the automatic boot sequence to an invalid legacy device error message. The situation would now require manual boot sequence with the unchecked devices, initiating the firmware-based administration passphrase prompt. Until then, we be waiting for the study/possibility of multi-factor authentication for hardware-based firmware/interface, disk encryption, and disk-based GNU Grub bootloader level.
I hope I don’t overwhelm readers with such overflow. Keeping on track is key to security’s progress.
Here is the reference material for UEFI-induced vulnerability.
https://www.gnu.org/proprietary/proprietary-insecurity.html#uefi-rootkit