Unlock LUKS with login/password

[paratrap]

Hello!

I have an idea about how modern linux works with encrypted LUKS partitions.

Right now on system encrypted with LUKS first prompt you see is a grub passphrase to unlock the device and after OS boot you see second prompt for login/password. This looks redundant.

What if we can by pass second prompt and allow grub to handle login/password prompt? It can be done with few steps:

1) grub can ask for login/password, then MD5 the text and unlock LUKS device using this MD5 passphrase. md5(login+password) or plain(login+password)

2) grub passing the login/password to the kernel.

3) Kernel boots and passing (or password manager service, like systemd) read that data from kernel (/proc/cmdline) and rewrites it (hide from cmdline).

4) password manager (systemd service) makes auto login with provided data

5) if user updates the password, then password manager updates LUKS corresponding slot with md5(login+password) or plain(login+password)

Since LUKS1 support for 8 keys, we can support only 8 logins which can open and automatically login. Password manager has to associate every user (UID) with LUKS device UUID and slot number for simply key updates. Or even using one SLOT0 but different technique for encrypting keys (the only limitation here we can't change slot0 passphrase, since it would require to update all user passwords). Also possible to use LUKS masterkey and keep all users logins (LUKS masterkey encypted with login/password) at ESP partition or stage2 image for grub to check.

This is major changes to the linux password management. Can it be improved and proposed as standard?

[itmicp]

Hi

I don't know what desktop environment and display manager you are using,
but you can probably just enable autologin.

For example, with lightdm : wiki.debian.org -> lightdm : Enable autologin

[p.H]

Right now on system encrypted with LUKS first prompt you see is a grub passphrase to unlock the device

In a default Debian installation, the passphrase is prompted by the initramfs, not GRUB.

[lindi]

Are you thinking about single-user systems here? Autologin is probably one option here but note that it cannot unlock your keyring so you will anyway need to enter the password to use that at some point. If you have multiple users and you need to isolate them from each other you need to ensure that they cannot get root access. One way to accomplish this is to use the TPM to hold the LUKS secrets.

[paratrap]

1) I'm not talking about autologin feature. I'm talking about unlocking HDD using login / password

2) I'm using ESP + SINGLE LUKS partition scheme. first grub asks for passphrase, then initrd reads passphrase from /boot/luks-key file and auto unlock the partition. Them gdm asks for login/password

3) autologin CAN unlock since the idea I'm proposing passing login and password to the session manager which can unlock keyring.

Guys this is a idea / proposal about unlocking LUKS using login / password instead passphrase.

[lindi]

Ok so mostly about speeding up login? Do you want to support multiple users that cannot access files of each other or is a single user enough?

[paratrap]

Mostly about having one login/password pair to unlock a device, not having two passphrase + login/password. This is about single LUKS partition (ESP+LUKS(boot,home) with multiply users.

[lindi]

How can you use LUKS with multiple users? Any user could just boot a livecd and look at the files of other users since they can open the LUKS container?

[paratrap]

With people who trust each other. Multiuser accounts only for separation of personal data, browser history, etc, not for security