La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: Marin le 19 octobre 2013 à 15:05:10
-
Un petit récapitulatif pour les deux FAIs auxquels j'ai été abonné récemment :
Free
- Mots de passe limités à 16 caractères (8 caractères il y a peu (http://www.freenews.fr/spip.php?article11739)).
- Au niveau des caractères autorisés, je ne me souviens plus mais je ne crois pas que ce soit très brillant non plus.
- Mots de passe renvoyés en clair par e-mail en cas d'oubli...
- Donc pas hashés dans la base de données.
- Cookie de session transmis directement dans l'URL, je suppose qu'ils ignorent l'existence d'un header HTTP dédié.
- Et pour couronner le tout, l'interface n'a pas été disponible en HTTPS avant de nombreuses années : il a fallu attendre mars 2010 (http://www.freenews.fr/spip.php?article7955) pour avoir un peu de sécurité à ce niveau.
SFR
- Mots de passe limités à 16 caractères.
- Caractères alphanumériques uniquement.
- Ces limitations indiquent qu'ils ne sont très probablement pas hashés, surtout que si sur certaines pages il y a un message d'avertissement (https://pbs.twimg.com/media/BW8FYFVIQAEX9S5.png:large) qui s'affiche, il me semble que le mien avait été tronqué silencieusement.
- Certains d'entre vous ont sûrement entendu parler de la fameuse protection contre les injections SQL (http://sebsauvage.net/files/20130127_sfr_business_sql_security.jpg) de SFR Business Team ?
Et vous, comment est-ce que votre FAI traite vos mots de passe ?
-
chez orange c'est plus simple dès que tu es connecté sur une livebox et que tu passe sur un site orange tu es automatiquement connecté sur l'espace client du proprio de la livebox!
bref ici même pas besoin de regarder la sécurité il n'y en a pas!
-
16 caractères seulement avec des contraintes a la noix alors que les passphrases sont plus surs.
Pour reprendre un classique:
(http://imgs.xkcd.com/comics/password_strength.png)
-
j'ai toujours apprécié l'utilisation des phrases (et mots multiples) en mots de passes (même si on est limité en nombre de caractère)
mais en pratique, cela ne change pas grand chose point de vue sécurité, les gens ont de toute façon une très mauvaise imagination
il faut démocratiser la double authentification (le token+pin, j'imagine que c'est ce que fait orange, avec la livebox en guise de token, mais je ne l'ai pas étudié), mon espoir étant l'initiative browserID de firefox, un gros plus en sécurité (certes imparfait, cela ne leur sera jamais) avec un bénéfice en expérience utilisateur, soit le contraire de ce que certains "experts sécurité" vendent
c'est gagnant gagnant
-
Sans même parler des FAI,
- combien d'entre vous utilisent une authentification forte dans leur travail ?
- Combien en ont déjà vu une en application ?
- Combien savent de quoi je parle ?
-
Free
- Mots de passe limités à 16 caractères (8 caractères il y a peu (http://www.freenews.fr/spip.php?article11739)).
- Au niveau des caractères autorisés, je ne me souviens plus mais je ne crois pas que ce soit très brillant non plus.
Je me souviens que des personnes qui avaient mis des caractères accentués avaient eu des problèmes en migrant sous Zimbra.
Même si des caractères non ASCII sont autorisés, ce n'est donc pas forcèment une bonne idée.
- Mots de passe renvoyés en clair par e-mail en cas d'oubli...
- Donc pas hashés dans la base de données.
Cela ne concerne que le mot de passe de compte ADSL ou accès gratuit ou compte email additionnel (mot de passe "principal"). Par contre le mot de passe FTP spécifique (si différent du MdP principal) d'un site perso lui est haché.
- Et pour couronner le toutwww, l'interface n'a pas été disponible en HTTPS avant de nombreuses années : il a fallu attendre mars 2010 (http://.freenews.fr/spip.php?article7955) pour avoir un peu de sécurité à ce niveau.
Ni POP/S, ni IMAP/S jusqu'à relativement récemment : Yohan (administrateur Zimbra et pages perso) considérait que SSL n'est utile que pour les usages pros! (véridique, ça ne s'invente pas)
-
Et l'ensemble du personnel de Free a accès facilement aux mot de passe, cela s'affiche sur les fiches client en clair sans faire de demande particulière, a coté du nom / prénom / adresse postale / adresse mail.
Les données bancaires sont plus sécurisées.
-
Sans même parler des FAI,
- combien d'entre vous utilisent une authentification forte dans leur travail ?
- Combien en ont déjà vu une en application ?
- Combien savent de quoi je parle ?
Une clé RSA pour mon VPN c'est bon ? (en plus d'un login/mdp)
Sinon ce n'est pas de l'authentification forte mais j'ai du Sophos Truecrypt sur mon disque dur pour éviter qu'il soit trop facilement lisible.
-
Une clé RSA ça tombe dans la catégorie "semi-forte" car la clé n'est "physiquement" pas protégée. Si tu la perds, on peut potentiellement s'en servir. Pour certains ayatollah ça n'est même pas du semi-fort, ça renforce juste ton mot de passe.
Mon post avait juste pour but de montrer que la prise en compte de la sécurité des accès est encore assez peu répandue. Je trouve assez malsain de la part des FAI de ne pas tenir le bon discours auprès du grand public. Mais ça ne choque personne vu qu'au niveau des entreprises le travail est encore énorme en matière de sensibilisation à la sécurité.
-
Les données bancaires sont plus sécurisées.
Qu'est-ce qu'on peut faire avec un RIB?
-
Mon post avait juste pour but de montrer que la prise en compte de la sécurité des accès est encore assez peu répandue. Je trouve assez malsain de la part des FAI de ne pas tenir le bon discours auprès du grand public.
Pareil!
Comme l'interface "sécurisée" de SFR :
https://lafibre.info/cryptographie/securisation-http-chez-sfr/
(https://lafibre.info/images/altice/201310_chat_sfr_ftth_1gb.png)
-
SFR
- Mots de passe limités à 16 caractères.
- Caractères alphanumériques uniquement.
- Ces limitations indiquent qu'ils ne sont très probablement pas hashés, surtout que si sur certaines pages il y a un message d'avertissement (https://pbs.twimg.com/media/BW8FYFVIQAEX9S5.png:large) qui s'affiche, il me semble que le mien avait été tronqué silencieusement.
Je ne vois pas du tout en quoi cela indiquerait une telle chose!
- Certains d'entre vous ont sûrement entendu parler de la fameuse protection contre les injections SQL (http://sebsauvage.net/files/20130127_sfr_business_sql_security.jpg) de SFR Business Team ?
(http://sebsauvage.net/files/20130127_sfr_business_sql_security.jpg)
Belle approche de la sécurité.
Il faudrait plus de panneaux :
- "Intrusion interdite"
- "Interdit de pirater"
- "Merci de n'utilisez que votre compte, pas celui d'un autre."
- "Ne cassez pas les mots de passe, merci d'avance."
-
Je ne vois pas du tout en quoi cela indiquerait une telle chose!
Si un mot de passe est limité à 16 caractères maximum, ce qui est quand même une taille relativement réduite (l'utilisateur peut bien vouloir utiliser une passphrase ou quelque chose d'un peu plus long, ça ne gênera personne), il y a des chances que ce soit parce qu'il est stocké en clair dans un champ de base de données de taille fixe. Cette limitation n'aurait pas lieu d'être avec un hash qui resterait de la même taille même avec un mot de passe long.
La limitation aux caractères alphanumériques pourrait également être mise en rapport avec une limitation au niveau de l'encodage des données côté SGBD.
-
Si un mot de passe est limité à 16 caractères maximum, ce qui est quand même une taille relativement réduite (l'utilisateur peut bien vouloir utiliser une passphrase ou quelque chose d'un peu plus long, ça ne gênera personne), il y a des chances que ce soit parce qu'il est stocké en clair dans un champ de base de données de taille fixe. Cette limitation n'aurait pas lieu d'être avec un hash qui resterait de la même taille même avec un mot de passe est long.
La limitation aux caractères alphanumériques pourrait également être mise en rapport avec une limitation au niveau de l'encodage des données côté SGBD.
Est-ce que les autres données choisies par l'utilisateur sont limitées de la même façon?
-
Une clé RSA ça tombe dans la catégorie "semi-forte" car la clé n'est "physiquement" pas protégée.
C'est simple : est-ce que tu peux te servir d'une clé RSA sur un PC en accès libre (ou simplement partagé et risquant particulièrement d'être compromis), en limitant la fenêtre de vulnérabilité dans le temps?
Non, si le PC est compromis quand tu utilises ta clef, que tu as stockée sur une mémoire de masse USB, alors elle peut être copiée et utilisée sans que tu le saches, tant que tu ne changes pas la clé (ce que tu n'as aucune raison de faire puisqu'on ne t'a rien pris).
Alors que si tu utilises un authentifiant USB "sécurisé", qui stocke ta clé mais la révèle pas, sur une machine compromise, l'accès n'est pas définitivement utilisable; seule la session que tu as lancée peut être piratée.
Si tu la perds, on peut potentiellement s'en servir. Pour certains ayatollah ça n'est même pas du semi-fort, ça renforce juste ton mot de passe.
Si tu perds une carte, tu peux faire quelque chose.
Si une clé est recopiée, tu ne peux rien faire tant que tu ne t'aperçois pas d'accès anormaux. D'où l'utilité de la mention "last login at hh:mm jj/mm/aaaa from i.p.ad.ress"
-
Euh, on parle des mêmes "clé RSA" ? Parce que chez moi c'est 6 chiffres qui changent toutes les 15 secondes, rien d'USB ou que sais-je !
-
Ah on parlait de systèmes OTP?
Moi, je parlais de chiffrement RSA.
-
Je parlais donc de ça :
(http://img.maxisciences.com/rsa/les-cles-de-cryptage-publiques-rsa-seraient-defaillantes_42653_w250.jpg)
-
Ce sont bien les gadgets qui ont été massivement compromis lorsque la base de données de RSA a été piratée?
-
Dommage j'ai loupé le créneau des 15s.... (tiens c'est pas 30s d'ailleurs ? faut que je regardes le mien....)
Par authentification forte, je parlais d'une carte à puce associée à une PKI. Si tu perds la carte, on ne peut rien en faire (en dehors du pouvoir fanstasmatique de la NSA).
-
Ce sont bien les gadgets qui ont été massivement compromis lorsque la base de données de RSA a été piratée?
Pas le gadget en lui-meme, la PKI qui permet de retrouver l'algo de génération de codes (tiens d'ailleurs est-ce que ça s'appelle une PKI le truc central de RSA ???)
-
Dommage j'ai loupé le créneau des 15s.... (tiens c'est pas 30s d'ailleurs ? faut que je regardes le mien....)
C'est ptet 30sec, j'ai pas vérifié ;)
Par authentification forte, je parlais d'une carte à puce associée à une PKI. Si tu perds la carte, on ne peut rien en faire (en dehors du pouvoir fanstasmatique de la NSA).
Mais là c'est pareil, si je perds la clé on ne peut rien en faire, manque encore des données pour s'en servir.
-
Pas le gadget en lui-meme, la PKI qui permet de retrouver l'algo de génération de codes (tiens d'ailleurs est-ce que ça s'appelle une PKI le truc central de RSA ???)
Je ne vois pas bien ce que "PKI" vient faire avec les OTP de RSA!
C'est juste un générateur pseudo aléatoire, il n'y pas de clé publique.
-
Ce que je veux dire que sur ton token on "voit" le code.
Sur une carte à puce, il faut un mot de passe pour pouvoir lui parler.
Pour les ayatollah ça fait une grosse différence.
-
Est-ce que les autres données choisies par l'utilisateur sont limitées de la même façon?
Je ne sais pas encore (il faut apparemment 1h pour que les modifications soient visibles dans l'espace client, j'ignore pourquoi), par contre, je peux lire :
L'adresse email de secours est l'adresse à laquelle nous vous enverrons votre mot de passe en cas d'oubli.
Je suppose que ça répond à la question du hashage du mot de passe.
-
Je ne vois pas bien ce que "PKI" vient faire avec les OTP de RSA!
C'est juste un générateur pseudo aléatoire, il n'y pas de clé publique.
Le générateur utilise une suite basé sur un algo de chiffrement.
-
Le générateur utilise une suite basé sur un algo de chiffrement.
Oui, très certainement.
(Un algo qui n'a rien à voir avec RSA.)
-
Par authentification forte, je parlais d'une carte à puce associée à une PKI. Si tu perds la carte, on ne peut rien en faire (en dehors du pouvoir fanstasmatique de la NSA).
Où tu entres le mot de passe? ;)
-
Pour les ayatollah ça fait une grosse différence.
J'en doute pas, après le code généré ne suffit pas. Même associé au login il faut la seconde moitié du password qui est un mdp "classique".
-
J'en doute pas, après le code généré ne suffit pas. Même associé au login il faut la seconde moitié du password qui est un mdp "classique".
Mdp qui peut être capturé!
-
Free
- Cookie de session transmis directement dans l'URL, je suppose qu'ils ignorent l'existence d'un header HTTP dédié.
L'ID de session est dans l'URL; quel est au juste le problème?
En quoi un cookie de session est une bonne chose?
-
L'ID de session est dans l'URL; quel est au juste le problème?
Si je ne m'abuse, il suffit par exemple que quelqu'un partage une URL de la console d'administration, et laisse l'ID de session (https://www.google.fr/search?q=%22console.pl?id=%22) par mégarde ou par ignorance de sa fonction, pour que le compte soit compromis...
La navigation est moins également moins pratique, par exemple si on utilise plusieurs onglets, ou bien qu'on retourne en arrière dans l'historique du navigateur, et que la session expire, le site risque de demander de se reconnecter une nouvelle fois et de créer plusieurs sessions indépendantes inutilement même si on vient juste de le faire.
-
Si je ne m'abuse, il suffit par exemple que quelqu'un partage une URL de la console d'administration, et laisse l'ID de session (https://www.google.fr/search?q=%22console.pl?id=%22) par mégarde ou par ignorance de sa fonction, pour que le compte soit compromis...
Oui, mais en principe il n'y a pas de raison que quelqu'un partage URL de la console, s'il a un minimum de logique.
Comme le délai d'expiration est extrêmement court, cela limite ce problème.
La navigation est moins également moins pratique, par exemple si on utilise plusieurs onglets, ou bien qu'on retourne en arrière dans l'historique du navigateur, et que la session expire, le site risque de demander de se reconnecter une nouvelle fois et de créer plusieurs sessions indépendantes inutilement même si on vient juste de le faire.
C'est surtout le délai d'expiration extrêmement court qui est un problème; en voulant programmer un enregistrement à distance, je me fais très souvent déconnecter.
-
Oui, mais en principe il n'y a pas de raison que quelqu'un partage URL de la console, s'il a un minimum de logique.
Si la personne ignore le fonctionnement du système de sessions de Free.fr, elle peut bien copier le lien dans une discussion pour montrer de quoi elle parle sans y voir de problème...
Comme le délai d'expiration est extrêmement court, cela limite ce problème.
Limite mais pas résout, si le lien est posté sur un chan IRC très fréquenté par exemple, il y a quand même des chances que quelqu'un s'amuse avec rapidement.
Et puis, si j'en crois l'assistance Free (https://www.free.fr/assistance/314.html) :
Saisissez deux fois votre nouveau mot de passe qui doit comporter entre six et huit caractères alphanumériques puis validez.
Il suffit de taper un nouveau mot de passe pour le changer ? Pas besoin de taper le mot de passe actuel ? Si c'est bien le cas, une personne malveillante pourrait prendre le contrôle du compte en s'affranchissant de cette limitation temporelle je suppose.
C'est surtout le délai d'expiration extrêmement court qui est un problème; en voulant programmer un enregistrement à distance, je me fais très souvent déconnecter.
Je trouvais ça assez embêtant aussi. Si j'utilisais la console de gestion plus souvent, j'aurais certainement créé un userscript pour me reconnecter automatiquement dans ce genre de situation.
-
Si la personne ignore le fonctionnement du système de sessions de Free.fr, il peut bien copier le lien dans une discussion pour montrer de quoi il parle sans y voir de problème...
Si je poste une URL, c'est bien que je pense que mon interlocuteur peut y avoir accès, et que je veux qu'il y ait accès.
Limite mais pas résout, si le lien est posté sur un chan IRC très fréquenté par exemple, il y a quand même des chances que quelqu'un s'amuse avec rapidement.
Il y a un risque en effet
Il suffit de taper un nouveau mot de passe pour le changer ? Pas besoin de taper le mot de passe actuel ? Si c'est bien le cas, une personne malveillante pourrait prendre contrôle du compte en s'affranchissant de cette limitation temporelle je suppose.
Je ne comprends pas.
Je trouvais ça assez embêtant aussi. Si j'utilisais la console de gestion plus souvent, j'aurais certainement créé un userscript pour me reconnecter automatiquement dans ce genre de situation.
J'utilisais la fonction "actualiser toutes les minutes".
-
Si je poste une URL, c'est bien que je pense que mon interlocuteur peut y avoir accès, et que je veux qu'il y ait accès.
Qu'il y ait accès mais pas forcèment avec mon compte.
Si un système de cookie était utilisé (ce qui est le cas sur la grande majorité du web) alors ce problème ne se poserait pas, or l'utilisateur lambda peut croire à un fonctionnement par cookie s'il ignore comment fonctionne la console de gestion Free et ce que signifient les paramètres dans l'URL.
Je ne comprends pas.
Si la personne malveillante accède au lien avant son expiration, il semblerait qu'elle puisse changer le mot de passe, et ainsi pouvoir se reconnecter indéfiniment en cas d'expiration.
-
Qu'il y ait accès mais pas forcèment avec mon compte.
Ah d'accord, elle pourrait penser qu'à cette adresse chacun accède à son propre compte.
Si la personne malveillante accède au lien avant son expiration, il semblerait qu'elle puisse changer le mot de passe, et ainsi pouvoir se reconnecter indéfiniment en cas d'expiration.
Si elle fait cela, elle révèle le fait qu'elle a piraté le compte.
Elle a plutôt intérêt à récupérer le mot de passe actuel!
-
Où tu entres le mot de passe? ;)
Ben via le lecteur de carte à puce connecté à ton PC ? (pas compris si c'était une question ou une boutade ?)
-
Je ne vois pas bien ce que "PKI" vient faire avec les OTP de RSA!
C'est juste un générateur pseudo aléatoire, il n'y pas de clé publique.
un générateur pseudo aléatoire avec des failles
https://en.wikipedia.org/wiki/NIST_SP_800-90A
PI
-
Mon opinion de RSA vient encore de baisser!
(Elle n'était déjà pas très haute.)
-
Par authentification forte, je parlais d'une carte à puce associée à une PKI. Si tu perds la carte, on ne peut rien en faire (en dehors du pouvoir fanstasmatique de la NSA).
En même temps quand on voit ce que certains arrivent à faire (ici (https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Nohl/BlackHat-Japan-08-Nohl-Secret-Algorithms-in-Hardware.pdf) et ici (http://events.ccc.de/camp/2011/Fahrplan/attachments/1888_SRLabs-Reviving_Smart_Card_Analysis.pdf)) avec une carte a puce, il y a de quoi être inquiet.
-
En même temps quand on voit ce que certains arrivent à faire (ici (https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Nohl/BlackHat-Japan-08-Nohl-Secret-Algorithms-in-Hardware.pdf) et ici (http://events.ccc.de/camp/2011/Fahrplan/attachments/1888_SRLabs-Reviving_Smart_Card_Analysis.pdf)) avec une carte a puce, il y a de quoi être inquiet.
Intéressant mais sur la partie carte à puce + module HSM ça reste très théorique. Avec des SI, on fait ce qu'on veut.