|
|
|
|
|
|
by zanny
4025 days ago
|
|
|
The UX of kwallet is awful, and everyone I put on KDE I always use a blank wallet password so they are not badgered by "enter password to unlock wallet" prompts. Yes, its insecure to have the user session act as an unlock on a cryptographic store like that. It looks like lxqt_wallet is even worse on that front in terms of UX - yes, its more secure for every program to have its own secret stores and require prompts to unlock them, but average desktop users just want to login and have that unlock their secret stores, pretty much like Gnome does it. What you really want is MAC on secrets. Applications that add to the secrets database get implicit access to those secrets in the future, but first access should require user permission before an application can start accessing your credentials for other accounts. You don't really need anyone to reinput a password, just prompt users "Kfoo wants to access your account neckbeard@gmail.com, allow?" with allow / deny choices, or make it an option in the wallet GUI. You could probably even integrate it into current MAC solutions. Make it a VFS somewhere in var, and have your distro ship sane defaults like letting the sanctioned im client (both are based off telepathy nowadays) access the secrets store on a whitelist of domains, like @gmail, @chat.facebook.com, etc. |
|
|
lxqt_wallet supports 3 backends: kwallet,libsecret and internal one that gives the behavior i explained above.
Each backend has its pro and cons and the project lets the user pick which one works best for them.
There need to be a general purpose secure storage system that can accommodate users who wish to not have their secrets that are meant to be used by only one application be exposed to all other applications.