imagine that user John Doe, used the password hint “same as Netflix”. […]. During the real investigation, this behavior was noticed in about 30% of all the master password hints, showing that it can totally happen and may not be isolated behavior.
L'intérêt d'avoir un gestionnaire de mot de passe comme Bitwarden est précisément de pouvoir avoir des mots de passe uniques. On en conclu que environ 30% des personnes ne comprennent pas pourquoi elles utilisent un gestionnaire de mot de passe.
Si ces personnes sont "obligées" car c'est un outil fourni par l'entreprise, alors l'employeur devrait investir un peu sur la sensibilisation et la formation… À ce niveau c'est du gâchis.
Posté par barmic 🦦 .
Évalué à 5 (+3/-0).
Dernière modification le 25 octobre 2024 à 00:16.
Dans l'une des universités où je travaille ils ont pas de SSO mais un LDAP ou quelque chose du genre ce qui fait que j'ai le même mot de passe sur une demi douzaine de sites et dans mon keepass ils sont liés via cette méthode (parce que ce serait un enfer sinon).
KeepassXC permet de faire une entrée « liée », c'est à dire que le mot de passe peut-être une référence vers le mot de passe d'une autre entrée.
Exemple :
Entrée « Portail SSO - identifiant : toto - mot de passe : test »
Entrée « Application - identifiant : - mot de passe : »
C'est pratique, une seule entrée à changer. Après, Bitwarden permet d'enregistrer autant d'URL qu'on veut pour une même entrée, donc ça peut faire aussi le travail.
C'est plutôt chouette (et normal) de centraliser les identités pour une structure comme une université. Si un jour cette université configure la couche SSO, ce sera d'autant plus simple pour les utilisateurs ! Et ça pourrait permettre une meilleurs acceptation de la double authentification, puisqu'elle ne se ferait qu'une fois pour des dizaines de sites/services.
Il me semble que cette analyse loupe un point critique sur ce genre de systèmes : le fait que le serveur bitwarden vient avec un client web installé au même endroit que la BDD (si j'en crois cette image tirée de la documentation. L'attaquant qui contrôle le serveur peut modifier le client web et servir un code JS qui, en plus de dériver le mot de passe pour déchiffrer le coffre, pourrait l'envoyer à l'attaquant.
Ça compromet le mot de passe de tous ceux qui utilisent le client web pendant que l'attaquant contrôle le serveur. Ceux qui utilisent uniquement les clients lourds sont à l'abri, tant qu'ils ne téléchargent pas le client depuis le serveur compromis.
L'article se concentre uniquement sur les conséquences d'une fuite de données du serveur, par exemple si la BDD ou une sauvegarde est accédée par l'attaquant.
Je pense que bien peu de gens utilisent l'interface web proposée par le serveur. C'est pas pratique, tout simplement, à part pour quelques tâche de maintenance.
Tout le monde utilise le plugin pour navigateur, et/ou l'application pour téléphone.
Faut arrêter avec cette dénomination de clients lourds quand ce qu'il y a souvent de plus lourd sur un pc aujourd'hui, ce sont les pages ouvertes sur le navigateur.
L'attaquant qui contrôle le serveur peut modifier le client web et servir un code JS qui, en plus de dériver le mot de passe pour déchiffrer le coffre, pourrait l'envoyer à l'attaquant.
En effet, ça semble logique. L'attaquant devrait même en profiter pour récupérer les secrets encore chiffrés au passage, car si le compte est protégé par de la double authentification, alors il ne pourra pas les récupérer plus tard via l'API web.
Ceux qui utilisent uniquement les clients lourds sont à l'abri, tant qu'ils ne téléchargent pas le client depuis le serveur compromis.
Par contre, je ne comprend pas bien pourquoi cela protège d'utiliser le client lourd : pour récupérer le coffre et pouvoir l'utiliser avec ledit client, il faut s'authentifier, et donc envoyer son mot de passe (et son éventuel OTP) au serveur compromis au moins une première fois, non ?
Et il t'envoie ton coffre chiffré qu'il ne sait pas déchiffrer en principe. Normalement tu decorrele l'authentification sur le serveur de la passphrase maître des mots de passe
Normalement tu décorrèles l'authentification sur le serveur de la passphrase maître des mots de passe
Mmm. La différence que je vois, c'est qu'en effet, le mot de passe est dérivé et condensé dans tous les sens avant d'être envoyé au serveur. Donc dans le cas du client web chargé depuis un serveur compromis, on peut en effet voler le mot de passe "en clair" côté client, alors que dans le cas du client lourd, il reste sagement sur l'ordi sans possibilité de bricoler le code du client.
# La sécurité est un échec™
Posté par cg . Évalué à 4 (+2/-0).
Très chouette article.
Ce passage m'a fait bizarre :
L'intérêt d'avoir un gestionnaire de mot de passe comme Bitwarden est précisément de pouvoir avoir des mots de passe uniques. On en conclu que environ 30% des personnes ne comprennent pas pourquoi elles utilisent un gestionnaire de mot de passe.
Si ces personnes sont "obligées" car c'est un outil fourni par l'entreprise, alors l'employeur devrait investir un peu sur la sensibilisation et la formation… À ce niveau c'est du gâchis.
[^] # Re: La sécurité est un échec™
Posté par barmic 🦦 . Évalué à 5 (+3/-0). Dernière modification le 25 octobre 2024 à 00:16.
Dans l'une des universités où je travaille ils ont pas de SSO mais un LDAP ou quelque chose du genre ce qui fait que j'ai le même mot de passe sur une demi douzaine de sites et dans mon keepass ils sont liés via cette méthode (parce que ce serait un enfer sinon).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La sécurité est un échec™
Posté par Glandos . Évalué à 3 (+1/-0).
KeepassXC permet de faire une entrée « liée », c'est à dire que le mot de passe peut-être une référence vers le mot de passe d'une autre entrée.
Exemple :
Entrée « Portail SSO - identifiant : toto - mot de passe : test »
Entrée « Application - identifiant : - mot de passe : »
C'est pratique, une seule entrée à changer. Après, Bitwarden permet d'enregistrer autant d'URL qu'on veut pour une même entrée, donc ça peut faire aussi le travail.
[^] # Re: La sécurité est un échec™
Posté par cg . Évalué à 2 (+0/-0).
C'est plutôt chouette (et normal) de centraliser les identités pour une structure comme une université. Si un jour cette université configure la couche SSO, ce sera d'autant plus simple pour les utilisateurs ! Et ça pourrait permettre une meilleurs acceptation de la double authentification, puisqu'elle ne se ferait qu'une fois pour des dizaines de sites/services.
# Compromission de l'appli web : un oubli?
Posté par Samuel (site web personnel) . Évalué à 3 (+2/-0).
Il me semble que cette analyse loupe un point critique sur ce genre de systèmes : le fait que le serveur bitwarden vient avec un client web installé au même endroit que la BDD (si j'en crois cette image tirée de la documentation. L'attaquant qui contrôle le serveur peut modifier le client web et servir un code JS qui, en plus de dériver le mot de passe pour déchiffrer le coffre, pourrait l'envoyer à l'attaquant.
Ça compromet le mot de passe de tous ceux qui utilisent le client web pendant que l'attaquant contrôle le serveur. Ceux qui utilisent uniquement les clients lourds sont à l'abri, tant qu'ils ne téléchargent pas le client depuis le serveur compromis.
L'article se concentre uniquement sur les conséquences d'une fuite de données du serveur, par exemple si la BDD ou une sauvegarde est accédée par l'attaquant.
[^] # Re: Compromission de l'appli web : un oubli?
Posté par Christophe . Évalué à 2 (+0/-0).
Je pense que bien peu de gens utilisent l'interface web proposée par le serveur. C'est pas pratique, tout simplement, à part pour quelques tâche de maintenance.
Tout le monde utilise le plugin pour navigateur, et/ou l'application pour téléphone.
Ceci dit la remarque reste valide j'imagine.
[^] # Re: Compromission de l'appli web : un oubli?
Posté par Psychofox (Mastodon) . Évalué à 6 (+4/-1).
Faut arrêter avec cette dénomination de clients lourds quand ce qu'il y a souvent de plus lourd sur un pc aujourd'hui, ce sont les pages ouvertes sur le navigateur.
[^] # Re: Compromission de l'appli web : un oubli?
Posté par cg . Évalué à 2 (+0/-0).
En effet, ça semble logique. L'attaquant devrait même en profiter pour récupérer les secrets encore chiffrés au passage, car si le compte est protégé par de la double authentification, alors il ne pourra pas les récupérer plus tard via l'API web.
Par contre, je ne comprend pas bien pourquoi cela protège d'utiliser le client lourd : pour récupérer le coffre et pouvoir l'utiliser avec ledit client, il faut s'authentifier, et donc envoyer son mot de passe (et son éventuel OTP) au serveur compromis au moins une première fois, non ?
[^] # Re: Compromission de l'appli web : un oubli?
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Et il t'envoie ton coffre chiffré qu'il ne sait pas déchiffrer en principe. Normalement tu decorrele l'authentification sur le serveur de la passphrase maître des mots de passe
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Compromission de l'appli web : un oubli?
Posté par cg . Évalué à 2 (+0/-0).
Mmm. La différence que je vois, c'est qu'en effet, le mot de passe est dérivé et condensé dans tous les sens avant d'être envoyé au serveur. Donc dans le cas du client web chargé depuis un serveur compromis, on peut en effet voler le mot de passe "en clair" côté client, alors que dans le cas du client lourd, il reste sagement sur l'ordi sans possibilité de bricoler le code du client.
J'ai bien compris cette fois ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.