starred/psst

Fork 0

mirror of https://github.com/jpochyla/psst.git synced 2026-04-27 15:35:56 +03:00

[GH-ISSUE #32] Store user credentials in the system keychain #25

New issue

Closed

opened 2026-02-28 14:30:04 +03:00 by kerem · 6 comments

kerem commented

2026-02-28 14:30:04 +03:00

Owner

Originally created by @auravoid on GitHub (Feb 2, 2021).
Original GitHub issue: https://github.com/jpochyla/psst/issues/32

Saving the authentication credentials to the disk in a config file is great, but saving them raw is a bit insecure. It would be really helpful if the passwords get encrypted for user's privacy and safety.

Originally created by @auravoid on GitHub (Feb 2, 2021). Original GitHub issue: https://github.com/jpochyla/psst/issues/32 Saving the authentication credentials to the disk in a config file is great, but saving them raw is a bit insecure. It would be really helpful if the passwords get encrypted for user's privacy and safety.

kerem

2026-02-28 14:30:04 +03:00

closed this issue
added the
enhancement

help wanted
labels

kerem commented

2026-02-28 14:30:04 +03:00

Author

Owner

@jpochyla commented on GitHub (Feb 2, 2021):

I understand the sentiment, but we don't really have any key to encrypt with, and it's not really different from all the other stored passwords in other apps. One possible solution would be to use the platform capabilities for this, i.e. Keychain Access on Mac, through the keyring crate: https://crates.io/crates/keyring. PRs welcome!

@jpochyla commented on GitHub (Feb 2, 2021): I understand the sentiment, but we don't really have any key to encrypt with, and it's not really different from all the other stored passwords in other apps. One possible solution would be to use the platform capabilities for this, i.e. Keychain Access on Mac, through the keyring crate: https://crates.io/crates/keyring. PRs welcome!

kerem commented

2026-02-28 14:30:04 +03:00

Author

Owner

@SpyrosRoum commented on GitHub (Feb 6, 2021):

Hey, looking at the keyring crate, this looks easy enough so I'm gonna give it a try!

@SpyrosRoum commented on GitHub (Feb 6, 2021): Hey, looking at the keyring crate, this looks easy enough so I'm gonna give it a try!

kerem commented

2026-02-28 14:30:05 +03:00

Author

Owner

@SpyrosRoum commented on GitHub (Feb 6, 2021):

I have one question @jpochyla
How do you want to handle the transition from "Password stored in config file" to "Use keyring"?

I am thinking for the next release we make the password field in Config to only be de-serializable but not serializable so we can read it but not write it.
Additionally we will save it in the keyring if it's not already there and we will delete it from the file.
In the next release we will tell serde to completely skip the password and we can remove some code since we will now assume the the password is either in the keyring or nowhere.

This way we give a transactional period for user and we will only have issues if a user skips the next release.
Alternatively we can tell serde to skip the password and just force the user to tell us the password again so we can save it in the keyring.

Thoughts?

@SpyrosRoum commented on GitHub (Feb 6, 2021): I have one question @jpochyla How do you want to handle the transition from "Password stored in config file" to "Use keyring"? I am thinking for the next release we make the `password` field in `Config` to only be de-serializable but not serializable so we can read it but not write it. Additionally we will save it in the keyring if it's not already there and we will delete it from the file. In the next release we will tell serde to completely skip the password and we can remove some code since we will now assume the the password is either in the keyring or nowhere. This way we give a transactional period for user and we will only have issues if a user skips the next release. Alternatively we can tell serde to skip the `password` and just force the user to tell us the password again so we can save it in the keyring. Thoughts?

kerem commented

2026-02-28 14:30:05 +03:00

Author

Owner

@jpochyla commented on GitHub (Mar 10, 2021):

Thoughts?

I think the choice should be on the user's side, i.e. a checkbox in the credential dialog.
There's a chance that we can avoid storing the credentials at all, through authenticating with the "reusable credentials" that the Spotify session gives us, after the first login. I haven't investigated this much, though. It's possible there's some TTL involved.

@jpochyla commented on GitHub (Mar 10, 2021): > Thoughts? 1. I think the choice should be on the user's side, i.e. a checkbox in the credential dialog. 2. There's a chance that we can avoid storing the credentials at all, through authenticating with the "reusable credentials" that the Spotify session gives us, after the first login. I haven't investigated this much, though. It's possible there's some TTL involved.

kerem commented

2026-02-28 14:30:05 +03:00

Author

Owner

@BachoSeven commented on GitHub (Mar 10, 2021):

@jpochyla Perhaps we could take inspiration from the (recent) switch that ncspot has made, from storing plaintext(albeit base64-encoded) credentials to a librespot token (see github.com/hrkfdn/ncspot@d6db7a54d6).

Original ncspot issue for reference: https://github.com/hrkfdn/ncspot/issues/447

@BachoSeven commented on GitHub (Mar 10, 2021): @jpochyla Perhaps we could take inspiration from the (recent) switch that `ncspot` has made, from storing plaintext(albeit base64-encoded) credentials to a librespot token (see https://github.com/hrkfdn/ncspot/commit/d6db7a54d634e7d5015ee03daddb939d7c225668). Original ncspot issue for reference: https://github.com/hrkfdn/ncspot/issues/447

kerem commented

2026-02-28 14:30:05 +03:00

Author

Owner

@jpochyla commented on GitHub (Mar 13, 2021):

@BachoSeven Yup! master is now storing the token instead of user credentials. Unfortunately it means users need to re-authenticate.

@jpochyla commented on GitHub (Mar 13, 2021): @BachoSeven Yup! `master` is now storing the token instead of user credentials. Unfortunately it means users need to re-authenticate.

kerem referenced this issue

2026-02-28 14:32:54 +03:00

[PR #25] [CLOSED] [WIP] Random and Loop controls #407