Password stored in plaintext #56
Comments
|
Yes, ideally we should do something better than that. A quick search suggests the Python keyring module could be a good option. |
|
From my initial testing, relying on the keyring module will make the CLI quite a bit harder to install on Linux. I think for now what I'll do is make it detect the module if it's installed, and if not it can prompt for the username/password each time rather than storing it in the config. |
|
I'm not sure about the details of how OAuth works, but would it be easier to instead issue and store a token that is set to expire after a longer period than the 60 minute bearer token? The effect would be the same that a user would remain logged in on their machine, but without risking their passwords. Furthermore a token could be revoked if it's compromised. We also wouldn't have to mess around with local dependencies relating to what keyring software is installed on a machine. |
|
That would be ideal, yeah. I did originally try that when I started working on the Python client module but there was a reason it wouldn't work with the Panoptes API -- but I can't actually remember what was stopping that because it's been a couple of years, so it might be worth trying again.
|
Running
panoptes configurestores the data that is entered in plain text on the host system. This means that if the user enters their username and password as prompted, their username and password are stored without encryption under$HOME/.panoptes/config.yml.Once the cli has been configured with a username and password, running
panoptes configureagain prints this info in plaintext as the default value.The text was updated successfully, but these errors were encountered: