!GzgmQVAObunAgMNkvU:matrix.org

FSUG-TVM Main (Free Software User Group, Thiruvananthapuram)

479 Members
Anyone can see what you discuss here | Website: https://tvm.fsug.in/ | Meetings History: https://git.fosscommunity.in/fsugtvm/meetings44 Servers

Load older messages


SenderMessageTime
30 Nov 2022
@sumanrajan435:matrix.orgrovonovo_zoroNice How locker address autostart apps needing passwords ? What db is in use ? 13:19:20
@gokuldas:matrix.orggoku12
In reply to @sumanrajan435:matrix.org
Nice

How locker address autostart apps needing passwords ?

What db is in use ?
I'm programming to use SQLite. The 'secret' will be stored in it after encryption with ChaCha20-Poly1305 algorithm. All other information will be unencrypted - this is allowed and recommended by the API spec.
13:21:23
@gokuldas:matrix.orggoku12

rovonovo_zoro:

How locker address autostart apps needing passwords ?

Locker obtains the password entered by the user a login (login terminal or display manager) using Pluggable Authentication Modules (PAM). This password is then used to decrypt the secrets. All this can happen immediately after login. The autostart applications will have to be started after confirming that locker is up. This is very easy to ensure if you are using systemd, s6, window managers, etc.

13:24:20
@gokuldas:matrix.orggoku12 *

rovonovo_zoro:

How locker address autostart apps needing passwords ?

Locker obtains the password entered by the user at login (login terminal or display manager) using Pluggable Authentication Modules (PAM). This password is then used to decrypt the secrets. All this can happen immediately after login. The autostart applications will have to be started after confirming that locker is up. This is very easy to ensure if you are using systemd, s6, window managers, etc.

13:24:51
@gokuldas:matrix.orggoku12 rovonovo_zoro: In case you are curious, we won't be storing the obtained password in the memory. Instead, the password is sent through a key derivation function (Argon2id) to obtain a key hash. The password is then erased from memory and only the key hash is retained. This key hash is what is actually used to decrypt the secrets later. 13:28:21
@gokuldas:matrix.orggoku12
In reply to @sumanrajan435:matrix.org
Nice

How locker address autostart apps needing passwords ?

What db is in use ?
* I'm programming to use SQLite. The 'secret' will be stored in it after encryption with ChaCha20-Poly1305 algorithm. All other information will be unencrypted/plaintext - this is allowed and recommended by the API spec.
13:28:55
@sumanrajan435:matrix.orgrovonovo_zoro
In reply to @gokuldas:matrix.org
rovonovo_zoro: In case you are curious, we won't be storing the obtained password in the memory. Instead, the password is sent through a key derivation function (Argon2id) to obtain a key hash. The password is then erased from memory and only the key hash is retained. This key hash is what is actually used to decrypt the secrets later.
Was going to ask that :-)
13:31:58
@gokuldas:matrix.orggoku12

rovonovo_zoro: There are still some bits to be sorted out. The leakage of the key hash is as bad as the leakage of the password as far the secrets db is concerned. However, this will at least ensure that the password is not compromised. The rest of the user account will be fine as long as the original password is protected (due to salting of password hashes).

Now, as far as the locker key hash is concerned, the OS kernel is supposed to ensure that locker's memory is not compromised. Despite all this, we need to find a way to make sure that the key hash is not written into the harddisk via the swap memory. This is still unresolved. Even then, this is a much better approach than storing the master password in a file.

13:37:52
@gokuldas:matrix.orggoku12 *

Hey Suman!
I will explain what it is first before going into why I'm creating it. Locker (as it is named now) is a user service/daemon that implements the freedesktop secret service API. Such a daemon is also called a 'secrets server'. It talks to its clients over DBus. Clients include applications like Element and Evolution. These client applications use the secrets server to store their secrets - for example mail passwords or web api keys. The secrets server stores these secret credentials securely on disk for the clients to access later.

Now about why I'm implementing this. There are only 4 secrets server implementations out there. And each one has its own problem. These are listed below:

