Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable simple symmetric encryption for password storage on user configuration file #60

Open
sbrunato opened this issue Oct 16, 2018 · 4 comments · May be fixed by #370
Open

Enable simple symmetric encryption for password storage on user configuration file #60

sbrunato opened this issue Oct 16, 2018 · 4 comments · May be fixed by #370
Assignees
Labels
enhancement New feature or request

Comments

@sbrunato
Copy link
Collaborator

Original report by Oyono (Bitbucket: aoyono, GitHub: aoyono).


The way user configuration is done now requires the user to provide its password in clear text in the configuration file. This issue aims at solving this problem by providing a way to crypt this password

@sbrunato
Copy link
Collaborator Author

Original changes by Oyono (Bitbucket: aoyono, GitHub: aoyono).


set milestone to "0.8.0"

@sbrunato
Copy link
Collaborator Author

Original changes by Oyono (Bitbucket: aoyono, GitHub: aoyono).


changed milestone from "0.8.0" to "1.0"

@sbrunato sbrunato added minor enhancement New feature or request labels Jun 18, 2020
@sbrunato sbrunato added this to the 1.0 milestone Jun 18, 2020
@sbrunato sbrunato removed this from the 1.0 milestone Dec 17, 2020
@CGuichard CGuichard changed the title Enable simple symetric encryption for password storage on user configuration file Enable simple symmetric encryption for password storage on user configuration file Nov 3, 2021
@CGuichard
Copy link
Collaborator

CGuichard commented Nov 3, 2021

State of the art in Eodag

As of now, there exists multiple ways to provide a password/token for each provider :

  • peps, creodias, onda: <provider>.auth.credentials.password
  • usgs: <provider>.api.credentials.password
  • theia: <provider>.auth.credentials.pass
  • aws_eos, astraea_eod, usgs_satapi_aws, earth_search: <provider>.auth.credentials.aws_secret_access_key
  • sobloo, mundi: <provider>.auth.credentials.apikey

Each of these fields accept raw value of the credentials. The problem is that if the configuration file is leaked, or shared for debug purposes, the credentials are compromised.

Proposal

Symmetric encryption

As suggested by this issue, it would be better to use a simple symmetric encryption to store the credentials in a more secured way.

The symmetric encryption can be done with cryptography, a widely used Python library.

In this library, a string can be encrypted with a key, and decoded with the same key. Example of key: XKSXP8mwCHN-IE0N5K58rC6VU1_belgYDEb_F-341D0=.

Configuration file

The problem with this issue is how to implement this encryption without adding breaking changes that would break the user's configuration file after upgrading their eodag to a version adding credentials encryption.

We can add a file named "credentials-keys.yml" inside the user's config folder for eodag, alongside of "eodag.yml" and "locations.yml". This file will contain the keys used to encrypt and decrypt the credentials passwords/tokens.

Example of "credentials-keys.yml":

peps: DKqDt8EMTSXpAT4c_uTEnORsOBs1iJG5ssMcID6_7aA=
sobloo: q-HOmuiiNmFCpme7sE6BYZOkmMPHUE4YSfzmoY4vxqw=
aws_eos: i33eNDec267-cNSexsydACFPpyTbzDeWH-F3qmTTi6k=
theia: 2IbOUYku6wqbRNThX-bwqGOwyVWPdHsbbXqbpoL--vE=
usgs: # empty entries are not used

When the config of the providers is loaded from "eodag.yml", if the file "credentials-keys.yml" exists each provider's password/token field inside "eodag.yml" is decrypted if it has a non-empty entry inside "credentials-keys.yml". When the provider isn't inside "credentials-keys.yml" its password/token remains a raw value. In my example, above, the password for peps would be decrypted when loading the config, but the password for creodias would not because it doesn't have an entry inside "credentials-keys.yml". The same can be said for usgs, with an empty entry no decryption is done.

Command

I have described the behavior of eaodag when reading the config with encryption/decryption support. How does the user use it ? I suggest we add a command to manage it.

Example:

$ eodag credentials creodias
password: # use of "getpass" module for password input type
... # Log
OK
$ eodag credentials astraea_eod
aws_secret_access_key: # use of "getpass" module for password input type
... # Log
OK

This command take the user input, encrypt it with a newly generated key, save the key to "credentials-keys.yml", and save the encrypted credential to "eodag.yml".
Saving to "eodag.yml" isn't trivial, because when saving with the yaml standard module the order of the keys and the comments aren't preserved.
I think modifying only the needed field and not mess with the user config file is important, so we may have to create a kind of custom parser to do it, or use ruamel.yaml, a derivative that keep the key order and the comments.


This proposition is the best way I can find to add password/token symmetric encryption without creating breaking changes.

@CGuichard
Copy link
Collaborator

After discussing with @sbrunato, we found a satisfying solution:

The credentials fields will be removed from "user_conf_template.yml" to prevent new users from having raw credentials in the config file, but the credentials fields will be added to "providers.yml" to keep them documented.

All credentials will be encrypted and saved inside a file named "credentials.yml". Encryption and decryption of the credentials will be done with cryptography. The config will load first the user's "eodag.yml", and override/add to the credentials the ones stored in "credentials.yml". If credentials are found in "eodag.yml", a warning will be issued to notify the user that he needs to remove them, and use the new subcommand credentials to create safe credentials.

@CGuichard CGuichard self-assigned this Nov 22, 2021
CGuichard added a commit that referenced this issue Nov 29, 2021
CGuichard added a commit that referenced this issue Nov 29, 2021
@CGuichard CGuichard linked a pull request Nov 30, 2021 that will close this issue
CGuichard added a commit that referenced this issue Dec 2, 2021
CGuichard added a commit that referenced this issue Dec 2, 2021
CGuichard added a commit that referenced this issue Dec 2, 2021
CGuichard added a commit that referenced this issue Dec 2, 2021
CGuichard added a commit that referenced this issue Dec 21, 2021
CGuichard added a commit that referenced this issue Dec 21, 2021
CGuichard added a commit that referenced this issue Mar 14, 2022
CGuichard added a commit that referenced this issue Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants