larlet-fr-david/david/blog/2016/mots-passe-physiques/index.md

title: Mots de passe physiques
slug: mots-passe-physiques
date: 2016-03-23
chapo: Il faut donc être en possession de la carte et du mot de passe personnel pour pouvoir recomposer un mot de passe complet.

> Il restera de toutes façons le point central : les clefs, les mots de passe, les identifiants. Je ne peux pas laisser un document avec tout ça, ni sous forme de papier ni sous forme informatique, ni chez moi ni chez d’autres.
> 
> <cite>*[Que se passe-t-il le jour où je ne suis plus là ?](https://n.survol.fr/n/que-se-passe-t-il-le-jour-ou-je-ne-suis-plus-la)* ([cache](/david/cache/4ec899ed10701458eefc879c105af4e8/))</cite>

[Frédéric](http://blog.mageekbox.net/) propose [sur Twitter](https://twitter.com/mageekguy/status/711961785918754816) d’utilise une [Blockchain](http://maisouvaleweb.fr/la-blockchain-signera-t-elle-la-fin-du-capitalisme/) ([cache](/david/cache/4c0564a79722d5ba5c75ee6da0fec626/)) pour cela. *Il faudrait que j’écrive là-dessus mais j’ai trop d’autres réflexions en attente.* Ce à quoi Éric répond avec [des besoins plus détaillés](https://docs.google.com/document/d/1hn_WQAcR3kjW_HRWGjbaYCMxDu60h3lMQyyRE_urTNk/edit?pref=2&pli=1) que je reproduis ici :

> 1. Les proches qui peuvent débloquer mes données après ma disparition n’ont pas de copie en clair. Avoir confiance dans la sécurité de mon propre stockage est déjà assez difficile, le principe par défaut doit être le chiffrement : stocker un fichier texte avec des mots de passe en clair ne me parait pas viable.
>
> 2. Aucun site centralisé ne contient ni n’accèdent à mes données d’une façon qui pourrait être déchiffrable aujourd’hui ou à l’avenir. Ça entraîne probablement l’idée de ne pas faire confiance à la cryptographie avancée, au cas où on découvre un jour des failles dans les algorithmes ou dans les logiciels. On parle de le garantir sur des décennies. Le seul chiffrement qui me semble correspondre à cette demande est à priori le [one time pad](https://en.wikipedia.org/wiki/One-time_pad)
>
> 3. La procédure est simple à mettre en œuvre pour les proches. Je peux demander d’avoir un minimum de compréhension de l’informatique, pas d’être un ingénieur en informatique.
>
> 4. La procédure et les formats sont suffisamment pérennes pour pour être utilisables et lisibles par l’informatique telle qu’elle sera dans des décennies – et ça exclu probablement tout format ou tout mécanisme avancé qui n’existait pas déjà il y a 20 ans.
>
> 5. Un proche unique ne peut déclencher la procédure et accéder aux données seul, il faut qu’ils soient plusieurs (nombre à définir mais au moins 2)
>
> 6. Quelque chose me demande une preuve de vie de façon récurrente et peut notifier les proches identifiés si je ne réponds pas au bout d’un certain temps, pour les informer du problème et leur rappeler la procédure possible
>
> 7. Quelque chose va s’assurer régulièrement que les proches identifiés sont toujours joignables et ont toujours la capacité de déclencher la procédure – ils ont toujours les données, clefs ou mots de passe dont ils ont besoin, ils savent toujours s’en servir, etc. – et peut me notifier si ce n’est pas le cas
>
> 8. Je peux mettre à jour les données – changer ou ajouter une information – sans que cette mise à jour ne demande d’action pénible par mes proches
>
> 9. Toute la procédure est résiliente à la disparition d’un ou plusieurs des proches identifiés initialement (nombre à définir, au moins 1)
>
> 10. Si la procédure utilise un service tiers, la disparition de ce service et des données qu’il stocke ne fait pas tomber la capacité d’accéder aux données (quitte à ce que ce soit plus complexe)
>
> 11. Pouvoir déterminer arbitrairement X et Y dans “pour débloquer les données il faut l’accord de X personnes parmi les Y chargés de la transmission”

**C’est un sujet qui [m’a fait réfléchir aussi](/david/blog/2013/testament-numerique/) et avec les contraintes énoncées je pense que la solution est technique ET physique.** Il existe [de telles solutions pour geeks](https://blog.imirhil.fr/2015/11/25/password-otp.html) ([cache](/david/cache/13ced99f6dcec926bc25b7f500b7d882/)) mais c’est encore trop complexe pour un contexte familial. Et puis il y a des solutions  comme la [QwertyCard](https://www.qwertycards.com/index) qui me semblent répondre à la problématique (il est possible de [les générer soi-même](http://passwordcards.raphael.li/) et [de manière locale	](https://github.com/raphiz/passwordcards)), elles combinent :

1. Un préfixe unique et aléatoire propre à la carte produite
2. Un mot de passe personnel
3. Une table de conversion pour avoir une partie propre au service

Il faut donc être en possession de la carte et du mot de passe personnel pour pouvoir recomposer un mot de passe complet. En donnant le mot de passe personnel (2) à une personne et la partie du service que je convertie (3) au second de mes légataires je ne leurs permet pas de se connecter pour autant avant d’être en possession de la carte et d’être réunis. Ce n’est pas sans failles mais ça réduit drastiquement la complexité du processus et ça répond à presque tous les besoins d’Éric. Il est possible de tester le système régulièrement en changeant ensuite les accès par la modification de (2) et (3).

**Il reste la problématique de la documentation à jour que je n’ai toujours pas résolue.** Pour la pérennité des données en elles-mêmes, je ne vois pas d’autre solution que d’utiliser des standards ouverts et de les mettre à jour en suivant l’avancée technique dans le domaine. C’est fastidieux mais c’est de toute façon nécessaire, même de son vivant…

*Un lecteur me signale le [partage de clé secrète de Shamir](https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir) qu’il a découvert dans [cet article sur la potentielle perte de mémoire](http://genma.free.fr/?Mots-de-passe-et-perte-de-memoire) ([cache](/david/cache/f385cec772687806e75280ba61684ff5/)).*