1 & 2. Gnome's gnome-keyring and KDE's kwallet. Both these programs are heavy and they implement more than just the secret service. They also work as (unsatisfactory) gpg-agent and ssh-agent. This means that you can't run the real gpg-agent or ssh-agent if one of these is running. This is a problem for those who want to run the real agents - especially those who work on window managers like i3, sway, awesome, etc. This is why a standalone secrets server is necessary. In addition to this problem, both of them are heavily dependent on the DE libraries and pull a large number of dependencies while installing. Furthermore, it's extremely hard to disable gnome-keyring as long as it is installed on the system.

  1. KeePassXC. This is a GUI password manager that can also work as a secrets server. However, you need to unlock the password DB manually before the stored secrets are available through the DBus API. This is a problem for autostart applications like nextcloud-client and mail syncers. We really need a headless daemon that goes up before these applications are launched.
  2. Secret Service by yousefvand: It solves all the problems above, but creates a new one. It doesn't store the secrets securely. Any application can trivially access the master password file and unlock all secrets. This is an acknowledged problem. However, there seems to be no plans to address it. With Locker, I instead plan to access the user's account password through PAM and use it to encrypt and decrypt the secrets to a database.

Hope I'm clear enough. Let me know if you have more questions.

13:44:14
@kskarthik:poddery.comKarthik joined the room.14:50:16
@gokuldas:matrix.orggoku12 *

rovonovo_zoro: There are still some bits to be sorted out. The leakage of the key hash is as bad as the leakage of the password as far the secrets db is concerned. However, this will at least ensure that the password is not compromised. The rest of the user account will be fine as long as the original password is protected (due to salting of password hashes).

Now, as far as the locker key hash is concerned, the OS kernel is supposed to ensure that locker's memory is not compromised. Despite all this, we need to find a way to make sure that the key hash is not written into the harddisk via the swap memory. This is still unresolved. Even so, this is a much better approach than storing the master password in a file.

18:51:42
2 Dec 2022
@gokuldas:matrix.orggoku12https://unifiedpush.org/03:12:52
3 Dec 2022
@gauthamkrishna9991:matrix.orggauthamkrishna9991 set a profile picture.13:57:30
@gauthamkrishna9991:matrix.orggauthamkrishna9991 removed their profile picture.13:57:38
@iwastux:matrix.org@iwastux:matrix.org joined the room.19:26:20
@iwastux:matrix.org@iwastux:matrix.org left the room.19:26:20
4 Dec 2022
@aliz97:matrix.org@aliz97:matrix.org joined the room.19:55:04
@aliz97:matrix.org@aliz97:matrix.orgRedacted or Malformed Event19:56:10
5 Dec 2022
@aliz97:matrix.org@aliz97:matrix.org left the room.01:55:34
@mdhav:matrix.orgMadhav@admin02:12:13
@athulvis1:matrix.orgAthul banned @aliz97:matrix.org@aliz97:matrix.org.02:16:52
@athulvis1:matrix.orgAthul @goku12 you have shared a set of tools to sync up contacts and messages from phone to some server. Is it possible to share it again? 02:18:53
@mdhav:matrix.orgMadhavOnly webdav comes to mind03:13:02
@gokuldas:matrix.orggoku12
In reply to @athulvis1:matrix.org
@goku12 you have shared a set of tools to sync up contacts and messages from phone to some server. Is it possible to share it again?
I use nextcloud for contacts and calendar. Syncing on mobile is using DAVx5. Syncing on laptop is using vdirsyncer. Viewing them is using khal, khard and todoman.
07:16:22
@mdhav:matrix.orgMadhavAny provider or do you host yourself?07:22:32
@gokuldas:matrix.orggoku12
In reply to @mdhav:matrix.org
Any provider or do you host yourself?
My own. Actually part of mail-in-a-box
07:31:48
@famubu:matrix.orgfamubuWas windowshopping some sites selling/renting domain names. Saw some places offering big discout if we buy it for 10 years at once. Do you guys know what the risks associated with that option could be?09:22:03
@gokuldas:matrix.orggoku12
In reply to @famubu:matrix.org
Was windowshopping some sites selling/renting domain names. Saw some places offering big discout if we buy it for 10 years at once. Do you guys know what the risks associated with that option could be?
10 years is the maximum any domain can be registered for in a go
09:53:51
@kskarthik:poddery.comKarthik
In reply to @gokuldas:matrix.org
10 years is the maximum any domain can be registered for in a go
Domain companies advertise as buying domain, But in reality we rent the domain. Careful use of words in business 😉
12:52:51
@gedizz:matrix.orgMichael Wolf joined the room.20:24:15

There are no newer messages yet.


Back to Room List