What's the best way to store a user password?
-
For the UT Nextcloud Music application, I'm looking to store the connection form data (url, user, password) to avoid having to retype them regularly.
I've managed to store this data in an sqlite database. Everything's working fine.
But I'm wondering about saving the password in clear text in a local database.
Is it secure?
Do I have to hash/salt it? Knowing that I have to do the reverse afterwards, which makes the method available to anyone?
Is it possible to use a system method? And if so, do you know a piece of QML code to store and retrieve this, please? -
@gwado You could encrypt it with username and salt it. You could use something like PGP for that. The best way would be to save it to a file with read only permissions and owned by root.
Does nextcloud support public-private key login? That would be ideal.For QML, there is the settings component which saves the variables in a file, but the content isn't readable with a simple cat (IIRC).
There is a lot more information in this Unix stackexchange thread.
-
dont you just get some token for login and store it, refresh it? i mean nextcloud desktop app is not asking me for password every run, and that is about all the stuff with oauth
-
@gwado There is a nextcloud plugin in the Online Accounts setting. Could you not integrate your app with that?
Here's some documentation to read up on about the Online Accounts[1]. It is still the old Canonical documentation, but I could not find the UBports mirror.
-
@arubislander the Nextcloud API does not allow you to retrieve Ampache/Subsonic identifiers from the Music application.
-
@gwado Ah, Nextcloud music provides a Subsonic API. I was not aware.
-
Storing passwords in plain text isn’t ideal, even locally. Since you need to retrieve it later, you could encrypt it using something like AES tied to the username or device info. Also, make sure the file has strict permissions.
-
@mchub
I use keepassxc and it works well.
I share the database between all my devices.
It's not working on Noble yet... -
Hi @Vlad-Nirky
OP wanted a secure way to store user's password for the app to use.
That's an issue with Ubuntu Touch as if a malicious actor can figure out the encryption method used and the key just by reading the sources.
A solution would require a way to encrypt the password and ensure that only the intended and unaltered app can access it.Non trivial.
-
@AppLee
Isn't it a problem for any operating system ?
I thougt that keepass provide API to access the password database. -
@AppLee Originally Online accounts could potentially be used for this. But I have never been able to figure out how to add a custom plugin for an app
-
@Vlad-Nirky said in What's the best way to store a user password?:
Isn't it a problem for any operating system ?
For proprietary OS, they can easily work around it by integrating a secret in the binary and only the authenticated user can make use of this secret to access sensitive data.
It's not the best, but it's pretty good.
Or they can rely on security cores to store all the user's secrets in it and grant access only to a trusted piece of code made by the developer of the OS then it's up to the OS to check the user's credentials before accessing the sensitive data.
This is widely used nowadays but do you trust the OS developer with your secrets? -
@AppLee another way for application developpers is by using the libsecret protocol to ask a user session service to store sensitive data. Gnome-keyring is such a service which creates by default a key store locked by the current user password.
IIIRC the KDE/plasma service is named kwallet.
Although, IIRC Ubuntu Touch lets user use phone without password/pin code. Maybe this is the reason such service is not provided to app developpers ?
-
@adorsaz said in What's the best way to store a user password?:
Although, IIRC Ubuntu Touch lets user use phone without password/pin code. Maybe this is the reason such service is not provided to app developpers ?
Ubuntu desktop also allows passwordless login. So that in itself is not the reason there is no implementation of libsecret on UT. The real reason is probably simply that none was implemented as yet.
