La sécurité de Bitly compromise, changez votre mot de passe

La sécurité de Bitly compromise, changez votre mot de passe

La valse des mots de passe

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

09/05/2014 2 minutes
13

La sécurité de Bitly compromise, changez votre mot de passe

Via son blog, Bitly indique que certaines données de ses comptes utilisateurs ont pu être compromises, sans plus de précisions pour le moment. La société ajoute avoir d'ores et déjà pris des mesures, notamment en déconnectant tous les utilisateurs de Facebook et de Twitter.

Bitly Securité

 

Décidément, c'est la saison des failles et de la fuite de données personnelles. Alors qu'Orange vient d'être de nouveau victime d'une intrusion, pour la deuxième fois en trois mois, c'est au tour de Bitly de faire part d'un problème de sécurité.

 

La société spécialisée dans le raccourcissement d'URL vient en effet de publier un message sur son blog afin de mettre en garde ses utilisateurs : « Nous avons des raisons de croire que des informations des comptes Bitly ont été compromises. Pour le moment, nous n'avons aucune indication confirmant que des comptes ont été consultés sans autorisation. Afin d'assurer la protection de nos utilisateurs, nous avons pris des mesures proactives, y compris avec la déconnexion pour tous les utilisateurs de Facebook et de Twitter ». Bitly précise que, même si vous voyez toujours Facebook et/ou Twitter rattachés à votre compte, il n'est plus possible de publier vers les réseaux sociaux à moins de se déconnecter, puis de se reconnecter.

 

Bitly Securité

 

La société demande également à ses utilisateurs de changer leur mot de passe et de réinitialiser leur clé API (dans Settings > Advanced > Show Legacy Key) qui est utilisée dans les applications tierces. Il est ensuite conseillé de se déconnecter de toutes les applications exploitant Bitly puis de se reconnecter. Pour rappel, vous pouvez consulter la liste de celles que vous avez autorisées via l'onglet Connected Accounts dans les paramètres.

13

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (13)


ça commence à être vraiment casse pied de devoir changer ses mots de passe tous les 4 matins sur plusieurs services, quand est ce que les services & entreprises vont enfin se décider à généraliser le chiffrement des mots de passe ? <img data-src=" />



A moins que ce soit contre leurs intérêts ? (Vérifier si l’user n’a pas le même login/mot de passe chez des concurrents, et récupérer quelques infos histoire de pouvoir cibler la pub & spammer…) <img data-src=" />

Y’a encore quelques années, j’aurais pu dire que c’est de la parano, mais avec tout ce qui nous est tombé dessus ces derniers temps… <img data-src=" />








bingo.crepuscule a écrit :



ça commence à être vraiment casse pied de devoir changer ses mots de passe tous les 4 matins sur plusieurs services, quand est ce que les services & entreprises vont enfin se décider à généraliser le chiffrement des mots de passe ? <img data-src=" />



A moins que ce soit contre leurs intérêts ? (Vérifier si l’user n’a pas le même login/mot de passe chez des concurrents, et récupérer quelques infos histoire de pouvoir cibler la pub & spammer…) <img data-src=" />

Y’a encore quelques années, j’aurais pu dire que c’est de la parano, mais avec tout ce qui nous est tombé dessus ces derniers temps… <img data-src=" />





Les paranos avaient en fait raison depuis le début. <img data-src=" />









bingo.crepuscule a écrit :



quand est ce que les services & entreprises vont enfin se décider à généraliser le chiffrement des mots de passe ? <img data-src=" />:





Le problème c’est que ça ne suffit pas… Car même des mots de passe chiffrés peuvent être déchiffrés, suffit de la puissance de calcul nécessaire.



Globalement, il faut surtout éviter de s’inscrire sur tout et n’importe quoi afin de limiter le problème et choisir des adresses électroniques “uniques” (genre [email protected] pour l’inscription à ce site) avec mot de passe unique. Et aussi éviter de donner date de naissance, adresse physique… à des sites qui n’en ont pas besoin !









bilbonsacquet a écrit :



Globalement, il faut surtout éviter de s’inscrire sur tout et n’importe quoi afin de limiter le problème et choisir des adresses électroniques “uniques” (genre [email protected] pour l’inscription à ce site) avec mot de passe unique. Et aussi éviter de donner date de naissance, adresse physique… à des sites qui n’en ont pas besoin !







