Exports chiffrés : repenser l'utilisation du sel (insert diet joke here)

1

Salut à tous,

je pense que le fonctionnement actuel des exports, qui nécessitent pour être déchiffrés d’avoir à la fois le mot de passe fourni par l’utilisateur et le sel de l’instance pose et posera problème encore + dans le futur.

Problème actuel : certains ignorent (manque de documentation ou d’attention ?) que pour importer un fichier Kresus © chiffré, il faut également le sel défini dans la configuration de Kresus.
C’est par exemple le cas dans YunoHost : l’installation est transparente, le sel on ne le connaît pas à moins de fouiller. Bien que la migration soit prévue par YunoHost et gère la question du sel, certains réinstallent complètement Kresus au lieu de migrer (ce qui change donc le sel), et pensent qu’ils pourront réimporter leur fichier.

Problème futur : on se dirige vers une instance pour plusieurs utilisateurs, non admin. Imaginons un https://chatons.org hébergeant plusieurs Kresus. Ses utilisateurs n’ont pas à connaître le sel de l’instance, et ne peuvent actuellement pas.

Le risque c’est que l’utilisateur ne chiffre pas l’export (et donc perde en sécurité mais aussi les identifiants bancaires seront absents de cet export), par facilité.

Piste 1

À l’export on affiche le sel de l’instance et demande à l’utilisateur de le saisir en + de son mot de passe à l’import.

Problème : un utilisateur a le même sel que tous les autres utilisateurs de l’instance.

Piste 2

On déplace le sel au niveau de l’utilisateur (en + ça pourra servir par la suite pour l’authentification), et on l’affiche lors de l’export aussi. À l’import on peut tenter d’importer avec le sel en base (si l’utilisateur réimporte sur son même compte), et si ça échoue, demander à l’utilisateur le sel affiché lors de l’export.

Problème : ça fait deux mots de passe à retenir pour l’utilisateur.

Piste 3

On exige plus de mot de passe de l’utilisateur, mais on en génère un avec son sel, et on l’affiche.

Problème : pas d’utilisation de gestionnaire de mot de passe possible (je doute que ce soit le cas actuellement), et le sel n’a plus vraiment d’importance ici.

Piste X

À vous de la trouver !

2

Bonjour,

Je suis utilisateur de Kresus depuis un peu plus d’un an et j’essaie de suivre un peu les évolutions.
Je ne suis pas particulièrement compétant sur les aspects sécurité/crypto, mais j’apporte quand même mon grain de sel (pun intended).

J’ai l’impression que l’intérêt du sel dans ce contexte, c’est de générer la clé de déchiffrement avec une approche

clé = hash[salt + password]

L’idée principale étant de limiter l’usage d’une Rainbow table.
Si l’intérêt du sel est autre que celui là, alors la suite de mon message n’est pas pertinente, désolé d’avance :sweat_smile:

Dans ce contexte là, moins un sel est réutilisé, plus la sécurité est élevée (un sel = une Rainbow-table à générer à partir de dictionnaires de mots de passe connus). Mais rien n’oblige à rendre ce sel secret.
Soit le sel est public, auquel cas la sécurité de l’export est égal au niveau de sécurité du mot-de-passe utilisateur; soit le sel est privé, auquel cas on peut considérer qu’il a la même fonction que le mot de passe de l’utilisateur et vient juste s’ajouter à ce mot de passe pour en augmenter la complexité.

Je vois donc plusieurs options, l’utilisateur pouvant avoir le choix entre elles:

  • Pas de chiffrement
  • Chiffrement par mot de passe utilisateur => On hash ce mdp avec un sel que l’on laisse en clair dans le fichier exporté. La sécurité sera équivalente à celle du mot de passe (s’il fait parti d’un dictionnaire, la sécurité est presque nulle…)
  • Chiffrement par mot de passe imposé => On génère un mdp aléatoire d’entropie élevée et on chiffre la base de donnée avec ce dernier, sans sel (ou avec sel inclut en clair dans le fichier exporté, ça ne change rien en termes de sécurité mais ça simplifie la compatibilité avec l’option précédente). Le mot de passe généré est affiché à l’utilisateur qui devra le conserver de manière sécurisée
3

Salut !

Merci de ta réponse. Au final on a même eu une PR sur le sujet, de la part d’une personne dont la sécurité est le travail ; l’idée est d’inclure le sel en clair dans le fichier d’export, la sécurité de l’export est celle du mot de passe, mais il est plus « pénible » de générer une rainbow table par sel (enfin de ce que j’ai compris).

@nicofrand, je pense qu’on peut clore le sujet ?

4

Oui on peut close le sujet, la prochaine étape étant en effet de relire/intégrer (je crois que le front n’est pas prêt) la MR sur le sujet !

Merci @mpigou pour ton retour, ton approche sera sûrement celle qu’on utilisera pour les futurs comptes utilisateurs.