Bonjour à tous,
Nouvel utilisateur, ancien utilisateur Finary, je suis en train d'évaluer Gesfine.
Avant d'entrer mon login / mot de passe dans Gesfine, je me pose quelques questions de sécurité, surtout que je n'ai pas de login "read only" sur mes établissements bancaires. Je cherche aussi savoir si je dois prendre des dispositions particulières pour sécuriser la base de données Gesfine (stockage sécurisé, localisation des backups...).
Comment est sécurisé le stockage du mot de passe et des données personnelles ? Encryption symétrique ? Stockage dans la base de données, dans l'OS avec le profile utilisateur, ailleurs ?
Mon objectif est d'être sûr que la base de données (ou son backup) ne soit pas suffisant pour cracker les credentials.
Cela suppose une encryption robuste et des clefs pas posées sur le coffre ....
Comment les authentifications multi-facteurs (MFA) des banques sont elles supportées ? Par des popups ?
Faut-il/ peut on plutôt passer par un agrégateur de compte certifié type Linxo ou Powens ou une interface DSP2 / passkeys ?
Merci beaucoup
Cordialement
Philippe
Source de données - Opérations courantes - sécurité
Modérateur : Patrice15220
-
- Administrateur
- Messages : 6893
- Enregistré le : 04 janvier 2010, 20:03
- Localisation : France (Yvelines 78)
- Contact :
Re: Source de données - Opérations courantes - sécurité
Bonjour,
Le cryptage du mot de passe du titulaire est un cryptage irréversible, le cryptage de toutes les autres données de type texte est un cryptage réversible (Cela inclut les identifiants et mots de passe utilisés par les sources de données pour leur connexion). Ce cryptage s'appuie sur des clés dépendant d'un algorithme et des propres données de l'utilisateur. L'algorithme intégré au programme est obfusqué par un outil de virtualisation du code.
C'est acceptable si ce n'est pas systématique, dans le cas contraire, il faut adapter la source pour que la connexion soit gérée manuellement par l'utilisateur avant qu'il n'engage le processus/le script d'importation des données.
Le cryptage du mot de passe du titulaire est un cryptage irréversible, le cryptage de toutes les autres données de type texte est un cryptage réversible (Cela inclut les identifiants et mots de passe utilisés par les sources de données pour leur connexion). Ce cryptage s'appuie sur des clés dépendant d'un algorithme et des propres données de l'utilisateur. L'algorithme intégré au programme est obfusqué par un outil de virtualisation du code.
La principale sécurité repose sur le non partage des données dans un cloud. Si ta base (ou une sauvegarde) est accessible à une personne malveillante, que cette personne arrive à décompiler le programme en passant outre la virtualisation du code, alors tes données seront décryptables.Fifi a écrit : 20 novembre 2024, 11:43 Mon objectif est d'être sûr que la base de données (ou son backup) ne soit pas suffisant pour cracker les credentials.
Mal, lorsqu'une validation secondaire à la saisie d'un mot de passe est nécessaire, l'étape de connexion de la source est interrompu et rend la main à l'utilisateur pour qu'il valide la double authentification par lui même.Fifi a écrit : 20 novembre 2024, 11:43 Comment les authentifications multi-facteurs (MFA) des banques sont elles supportées ? Par des popups ?
C'est acceptable si ce n'est pas systématique, dans le cas contraire, il faut adapter la source pour que la connexion soit gérée manuellement par l'utilisateur avant qu'il n'engage le processus/le script d'importation des données.
Je ne connais pas ces agrégateurs, et aucune source n'existe pour s'y connecter.Fifi a écrit : 20 novembre 2024, 11:43 Faut-il/ peut on plutôt passer par un agrégateur de compte certifié type Linxo ou Powens ou une interface DSP2 / passkeys ?
Re: Source de données - Opérations courantes - sécurité
Bonsoir Jacques,
Merci beaucoup pour les réponses clairs et précises. Cela confirme ma compréhension du fonctionnement.
Si la base de données est accessible, c'est alors la compréhension de l'algorithme qui protège la clef d'encryption. Et l'algorithme est lui-même protégé par l'offuscation. (et par les mesures prises par le développeur pour protéger le code source et ses backups).
Une option de stockage d'un morceau des clefs ou des clefs entière dans la TPM ou dans le certificate store aurait été un plus, même si cela complexifie d'un autre côté la sauvegarde des clefs (dans son password manager)
Le stockage de la base de données doit effectivement être sécurisé ainsi que le stockage des 2 types de backup (automatique et utilisateur). Concrètement, cela veut dire authentification forte sur le/les comptes utilisateurs windows et NAS, encryption at rest des zones de stockage avec accès exclusif par le compte utilisateurs, et mesures de sécurité usuelles sur le poste de travail.
La sécurité de nos comptes bancaires est encore aujourd'hui principalement assurée par l'email et le téléphone (Reset, MFA...). Si l'un ou l'autre est compromis, alors de toute façon, les accès bancaires seront compromis assez directement. Il faut donc essayer de ne pas être moins sécurisé que son email et son téléphone.
Linxo offre une possibilité d'export CSV, OFX ou QIF de tous les comptes aggrégés.
Sur le CSV, les colonnes sont :
Cela devrait être une bonne option dans mon cas pour les opérations courantes.
Il n'y a pas d'URL directe pour exporter mais un bouton par format d'export est proposé. Vu la richesse fonctionnelle du module de gestion des sources de données, cela doit être jouable assez simplement.
Pour la partie MFA, si c'est effectivement redemandé tous les 90 ou 180 jours, c'est acceptable. Cela suppose que le cache Chromium (CEF) conserve les cookies d'une session sur l'autre et qu'il ne soit pas resetté. J'ai fait un test rapide et cela semble le cas - mais je n'ai pas (encore) retrouvé la localisation du cache. Je vais aussi tester en déclarant Linxo dans les liens pour la navigation et en me connectant deux fois. Normalement, il devrait me demander une seule fois le 2ieme facteur d'authentification. Idem sur les autres banques.
Si le cache Chromium n'est pas stocké au même endroit que la base de données cela diminue aussi le risque : la base de données seule ne permet alors pas de se connecter aux comptes bancaires ou à Linxo : il faut également un accès au poste de travail ou à une copie du cache ou au MFA ....
Depuis fin 2019 (directive DSP2), les banques et les prestataires de services de paiement doivent mettre en œuvre une authentification multifacteur pour la plupart des paiements à distance, l’accès au compte ainsi que les opérations sensibles (ajout de bénéficiaire de virements, commande de chéquier, changement d’adresse, etc.). La fréquence maximale pour la réauthentification était de 90 jours avant 2023 et est désormais 180 jours. En attendant la généralisation des passkeys, on va devoir faire avec l'authentification multifacteur et continuer de protéger ses login et mots de passe...
Merci encore
Cordialement
Philippe
Merci beaucoup pour les réponses clairs et précises. Cela confirme ma compréhension du fonctionnement.
Si la base de données est accessible, c'est alors la compréhension de l'algorithme qui protège la clef d'encryption. Et l'algorithme est lui-même protégé par l'offuscation. (et par les mesures prises par le développeur pour protéger le code source et ses backups).
Une option de stockage d'un morceau des clefs ou des clefs entière dans la TPM ou dans le certificate store aurait été un plus, même si cela complexifie d'un autre côté la sauvegarde des clefs (dans son password manager)
Le stockage de la base de données doit effectivement être sécurisé ainsi que le stockage des 2 types de backup (automatique et utilisateur). Concrètement, cela veut dire authentification forte sur le/les comptes utilisateurs windows et NAS, encryption at rest des zones de stockage avec accès exclusif par le compte utilisateurs, et mesures de sécurité usuelles sur le poste de travail.
La sécurité de nos comptes bancaires est encore aujourd'hui principalement assurée par l'email et le téléphone (Reset, MFA...). Si l'un ou l'autre est compromis, alors de toute façon, les accès bancaires seront compromis assez directement. Il faut donc essayer de ne pas être moins sécurisé que son email et son téléphone.
Linxo offre une possibilité d'export CSV, OFX ou QIF de tous les comptes aggrégés.
Sur le CSV, les colonnes sont :
- Date
Libellé
Catégorie
Montant
Notes
N° de chèque
Labels
Nom du compte
Nom de la connexion
Cela devrait être une bonne option dans mon cas pour les opérations courantes.
Il n'y a pas d'URL directe pour exporter mais un bouton par format d'export est proposé. Vu la richesse fonctionnelle du module de gestion des sources de données, cela doit être jouable assez simplement.
Pour la partie MFA, si c'est effectivement redemandé tous les 90 ou 180 jours, c'est acceptable. Cela suppose que le cache Chromium (CEF) conserve les cookies d'une session sur l'autre et qu'il ne soit pas resetté. J'ai fait un test rapide et cela semble le cas - mais je n'ai pas (encore) retrouvé la localisation du cache. Je vais aussi tester en déclarant Linxo dans les liens pour la navigation et en me connectant deux fois. Normalement, il devrait me demander une seule fois le 2ieme facteur d'authentification. Idem sur les autres banques.
Si le cache Chromium n'est pas stocké au même endroit que la base de données cela diminue aussi le risque : la base de données seule ne permet alors pas de se connecter aux comptes bancaires ou à Linxo : il faut également un accès au poste de travail ou à une copie du cache ou au MFA ....
Depuis fin 2019 (directive DSP2), les banques et les prestataires de services de paiement doivent mettre en œuvre une authentification multifacteur pour la plupart des paiements à distance, l’accès au compte ainsi que les opérations sensibles (ajout de bénéficiaire de virements, commande de chéquier, changement d’adresse, etc.). La fréquence maximale pour la réauthentification était de 90 jours avant 2023 et est désormais 180 jours. En attendant la généralisation des passkeys, on va devoir faire avec l'authentification multifacteur et continuer de protéger ses login et mots de passe...
Merci encore
Cordialement
Philippe
-
- Messages : 1705
- Enregistré le : 18 août 2013, 15:29
- Localisation : St Mamet La Salvetat (Cantal 15)
Re: Source de données - Opérations courantes - sécurité
Bonjour Philippe,
Pour y accéder : %Temp%\CefCache
Il se situe dans le répertoire temporaire défini dans les variables d'environnement système, et se nomme "CefCache".
Pour y accéder : %Temp%\CefCache
-
- Administrateur
- Messages : 6893
- Enregistré le : 04 janvier 2010, 20:03
- Localisation : France (Yvelines 78)
- Contact :
Re: Source de données - Opérations courantes - sécurité
Bonjour,
Pour une importation multicompte, manuellement, seul le format OFX est supporté, automatiquement une source de données procède compte par compte.
Je te recommande d'essayer avec le format OFX, même si cela nécessite quelques règles d'importation pour formater les champs.Fifi a écrit : 22 novembre 2024, 03:28 Linxo offre une possibilité d'export CSV, OFX ou QIF de tous les comptes agrégés.
Pour une importation multicompte, manuellement, seul le format OFX est supporté, automatiquement une source de données procède compte par compte.
Re: Source de données - Opérations courantes - sécurité
Bonjour,
Merci pour les précisions. Cela m'aide beaucoup dans mes choix de configuration.
J'ai quitté Finary à cause de la difficulté à assurer la qualité des données avec la version à l'époque.
Je cherche donc à maitriser la qualité des données à l'importation.
Je pense aussi rester dans une logique par compte et par mois.
Cela permet de corriger les erreurs éventuelles sur un nombre limité d'opérations et c'est adapté au pointage.
Linxo permet de filtrer l'export avec plein de critères, dont le compte, les dates, les types d'opération - donc je pourrai facilement exporter/importer mes écritures par compte et par période.
Linxo ne gère pas les devises et les comptes étrangers ne sont pas synchronisés automatiquement. C'est la plus grosse limitation. Pour ces comptes étrangers, je compte les importer a priori manuellement directement dans Gesfine.
Prochaine étape : maitriser les formats d'importation dans gestfine.
L'automatisation sera pour plus tard....
Merci encore
Philippe
Merci pour les précisions. Cela m'aide beaucoup dans mes choix de configuration.
J'ai quitté Finary à cause de la difficulté à assurer la qualité des données avec la version à l'époque.
Je cherche donc à maitriser la qualité des données à l'importation.
Je pense aussi rester dans une logique par compte et par mois.
Cela permet de corriger les erreurs éventuelles sur un nombre limité d'opérations et c'est adapté au pointage.
Linxo permet de filtrer l'export avec plein de critères, dont le compte, les dates, les types d'opération - donc je pourrai facilement exporter/importer mes écritures par compte et par période.
Linxo ne gère pas les devises et les comptes étrangers ne sont pas synchronisés automatiquement. C'est la plus grosse limitation. Pour ces comptes étrangers, je compte les importer a priori manuellement directement dans Gesfine.
Prochaine étape : maitriser les formats d'importation dans gestfine.
L'automatisation sera pour plus tard....
Merci encore
Philippe