Comment garantissez vous qu'il ne reste aucune trace d'un couple login/password bancaire à l'inscription ou à la modification dans le frontend par l'utilisateur (par exemple, dans le swap) ?
Effectivement nous ne sommes pas allé aussi loin que de s'assurer que ce n'est pas conservé dans le swap, ça devient subtil. Si tu as des suggestions à ce sujet je suis preneur.
Comment garantissez vous que le backend ne s'est pas fait pirater (ben oui, il faut bien qu'il accède à l'internet pour se connecter sur les sites des banques, et ce avec les données localement en clair, non ?
Sur le backend, les données sont en clair uniquement en mémoire au moment de la récupération. Les machines sont dans un VPN, le backend n'écoute aucun service sur Internet, et le frontend n'a d'accès au backend que via un canal ne permettant au premier que de donner quelques ordres au second (il n'a pas de moyen d'y accéder en ssh ou autre).
En gros vous dites que les données de connexion sont chiffrées et qu'on ne peut donc pas les voler. Ensuite, vous insistez sur le fait que le système ne peut pas faire de transfert mais qu'il lit simplement l'état du compte tous les jours. Cela veut donc dire, que la clef utilisée pour chiffrer la base est stockée quelque part (normal sinon ça ne servirais à rien). Au final, le fait d'être "read-only" n'importe pas tant que ça puisque compromettre les serveurs a de grandes chances de donner accès aux données chiffrées ET à la clef nécessaire pour obtenir les identifiant en clair.
En fait il faut voir plusieurs choses dans l'argumentaire :
Le fait de dire que l'application est read-only concerne le cas où l'utilisateur se fait usurper son compte Budget Insight (pas que nos serveurs aient été compromis) ;
Les identifiants bancaires requis pour la synchronisation ne permettent pas de réaliser de virements, puisque la Banque de France oblige les banques à nécessiter l'envoi d'une confirmation par courrier ou SMS pour l'ajout d'un bénéficiaire ;
Les identifiants bancaires sont chiffrés dans la base de données de manière à ce qu'ils ne soient pas déchiffrables par l'application web. Ce qui signifie que si uniquement le site se faisait compromettre, les transactions pourraient être déchiffrées (l'application web ayant besoin de lire ces informations), mais pas les identifiants bancaires ;
Le backend tourne sur une autre machine non accessible depuis l'extérieur. Dans le cas d'une attaque grave où le serveur web frontal serait compromis, il n'y a rien dessus qui permette de déchiffrer les identifiants bancaires (les transactions, en revanche, si).
McAfee c'est quoi ce truc ? Ils scannent votre site pour vérifier qu'il n'y a pas un site de phishing rajouté ? Si quelqu'un arrive à prendre le contrôle de votre site, il aura beaucoup plus intérêt à rester discret et à récupérer la base de données des identifiants et la clef plutôt que de défacer le site.
Il s'agit de robots qui tentent d'attaquer le site et le serveur, pour la découverte d'éventuelles failles. Ces tests ne sont pas exhaustifs évidement, ce qui fait que nous ne nous reposons pas dessus, néanmoins il constitue une preuve que nous sommes résistant sur l'ensemble des tests effectués par McAfee, raison pour laquelle nous le mettons en avant sur la page sécurité.
Enfin, il faut également penser à replacer cette page dans son contexte : la majorité des utilisateurs de BI ne sont pas aussi technophiles que les
lecteurs de linuxfr, et c'est eux qu'elle vise à rassurer.
Ainsi que je vous l'ai signalé par mail, vous avez raison, cette limitation temporaire n'est pas optimale et suite à votre remarque nous allons réaliser les modifications nécessaires.
Néanmoins, je tiens à vous préciser que la restriction du mot de passe d'un utilisateur n'est qu'une mesure de sécurité contre lui-même, qu'elle ne remet aucunement en cause la sécurité réelle de l'application.
[^] # Re: Budget Insight, et son "haut niveau de sécurité"
Posté par BudgetInsight . En réponse à la dépêche Ces start-ups qui contribuent au Libre. Évalué à 1.
Effectivement nous ne sommes pas allé aussi loin que de s'assurer que ce n'est pas conservé dans le swap, ça devient subtil. Si tu as des suggestions à ce sujet je suis preneur.
Sur le backend, les données sont en clair uniquement en mémoire au moment de la récupération. Les machines sont dans un VPN, le backend n'écoute aucun service sur Internet, et le frontend n'a d'accès au backend que via un canal ne permettant au premier que de donner quelques ordres au second (il n'a pas de moyen d'y accéder en ssh ou autre).
[^] # Re: Budget Insight, et son "haut niveau de sécurité"
Posté par BudgetInsight . En réponse à la dépêche Ces start-ups qui contribuent au Libre. Évalué à 10.
En fait il faut voir plusieurs choses dans l'argumentaire :
Il s'agit de robots qui tentent d'attaquer le site et le serveur, pour la découverte d'éventuelles failles. Ces tests ne sont pas exhaustifs évidement, ce qui fait que nous ne nous reposons pas dessus, néanmoins il constitue une preuve que nous sommes résistant sur l'ensemble des tests effectués par McAfee, raison pour laquelle nous le mettons en avant sur la page sécurité.
Enfin, il faut également penser à replacer cette page dans son contexte : la majorité des utilisateurs de BI ne sont pas aussi technophiles que les
lecteurs de linuxfr, et c'est eux qu'elle vise à rassurer.
[^] # Re: Budget Insight, et son "haut niveau de sécurité"
Posté par BudgetInsight . En réponse à la dépêche Ces start-ups qui contribuent au Libre. Évalué à 8.
Bonjour,
Ainsi que je vous l'ai signalé par mail, vous avez raison, cette limitation temporaire n'est pas optimale et suite à votre remarque nous allons réaliser les modifications nécessaires.
Néanmoins, je tiens à vous préciser que la restriction du mot de passe d'un utilisateur n'est qu'une mesure de sécurité contre lui-même, qu'elle ne remet aucunement en cause la sécurité réelle de l'application.
Je vous invite d'ailleurs à visiter notre page sur la sécurité.
Cordialement,
L'équipe de Budget Insight