When I open my backuped file
/home/defaultuser/.config/signond/signon-secrets.db
with sqlitebrowser on my PC, I can see my mail addresses + passwords.
Did I do something wrong?
You too?
1 Like
When trying to download as defaultuser, I get permission denied (scp).
devel-su, cp/chmod later:
sqlite> .schema
CREATE TABLE CREDENTIALS(id INTEGER NOT NULL UNIQUE,username TEXT,password TEXT,PRIMARY KEY (id));
CREATE TABLE STORE(identity_id INTEGER,method_id INTEGER,key TEXT,value BLOB,PRIMARY KEY (identity_id, method_id, key));
CREATE TRIGGER tg_delete_credentials BEFORE DELETE ON CREDENTIALS FOR EACH ROW BEGIN DELETE FROM STORE WHERE STORE.identity_id = OLD.id; END;
sqlite>
sqlite> select * from CREDENTIALS;
ouch. not hashed.
I’m not sure if the mitigation with group privilig(ed) helps, but the passwords should be hashed. They are not.
This should be a bug report.
These are credentials needed for logging in to services, so they can’t be hashed unfortunately. They could be obfuscated, but ultimately there has to be some way for the device to be able to access the plain text credentials in order for it to use them.
6 Likes
It could be stored in encrypted way where the encryption key is the pincode for the device, then on the first device unlock it’s decrypted and hold in the memory in the unencrypted form. I know it’s not perfect but way harder to obtain it than from single file.
1 Like
How does the browser manage stored passwords?
actually regarding my hint in this message:
any news regarding it? Of course some better solution would be great.
That’s still just obfuscation and anyone with root access will have access to it just like to the disk
can’t when then just use:
https://man7.org/linux/man-pages/man7/keyrings.7.html
for this? If I understand it properly, there’s this property “posession” which looks just how we’d like to have it.
The simple rule would be:
- on boot up, decrypt user mail password using pin code,
- start up mail daemon, and load up the password into keyring and set proper permissions so only mail thread can access that password
Potential problems:
- when mail deamon crashes, user needs to type pin code again to decrypt password, as password is not stored in memory.
@flypig what you think about this?
Tbh this could be used also for other services for example accounts but it would require always to have a daemon that will startup when the phone starts to automatically load up password, or if done later, a user prompt will be required to unlock the secure storage each time app is started.
Well probably someone that’s more into security will for sure make it even better, but this is something that came out to my mind, maybe it’s worth rethinking?
1 Like
It’s always worth thinking about security, and I agree it’s also always worth seeing if things can be improved. This here is just my personal opinion (as it’s an interesting topic for sure).
The current situation (as I understand it) is that the password is protected in three ways:
- With disk encryption. This protects the secret when the operating system isn’t running (data at rest).
- With privileged file access. This protects the secret when the operating system is running (data in use).
- With something like TLS when it’s used to log in across the network (data in transit).
In theory the first requires your device lock code to gain access. The second requires your developer password to gain access. The caveat being that there may be exploits to get around these (this is always the case, independent of the platform or approach).
In theory I think this gives similar protection to what you’re describing @lolek (PIN + permissions).
There may be a good argument that daemon permissions would be more secure (smaller more controllable attack surface, more fine-grained permissions) compared to file permissions. A daemon in the way you describe would also work nicely for Sailjail, and you could probably achieve something similar using Sailfish Secrets, so the mechanisms are probably mostly there already.
However, I’d add that it would also be better to use something like OAuth2 instead of needing passwords at all. In this case the secrets are still available on the device, but they are app and scope-specific and can be revoked at the service end without affecting other access.
Like I say, this is just my personal thoughts here.
2 Likes
I don’t get it how OAuth2 can help with mail password for the builtin client?
There current situation also doesn’t protect from stealing password by malicious app that has escalated privileges. And I understand that many users here would like to have protection from this kind of problems. It’s of course not a problem to have protection from additional app but for something that’s built into the system, well I can’t just replace the built in mail client, can I?
Just to clarify: when I suggested to use OAuth2, this wasn’t aimed at end users, but rather at app developers (including for the build in apps) and service providers.
My (honest) question would be: how does your suggested approach change this? If I’m understand right, the difference is about the point at which the user has to enter their PIN or password to gain access?
I’m not trying to be obtuse or dismissive, so I apologise if my comment came across that way: if there’s an improvement to be made, it’s good to be clear about it.
1 Like
It’s a bit different.
With current approach, it’s as “easy” as to get root access and voila you have access to all data. So it’s enough to just run some app with elevated privileges which will have access to everything.
While with kernel keyring there’s no option to do this as from what I understand it can be restricted per process. So different process won’t have access to that data even if it’s a process running from a “root” account.