Le problème avec ça c’est qu’on se retrouve vite avec une quantité industrielle d’adresses e-mails à conserver, avec autant de failles possibles.









lincruste_2_la vengeance a écrit :



Le problème avec ça c’est qu’on se retrouve vite avec une quantité industrielle d’adresses e-mails à conserver, avec autant de failles possibles.





Ou alors tu rediriges de multiples adresses email vers une principale comme ça le jour où tu en as une qui se fait spammer : 1- tu connais le fautif. 2- tu la clotures.









bilbonsacquet a écrit :



Globalement, il faut surtout éviter de s’inscrire sur tout et n’importe quoi afin de limiter le problème et choisir des adresses électroniques “uniques” (genre [email protected] pour l’inscription à ce site) avec mot de passe unique. Et aussi éviter de donner date de naissance, adresse physique… à des sites qui n’en ont pas besoin !









D’autant plus que certains fournisseurs permettent la création d’alias! :)

Et de cette manière tu sais qui a vendu ton adresse mail aux spammeurs.

PS : A ma connaissance, déchiffrer un mot de passe (autre que 123456) hashé correctement, c’est du domaine de l’impossible, ou du moins, pas faisable en un temps raisonnable.







bingo.crepuscule a écrit :



[…]quand est ce que les services & entreprises vont enfin se décider à généraliser le chiffrement des mots de passe ? <img data-src=" />





Pas forcement besoin d’avoir le mot de passe en clair pour récupérer des données ;)

D’ailleurs ce n’est précisé ni dans la news, ni dans le blog de bit.ly







Lordtoniok a écrit :



Ou alors tu rediriges de multiples adresses email vers une principale comme ça le jour où tu en as une qui se fait spammer : 1- tu connais le fautif. 2- tu la clotures.







Les alias sont tes amis ;)









Charly32 a écrit :



PS : A ma connaissance, déchiffrer un mot de passe (autre que 123456) hashé correctement, c’est du domaine de l’impossible, ou du moins, pas faisable en un temps raisonnable.





Tes connaissances sont erronées… Avec le “Cloud” et les fermes d’ordi zombies, c’est de l’ordre du possible, enfin dépend de la complexité du mot de passe et de / des algo de chiffrement.



Certains (tous à terme ?) algo sont vulnérables (bug ou faille volontaire, genre NSA & co).









Lordtoniok a écrit :



Ou alors tu rediriges de multiples adresses email vers une principale comme ça le jour où tu en as une qui se fait spammer : 1- tu connais le fautif. 2- tu la clotures.







Oui c’est ce que je disais: “une quantité industrielle d’e-mails à gérer avec autant de failles possibles.”









bilbonsacquet a écrit :



Le problème c’est que ça ne suffit pas… Car même des mots de passe chiffrés peuvent être déchiffrés, suffit de la puissance de calcul nécessaire.







C’est plutôt faux. En fait une société un tant soit peu responsable ne va pas stocker les mots de passe chiffrés, mais les hashs de mots de passe. Le principe d’une fonction de hachage est d’associer à une chaîne de bits une autre chaîne de bits, de façon déterministe (c’est une fonction), mais qui paraisse aléatoire : impossible à partir de h(x) de connaître x. En gros. Pour authentifier l’utilisateur, lorsque celui-ci entre un mot de passe x’, le système calcule h(x’) et compare avec le hash stocké sur ses serveurs : s’ils correspondent, c’est tout bon ; sinon l’authentification échoue.



C’est pour ça qu’une bonne fonction de hachage doit pouvoir résister aux collisions, càd que personne ne doit être en mesure d’exhiber x et y distincts tels que h(x) = h(y). Un adversaire ne doit pouvoir être authentifié que s’il entre effectivement le bon mot de passe, et pas un autre.

Stocker simplement le hash est encore une mesure trop faible, sensible aux attaques par dictionnaire (l’adversaire se crée une grande base de données de la forme (x, h(x)). Lorsqu’il chope un hash h sur le serveur, il cherche dans sa base s’il n’avait pas calculé un x tel que h = h(x) ; auquel cas l’adversaire a retrouvé le mdp). Des techniques de salage permettent de contrer ce type d’attaques.



Ces mesures sont connues depuis longtemps et pourtant certaines entreprises ne les mettent pas en place, alors qu’il ne me semble pas que ce soit particulièrement difficile… un bon exemple était Orange, qui il y a un an à peine, lorsque je le testais en prétendant oublier mon mdp, me renvoyait… mon mot de passe. C’est donc bien qu’il était stocké en clair sur leurs serveurs… et avec les news récentes je me demande s’ils ont changé ça depuis.



