Kresus app - sécurité des données

Support apps
1

Bonjour,

Je suis bien tenté d’essayer cette appli mais je me pose des questions sur la sécurité des informations.

L’application est basée sur weboob
Elle utilise les identifiants de connexion au site de la banque pour récupérer les informations de compte.

Je n’ai pas trouvé de moyen de m’assurer que les identifiants et mot de passe sont bien en sécurité

@LowMem , est-ce que tu as l’info ?

Merci
Cyril

1 Like
2

Bonjour
Si j’ai bien compris, les identifiants ne sont pas en sécurité. Il me semble même qu’ils soient stockés en clair si je ne m’abuse ?
Je pense que c’est vraiment une app à avoir sur son cloud en local … Faut vraiment pas que quelqu’un ait d’accès root.
Mais peut être ça a évolué depuis ?

3

Bonjour,

Alors, je n’ai pas trop examiné le code de kresus, mais voici les tests rapides que j’ai faits:

  • Kresus est protégé par le login/mot de passe des utilisateurs configurés dans la YUNoHost box

  • Kresus n’est pas (encore) multi-utilisateurs: quel que soit l’utilisateur de ma YUNoHost box, j’arrive sur la même “configuration” de Kresus (mêmes comptes, mêmes catégories pour les dépenses/entrées d’argent, mêmes budgets, etc…)

  • Comme l’indique @scith: On peut retrouver les accès aux comptes bancaires en clair (dans les journaux et autres fichiers utilisés par le serveur Kresus: logs, etc…)

Personnellement, cela me suffit amplement pour mon usage: gestion de mes comptes bancaires et budgétisation mensuelle avec la personne avec laquelle je partage ma vie (et ma YUNoHost box :wink: ).

Bref, la FAQ du site officiel dit vrai ! (mais personne n’en doutait) :smiley:

4

Salut, ici Benjamin (core team de Kresus)

A l’heure actuelle, les identifiants et mots de passe sont stockés en clair dans la base de données de Kresus ; c’est un point sur lequel on aimerait vraiment s’améliorer. Parmi les pistes futures :

  • utiliser un couple de clés asymétriques pour que le seul le serveur puisse avoir accès aux identifiants et mots de passe (même si la base de données est compromise). C’est un bon premier pas, mais quelqu’un qui a accès au serveur pourrait donc avoir accès aux données bancaires (remarquez, si votre serveur a été compromis, vous avez sûrement d’autres soucis à vous faire…). La plupart des services genre Linxo etc. font ça, a priori.
  • créer un mode de connexion dans lequel on ne stocke pas du tout le mot de passe côté serveur ; cela signifierait qu’à chaque connexion à Kresus, on donne son mot de passe pour mettre à jour les informations bancaires (et bien évidemment, impossible de faire une connexion automatique toutes les nuits au site de la banque, donc l’intérêt est très réduit).

A priori, la première solution serait implémentée à court voire moyen terme (Kresus est toujours officiellement en beta).

Ensuite, pour ce qui est des données bancaires elles-mêmes (opérations etc), on pourrait imaginer un mode où Kresus chiffre tout à l’aide d’un mot de passe que l’utilisateurice doive rentrer à chaque utilisation (pour déchiffrer localement, juste sur le navigateur). Dans ce mode, Kresus n’aurait aucune connaissance des informations bancaires, sauf au moment de la récupération automatique. Là, on est plutôt dans le domaine du rêve à l’heure actuelle, parce que ça remet en cause beaucoup de fonctionnalités de Kresus et ça implique de recoder beaucoup beaucoup de choses :stuck_out_tongue:.

Je tiens à préciser une chose : les identifiants sont protégés (i.e. chiffrés) sous Cozy (sécurité implémentée par Cozy, non pas par Kresus), mais pas dans YNH.

Voilà, n’hésitez-pas si vous avez des questions (ou êtes motivé.e.s pour aider à l’implémentation d’une meilleure sécurité dans Kresus ;))

Cheers,
Ben

1 Like
5

D’après moi, il faut relativiser le fait de stocker des choses “en clair”… De nombreux logiciels stockent des mot de passe ou des clefs en clair, tout simplement parce que à partir du moment où l’on automatiser quelque chose qui requiert une authentification, on passera forcément par une donnée en clair. Que ce soit un mot de passe, une clef SSH privée, ou un token d’API.

Pour moi le véritable truc cool serait que les banques/assurances/… mettent à disposition des APIs type OAuth où on a un token avec des permissions limités etc… Ca permettrait de limiter le risque (e.g. accès juste en lecture) ou d’avoir une tracabilité si il y a un abus (e.g. action déclenchée via un token donné) et de révoker le token en cas de compromission… Mais bon, quand on vois comment l’interface en ligne des banques est bien foutu, y’a du chemin à faire de leur côté avant d’en arriver là :wink:

1 Like
6

Cela me semble être un bon compromis : Plus de MAJ automatique la nuit, mais MAJ automatique à la connexion de l’utilisateur.

7

C’est vrai que le temps perdu pour mettre à jour “à chaud” les données lors de la connexion semble peu en regard du gain de sécurité associé! Et pour couronner le tout, ça ne doit vraiment pas être très compliqué à coder :wink:
La seule chose que l’on perd c’est une alerte automatique par mail déclenchée par un certain montant par exemple.