Contrairement à ce qu’annonce la firme spécialisée dans la prise de rendez-vous médical Doctolib, elle ne chiffre pas l’ensemble de vos données de bout en bout.
Bon, il y a aussi l’administrateur de la base de données qui a accès.
Si on veut tout crypter, personne ne saurait ce qu’il y a dedans.
Doctissimo dit chiffrer de bout en bout. Pas qu’ils ne possèdent pas les clés de déchiffrage il me semble…
La seul fois que j’ai utilisé leur truc, j’étais meme pas inscrit dans la rdv… hop compte supprimé.
Tout à fait ! +1
Dans le principe, je suis tout à fait d’accord.
Mais dans ce cas, je m’inquièterais tout de même beaucoup pour la sécurisation des comptes et des données, car nos services publics ou administrations ne sont pas des cadors de la cybersécurité.
7 « J'aime »
Non, pas nécessairement. Les données peuvent être chiffrées dans la base de données.
Non, pas forcément. On pourrait avoir un système de chiffrement à clés asymétriques, qui pourrait fonctionner sans que Doctolib n’ait ce qu’il faut pour déchiffrer.
Lors de l’inscription (aussi bien côté praticien que côté patient), on génère sur le poste de l’utilisateur une paire de clés, on chiffre la clé privée avec le mot de passe et on envoi au serveur Doctolib la clé publique en clair, la clé publique chiffrée et un hash salé du mot de passe (ainsi le serveur ne connait jamais le mot de passe, donc est incapable de déchiffrer la clé privée, mais peut par contre vérifier l’authenticité du mot de passe quand on se connecte au compte).
Ensuite, pour le motif de la visite par exemple, qui n’a besoin d’être connu que par le praticien, il suffirait que lorsque le patient s’inscrit, il récupère auprès du serveur la clé publique du praticien, chiffre le motif sur son ordinateur avec cette clé et envoie le résultat au serveur. Le serveur n’a ainsi qu’une version chiffrée du motif, et seul le praticien peut la déchiffrer avec sa clé privée.
À l’inverse, si le praticien doit remonter des données au patient, elles devraient être chiffrées avec la clé publique du patient, pour que seul lui puisse les déchiffrer avec sa clé privée.
L’inconvénient de cette solution est par contre que la clé privée est forcément perdue en cas de perte du mot de passe, mais ce n’est pas non plus dramatique, d’autant qu’on peut par exemple doubler toutes les données (en les stockant chiffrées avec la clé publique du patient et avec celle du praticien), comme ça si l’un des deux doit réinitialiser sa clé privée on peut demander à l’autre partie de renvoyer les données chiffrées avec la nouvelle clé publique de l’autre.
4 « J'aime »
Que tous ceux qui ont vraiment pensé que leurs données etaient sécurisé ne s’en prennent qu’à eux même.
« Ne vous inquiétez pas, la très grande majorité de vos données sont entre de bonnes mains », c’est fou comme cette phrase a l’effet inverse de ce qu’elle prétends.
Les gens ont pris l’habitude de lâcher tout un tas de données sur plein de site dit gratuit et après s’etonnent.
La plupart des personnes sont devenus des fénéants, sous couvert qu’ils croient ce que raconte la plupart des boites qui leur facilite des choses, ex: mot passe enregistré sur un navigateur ou autre software pour ne pas le retaper plus tard, etc…
Pourquoi les pirates infomatiques vont s’en priver si vous leur facilité la tâche avec les bases de données non protéger, d’ou l’essors des piratages de grandes ampleurs et sans bouger de chez vous.
Des spécialistes, ça s’embauche, et je suis certain que des whitehat seraient prêts à faire le taf pour le bien de la société.
Déléguer des services régaliens à des boites privées, c’est la pire des solutions.
1 « J'aime »
Pour étayer mes propos voici un lien tre interessant. L’une des premiere conclusions c’est que le 1er maillon faible en sécurité c’est la personne devant son PC, telephone etc…
Toute action entraine une conséquence.
…la CPAM aurait sous-traité le développement et la mise en prod de l’outil, à tous les coups…
3 « J'aime »
Ok donc apparemnt on n pas ajouter de lien.
Chercher CYBERSÉCURITÉ Les professionnels de la cybersécurité sont-ils tous au bord du burn-out ?
On n’est pas tout a fait sur un service régalien ici. C’est un service privé que payent des médecins privés (du secrétariat en fait!). Reste qu’effectivement ce sont des données très sensibles…
1 « J'aime »
Faux (je pense) c’est régalien car les données de santé sont hautement sensibles et très personnelles …
Jamais utilisé doctolib : je suis contre ce genre de service opaque
La santé des citoyens, c’est un service public régalien à mon sens, d’ailleurs, c’est bien le gouvernement qui initie des choses du genre vaccination de masse, qui régule les tarifs et les autorisations de mise sur le marché, etc… Pas le privé.
Et justement, laisser le traitement de données médicales sensibles aux mains des privés c’est une grosse lacune quand on sait à quelle point ces données sont convoitées par d’autres acteurs eux aussi privés.
Et si on considère la nature des médecins, ils sont rémunérés pour une grande part de leur revenu par la sécu, de l’argent public, mais bon, ceci est une autre histoire.
Effectivement, si tu rattaches la santé et les données associées à la sécurité, c’est effectivement du « régalien ».
Chaque utilisateur, enregistré à son insu par son médecin ou pas, peut demander par courrier recommandé la suppression de l’ensemble de ses données personnelles en faisant explicitement référence au texte de loi qui le permet.
Tu veux parler de Doctolib plutôt, non ?
1 « J'aime »
Oui bien sûr 
Et alors ? Ça n’empêche pas un stockage chiffré… Parce que les gens consultent depuis ces terminaux en utilisant leur mot de passe. Donc avec une clé de chiffrement dérivée du mot de passe, leur PC perso, leur smartphone, etc… peuvent connaître la clé de déchiffrement, sans pour autant que le serveur ait besoin de la connaître (il n’a besoin de connaître que le hash salé du mot de passe, pour authentifier l’utilisateur).
Il existe plein de services avec chiffrement de bout en bout qui fonctionnent très bien sur PC, smartphone, etc…
Voilà en simplifié le processus :
À l’inscription :
- l’utilisateur saisit un mot de passe sur son poste,
- du code s’exécutant côté client (JavaScript par exemple) calcule un hash salé (avec un sel qui peut être soit aléatoire, soit dérivé de l’identifiant ou du mot de passe, soit fourni par le serveur) du mot de passe, calcule une clé maîtresse dérivée du mot de passe et génère une paire de clés RSA,
- le client chiffre la clé privée,
- le client envoie le hash salé et son sel (s’il est aléatoire), la clé privée chiffrée et la clé publique au serveur.
Lors de la prise de rendez-vous :
- l’utilisateur saisit son identifiant et son mot de passe,
- le client demande au serveur le sel associé à cet utilisateur (si le sel est aléatoire ou fourni par le serveur),
- le client calcule le hash salé du mot de passe et l’envoi au serveur,
- si le hash est ok, le serveur renvoie au client la clé privée chiffrée avec la clé maîtresse et la clé publique,
- le client calcule la clé maîtresse et déchiffre la clé privé,
- le serveur envoie les données chiffrées au client,
- le client déchiffre les données avec la clé privée => il a désormais les données en clair, sans qu’elles aient jamais transité par le serveur et sans que le serveur ait jamais eu les informations nécessaires pour déchiffrer.