# Single password entry signon-on

## msst

Currently I have to enter my password multiple times - thanks to a bug in kwallet even 3x bevore everything is unocked and logged in. But really, 1x should be enough. I wonder if anyone managed the following scenario already:

1. Fully encrypted system partition (LUKS.root)

2. User enters password and partition is unlocked by initramfs and system boots (that part works here).

3. Password is automatically passed on (pam comes into mind - but how?) to sddm login manager and the user logged in.

4. kwalletd is opened with the same passwd. pam_kwalletd5 should do that, but is still buggy here.

Basically one login, useable desktop unlocked appears. That is how it should be. But I am not aware that this is possible at all currently or did anyone find out how yet??

P.S.: The closest I can get is by using autologin for sddm and using no pw portected kwalletd. But thats not entirely how its intended I think.

----------

## gerdesj

Have you ever found yourself explaining to someone why it is a bad idea to have the same password on different websites?

To securely link your password from your boot prompt to your KDE session is a big ask.  In effect you asking for your disc encryption to be as secure as your DM login and probably your browser logins.  Whereas on Windows, int al, you might get a "yeah we'll reduce your disc encryption security to enable single sign on", your LUKS does not.

Either ditch LUKS because you can't be arsed with security or accept that greater security has a bit of a price.  Bear in mind that there is probably nothing wrong in deciding to have a simple password for the LUKS login that is generally known in your organisation.  LUKS is to ensure that if your systems are stolen then the data is is reasonably safe.  Risk Assessment.

----------

## msst

 *Quote:*   

> Have you ever found yourself explaining to someone why it is a bad idea to have the same password on different websites?

 

Yes, and it is a tough situation. There is likely not a single person using different passwards for each and every site. Unless you use a master password and all else is saved under this. Which is a matter of philosophy - you create also a single point of failure with it. In the end it comes all down to "pretty useable safety".

I think it would be a good compromise if luks, grub, whatever could pass on some at least "derived from boot password" auth token in a semi-volatile way to be reused for the boot-login process. Thats a bit the general problem with linux - it can do everything that windows and co. can do. Actually often better. But the usability and handling around it is here and there a bit sluggish.

Having to enter passwords multiple times or even multiple passwords to get a fully useable computer session booted up is simply such a thing - it may be conceptionally correct, but it sucks in terms of work-flow.

----------

## Hu

As regards master password - that is actually quite common now, and in my opinion it is better than reusing a password.  With the master password approach, you rely on adversaries not obtaining the master password (which you never write down) and the password vault (which is on your disk).  Contrast that with the reused password approach where you rely on adversaries not obtaining your password from one site because that password will work on four other sites.  You can mitigate the single-point-of-failure problem by keeping good backups of the vault.

If you trust the user who has the drive password to such an extent, why not make the other resources password-free?

----------

