• [^] # Re: Budget Insight, et son "haut niveau de sécurité"

    Posté par . En réponse à la dépêche Ces start-ups qui contribuent au Libre. Évalué à 2. Dernière modification le 03 décembre 2012 à 21:07.

    • 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).

    Tel que c'est écrit ici, je vois au moins deux problèmes. De ce que je comprends, au moins fonctionnellement, l'archi ressemble à ça :

     +----+ +--------+ +--------+ +-------+ +--------+ +------+
     |user|<-->|internet| <->|frontend| <-->|backend| <-->|internet| <--> |banque|
     +----+ +--------+ +--------+ +-------+ +--------+ +------+
    
    

    Donc:

    • 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) ?
    • 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 ?