Cependant, les techniques de salage permettent surtout de contrer des attaques “pêche au filet” ; il reste toujours possible pour l’adversaire d’effectuer des attaques ciblées, et donc il sera toujours conseillé de changer son mot de passe en cas de fuite.



Un autre problème est que si l’adversaire parvient à s’installer sur le serveur cible, il pet sûrement avoir accès aux mots de passe en clair de tout utilisateur qui souhaite se connecter. Même en supposant que l’entreprise chiffre (un protocole à clé publique me semble le plus simple même si je ne sais pas si cela est viable en pratique en termes de complexité) les mots de passe lorsque ceux ci transitent depuis le terminal utilisateur jusqu’à ses serveurs, il faut bien le déchiffrer à un moment ou à un autre.









bilbonsacquet a écrit :



Tes connaissances sont erronées… Avec le “Cloud” et les fermes d’ordi zombies, c’est de l’ordre du possible, enfin dépend de la complexité du mot de passe et de / des algo de chiffrement.



Certains (tous à terme ?) algo sont vulnérables (bug ou faille volontaire, genre NSA & co).







Toujours de mémoire (et une recherche rapide google, je ne me suis pas attardé sur le sujet), le reverse d’un hash SHA est toujours basé sur du brute-force/dictionnaire.

Si effectivement, pour des mots de passes simple (lettres et chiffres uniquement) le reverse peut être calculé en 1 journée pour des mots de passes courts (source).

En se basant sur le même calcul, le réseau bitcoin ( ~70 000 000GH/s) pourrait déchiffrer un mot de passe 11 caractères ASCII (94 caractères possibles) en 1 journée.

Ca reste assez peu worth it, d’autant plus qu’il faudrait répéter l’opération pour chaque compte.









Charly32 a écrit :



Ca reste assez peu worth it, d’autant plus qu’il faudrait répéter l’opération pour chaque compte.





C’est sûr, sauf le jour où le SHA n’est plus valable car on aura trouvé comment le mettre en défaut.



Cela engendre aussi de devoir régulièrement changer la façon dont les hash sont générés en permettant la conversion sans devoir réinitialiser le mot de passe en question.



Enfin, une chose est sûre que oui, un développeur qui stocke dans son appli les mots de passe en clair devrait être écartelé vif <img data-src=" />









bilbonsacquet a écrit :



C’est sûr, sauf le jour où le SHA n’est plus valable car on aura trouvé comment le mettre en défaut.



Cela engendre aussi de devoir régulièrement changer la façon dont les hash sont générés en permettant la conversion sans devoir réinitialiser le mot de passe en question.







Tu n’as pas l’air de savoir de quoi tu parles.



“SHA” ne désigne plus un protocole mais une famille de protocoles aujourd’hui.



Mais surtout, on est loin, très loin, de devoir changer régulièrement de fonction de hachage. SHA-1, introduit en 1995, ne souffre que d’attaques (trouver des collisions, cf mon précédent message) encore assez théoriques (pas franchement applicables en pratique) 20 ans après. À cause de ces vulnérabilités cependant, il est conseillé de ne plus l’utiliser.

La sous-famille des SHA-2, introduite en 2001, ne connaît à l’heure actuelle aucune réelle attaque. Cependant, comme elle se base sur SHA-1, on craint qu’il y ait des vulnérabilités sous-jacentes, d’où la création de SHA-3, basée sur un schéma différent.



Bref, la durée de vie d’une fonction de hachage dépasse allègrement les 10 ans, au bas mot…

Alors la gestion d’un changement de fonction de hachage, honnêtement, c’est le cadet des soucis en sécurité <img data-src=" />









bilbonsacquet a écrit :



Le problème c’est que ça ne suffit pas… Car même des mots de passe chiffrés peuvent être déchiffrés, suffit de la puissance de calcul nécessaire.



Globalement, il faut surtout éviter de s’inscrire sur tout et n’importe quoi afin de limiter le problème et choisir des adresses électroniques “uniques” (genre [email protected] pour l’inscription à ce site) avec mot de passe unique. Et aussi éviter de donner date de naissance, adresse physique… à des sites qui n’en ont pas besoin !





C’est pour cela que les mots de passe ne sont pas chiffrés mais hashés.