Réflexions sur l'efficacité de hardware chiffrées pour stockage de mots de passe
-
@tulsene a dit dans Solutions hardware chiffrées pour stockage de mots de passe :
Intéressant comme hardware, l’utilises tu?
Nope, mais je vais essayer.
En revanche, si le système m’attire, je suis loin, très loin d’avoir les compétences pour juger de sa fiabilité. Ce qui me plait, c’est de cogiter à comment ma grand-mère ferait pour utiliser de la crypto, et de manière sécurisée. Brancher un truc en USB qui gère les mots de passe est séduisant. “Mamie, tu mets le bidule là… Non, là c’est pour le DVD… Non, le DVD, c’est comme une bobine de super 8, mais en disque. Pis c’est pas la question… Le truc, tu le mets en dessous… Là… Voilà… Rectangle sur rectangle… D’où le fait que ça ne marche pas avec un DVD, mais on verra ça plus tard…”
Vivement que l’on puisse s’authentifier avec une paire de clé privée/publique ECDSA (ou autre), là on aura vraiment avancé en matière de sécurité poru l’authentification (tout en utilisant un hardware comme ledger) car ce genre de système est toujours sensible aux keyloggers
Pas compris… Quel système est toujours sensible aux keyloggers ?
-
Quel système est toujours sensible aux keyloggers ?
Je n’ai pas étudié à fond leur système (et n’ai pas l’expertise pour le faire), mais de ce que j’en ai compris, sur ce type de stockagei : il y a le mot de passe général qui peut être “enregistré” lors ce que tu déverouille la clé et lors ce que tu copie colle un mot de passe contenu dans la clé. Il y a donc un sentiment de sécurité qui peut être dangereux dans certains contextes.
Le vrai de problème vient des sites auquels ont s’identifie : ils utilisent un système d’authentification faible (les pires étant ceux qui empêchent l’utilisation de mot de passe de plus de 8 caractères…). En revanche, avec le principe de clé privée, clé publique, on peut imaginer des systèmes bien performant : chaque mot de passe est unique (donc même si on capte d’une manière ou d’une autre la donnée, elle est inutilisable). Couplé à un hardware wallet on aurait donc simplicité d’utilisation et sécurité fortement accrue.
-
@tulsene - Nope, tu unlock le biniou, et il remplit automatiquement les champs login et password. Pas besoin de copier le MdP en clair, pour le coller dans l’invit’ d’authentification.
La faille, ici, vient de la création de la paire login/password, qui est, elle, vulnérable si créée sur une machine vérolée, en amont du stockage sur l’appareil. Effectivement, j’aimerais bien savoir s’il crée les clefs publique/privée en interne, pour les hermétiser.
Par contre, sur la version chère, le Mooltipass, le PIN à entrer, pour débloquer le bouzin, se tape sur le hardware, comme un Ledger. Pour le MemType, j’ai l’impression que c’est au clavier, rapport à qu’il n’y a pas d’écran OLED ni de petit bouton de navigation. Par contre, automatiser un poutrage de clef cryptée, offline, quand branchée seulement au besoin, ça commence à faire un cahier des charges pesant, pour l’attaquant, et la fenêtre de tir est étroite. Pas mon genre de miser sur les statistiques peu probables, mais ce qui est sûr, c’est qu’entre un VeraCrypt et autres password managers, on n’est pas si mal…
-
@nakhom ok, je n’avais pas capté que le champ était rempli automatiquement par l’appareil, mais je me pose alors la question : est ce que c’est toujours le même mot de passe chiffré qui est utilisé?
-
@tulsene a dit dans Solutions hardware chiffrées pour stockage de mots de passe :
est ce que c’est toujours le même mot de passe chiffré qui est utilisé?
Comment ça ?
-
@nakhom c’est en fait une question réthorique mal formulée
En fait, même si c’est l’appareil qui rempli le champ et que le champ rempli est chiffré, comme c’est toujours la même information qui est utilisée, si un attaquant à accès à cette information il est donc en mesure d’utiliser ton mot de passe.
-
@tulsene - Oui, j’avais cet espèce de fantasme que le hardware communiquait en chifrré avec l’interface, comme le Ledger, mais c’est une connerie, dès l’instant que l’application n’est pas dédiée. Cette solution n’apporte en fait pas grand chose de plus qu’un KeyPass, à ceci près que les MdP sont stockés à froid. Tu as raison sur le fait que ça peut induire un faux sentiment de sécurité. Néanmoins, bien que pas encore parfait, ça permet une toute petite couche de sécurité en plus :
- Stockage des MdP offline
- Remplissage des champs automatique [plus de copier/coller]
Back to square one…
-
C’est ni plus ni moins qu’un microcontrôleur AVR qui émule un clavier.
L’algo de cryptage sur la clef est un peu léger, ce qui est normal au vu des capacité limités du microcontrolleur.
Aucune sécurité contre les key loggers logiciels.
Aucune sécurité contre un “sniffing” du port USB (mot de passe envoyé en clair).
Aucune sécurité en cas de vol.Équivalent plus ou moins à un post-it collé sous son clavier, le coté “je suis un flemmard” en plus.
-
PWAH ! Bon, un admin pourrait éditer le titre, voire retirer le sujet, vu l’erreur, svp ? Merci @raoullevert pour les précisions. Des pistes pour une solution de stockage à froid ?
-
Cette analyse n’engage que moi, mais d’après ce que je vois c’est plus ou moins un arduino nano. Le ledger que tu cites emploies des solutions un peu plus evoluées. Le tindie a sûrement une utilité, mais pour ma part je n’aurais aucune confiance en l’utilisant.
Une réponse trouvé à une personne voulant protéger son AVR contre un dump et un reverse :
“Atmel’s AVR line are not high security devices (unless explicitly noted!) and as such they absolutely don’t come with any code safety guarantee, nor should they! Like all non-secure devices (and sadly even some secure ones,) they are prone to common attacks!”Effectivement c’est pratique comme petit puce, mais pas adaptée à quelque chose de sensible.
-
@nakhom, c’est bien de garder, surtout quand c’est des échanges instructifs mais que penses-tu de ce titre?
-
il faut rajouter : vous avez 2 heures pour répondre.
-
Allez, 3 !
-
@tom-syphers - Perfecto, merci !
