Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

Stockage sécurisé en db

+6 votes

Je dois développer une page qui permette à un utilisateur et à un technicien de dialoguer par message via une simple page Web. L'utilisateur sera éventuellement amené à transmettre des identifiants et mot de passe pour une intervention d'un technicien. Je souhaite donc trouver un moyen sûr pour que ces données ne puissent pas être exploitable en cas de compromission de notre site Web (évidemment, on fera en sorte d'éviter cela, mais on n'est jamais 100% à l'abri).

Je me demande quelle est le meilleur moyen de faire cela proprement et sans SPOF. Au stade actuel de ma réflexion, un moyen plutôt sûr serait de déchiffrer les échanges directement coté navigateur via du javascript après connexion de l'utilisateur en utilisant le mot de passe de l'utilisateur comme passphrase. Le problème étant que nos techniciens doivent également pouvoir visualiser les messages et qu'ils ne disposent pas de la passphrase de l'utilisateur (chiffré en db). Il faudrait donc un message qui puisse être déchiffré avec plusieurs clés (au moins deux). De cette manière nous pourrons stocker les échanges chiffrés en DB sans avoir à stocker de clé sur le serveur.

Cela vous parait il une bonne approche ? Si oui, auriez vous des pistes pour avoir une seule serrure et plusieurs clés d'ouverture ?

demandé 3-Mar-2016 par Stiquemou (206 points)
edité 4-Mar-2016 par max

Bonjour,

La sécu est un très vaste sujet.
Pour sécuriser la base en cas de compromission du site, il faudrait que celle ci ne soit déjà pas sur le même serveur, ainsi si le front est "grillé" le back est sauf.

Sinon la topologie que tu recherches est exploitée avec GPG.
Un manager de clés génére des clefs applicatives qui sont signées par lui et par le tiers qui doit échanger.

Ainsi quand l'application chiffre des fichiers, ils sont déchiffrables par le manager et le tiers.
C'est le trousseau de clés qui gere quoi. Je pense pas qu'on puisse gérer un "passe partout" ; tu devras surement en passer par un keyring.

Par contre pour transposer ça dans un browser j'en ai aucune idée.

Je sais pas si ca va t'aider mais c'etait au cas où:)

Merci pour ta réponse.

Je veux partir du principe que l'attaquant a réussi à accéder au serveur SQL et a pu dumper les données, mais je veux qu'il ne puisse pas les exploiter.

Je vais me renseigner du coté de pgp, comme tu l'indiques la sécurité est un vaste sujet et je n'ai que des connaissances assez basique là dessus.

A priori je ne pourrai pas utiliser PGP pour chiffrer ces échanges.
La page doit affiché les échanges entre le technicien et le client, mais les deux doivent pouvoir lire tous les messages sur le fil de discussion. Avec pgp, seuls les messages signés avec la clé publique de l'autre pourront être déchiffrés. Le client pourra lire les messages du technicien sur le fil mais les siens ne lui seront plus visible, et inversement pour le technicien. Je suis un peu perdu dans les solutions de chiffrement, je vais continuer de creuser plus.

Les problématiques :

  • je ne peux pas stocker le mot de passe sur le serveur ou mettre une clé sans mot de passe, l'attaquant aurait juste à l'utiliser pour déchiffrer les messages.

  • Le message doit pouvoir être déchiffré suite à la connexion du client seulement, quand il aura fourni son mot de passe, un hash de celui-ci pourra être utiliser comme passphrase

  • Lorsque le client change de mot de passe, les anciens messages doivent toujours être déchiffrable avec le nouveau mot de passe

Bref si quelqu'un a une idée sur une solution de chiffrement capable de faire cela, ou une autre méthode sûr, je suis toujours preneur :)

@Stiquemou
Tu n'as pas a stocker quoi que ce soit. En theorie, il suffit que chacun possede une clé privée et une clé publique, c'est cette derniere qui sera partagée.

En ce qui concerne le passphrase, si je me fie a comment ça fonctionne avec GPG. Il est parfaitement possible de changer de passphrase, cela n'affecte ni la clé privée, ni la clé publique. Donc, les anciens messages, restent dechiffrables.

Pr envoyer un message, il suffit avant, de le chiffrer avec la clé publique de chacune des personnes devant lire le message. Donc, si A veut envoyer un message à B et s'il veut en meme temps pouvoir lire ses propres messages, il va falloir chiffrer le message une premiere fois avec sa propre clé publique, puis une seconde fois avec la clé publique de B.

Solution de chiffrement? A part python-gnupg que je n'ai jamais utilisé, je ne vois rien d'autre :\

Un tchat sur websocket sur SSL ? Ça devrait le faire, enfin je ferais comme cela de mon côté.

Tu peux aussi utiliser plusieurs clefs pour signer ton message. Tous les destinataires vont pouvoir déchiffrer le message, c'est faisable sans soucis et super pratique (me j'ajoute toujours en tant que destinataire quand j'envoie un mail, que je puisse encore le relire dans ma boite d'envois par la suite, c'est toujours pratique).

1 Réponse

+1 vote

Merci Nsukami_ pour ta réponse.

J'ai pensé à cette solution mais elle me semble trop gourmande en ressource et en stockage, stocker plusieurs fois le message pour le client et les techniciens. Je pense avoir trouver une solution plutôt satisfaisante qui consisterait à avoir une api dans un autre venv que celui où est installé le site.

Avec une simple paire de clé et une passphrase stocker en dur dans le code. L'idée serait ensuite de compiler le code pour le rendre illisible à un attaquant. L'api chiffrerait et déchiffrerait les messages à la volé et les renverrait au site web après authentification du client.

Ce n'est pas parfait mais je crois que ça suffirait à ralentir voire à stopper la majorité des attaquants. Le défaut est que le clé est identique pour tout le monde.

Reste à tester cela en pratique :)

répondu 8-Mar-2016 par anonyme
edité 8-Mar-2016 par boblinux

Du coup, ce sera python-gnupg ou autre chose? Si tu pouvais inclure ds ta reponse, une description un peu plus technique de ta solution, ça me plairait bien.

...