Filtrage IP

Gloops devait dire quelque chose comme ceci :

[protocole de cryptage]

Mon raisonnement, c'était que si on utilise quelque chose de tout prêt,
un pirate avait eu tout loisir d'étudier comment ça fonctionne ?

Qu'il sache comment ça fonctionne ne signifie pas qu'il puisse le
contourner. Les sources d'OpenSSH sont publiques depuis le début et
cela reste pourtant l'un des protocoles de cryptage de connexion parmis
les plus robuste qui soit.
Ce n'est pas parce que c'est connu sur le bout des doigts que ce n'est
pas sur.

Par ailleurs, est-ce qu'il y a moyen que ça ne coûte pas les yeux de la
tête ?

Evidement. Là aussi, ce n'est pas parce que c'est gratuit que ce n'est
pas sérieux. En fait, j'aurais même tendance à dire que c'est le
contraire. Je fait plus confiance à un programme de cryptage open
source ou libre, utilisé depuis des années, qu'à un programme
propriétaire dont personne ne sait rien et qui en plus pourrait coûter
la peau du cul. Tout simplement parce que le premier est étudié par des
centaines de professionnels qui peuvent à tout instant trouver une
faille et qui peuvent en prime comprendre pourquoi elle existe et
comment la combler. En plus tout le monde peut vérifier
qu'effectivement la faille a été comblée. Bref dans le cas présent la
transparence offerte par l'open source et le libre est un gage de
sécurité.

--
17/06/1969 - 18/01/2011

Repose en paix mon amour :'(

Stéphane Catteau , dans le message <mn.73e17dd34c1a2131.30736@sc4x.org>,
a écrit :

Si c'est parce que l'adresse sert de login, il suffit que tu la
stockes sous forme d'un hash. Elle restera utilisable pour sa fonction
de login, mais ne sera pas exploitable si ta base de donnée est
compromise. Attention toutefois, là tu dois utiliser un grain de sel,
parce que MD5 est de plus en plus fragilisé par les collisions connues.
Il reste irreversible (l'adresse e-mail est donc protégée), mais il
serait alors possible de pirater le compte en utilisant une valeur de
collision pour s'identifier, ce qui n'est pas possible si tu utilise un
grain de sel.

Il y a deux erreurs dans ce paragraphe.

D'une part, on est à ma connaissance encore loin d'attaques en préimage
efficaces contre MD5.

D'autre part, un login n'est pas quelque chose de confidentiel, donc un
collision, ou même une préimage, ne serait pas un problème. C'est le mot de
passe qui est confidentiel, et là il faut évidemment utiliser un haché avec
du sel. De préférence une implémentation standardisée et cryptanalysée, par
exemple crypt() avec un sel en $6 pour utiliser SHA-512.

Si c'est parce que tu veux pouvoir envoyer un mail en cas de perte du
mot de passe, ou que tu veux pouvoir contacter la personne pour
d'autres raisons, là c'est beaucoup plus compliqué.

Pour pouvoir envoyer un mail en cas de perte du mot de passe, c'est très
facile : il suffit de re-demander l'adresse mail à l'utilisateur et de la
comparer au haché.

Une autre possibilité, perverse, est de doubler les données.
C'est-à-dire que tu as bien un champ "adresse e-mail" dans la table
contenant les données utilisateurs, mais avec des données aléatoires.
Le pirate croira avoir a faire à des données cryptées et ne cherchera
pas les vraies données qui sont situées dans une autre table.

Mouarf.

Gloops n'était pas loin de dire :

Mon raisonnement, c'était que si on utilise quelque chose de tout prêt,
un pirate avait eu tout loisir d'étudier comment ça fonctionne ?

En crypto bien conçue, la sécurité repose totalement sur la clef, et
absolument pas sur l'algorithme.

A priori, si on dit qu'il faut crypter la chaîne de connexion dans le
fichier de config,

Ah, au temps pour moi. Tu parles de ta connexion à toi en tant
qu'admin, genre ta clé privée, c'est ça ?

c'est qu'on part du principe qu'un pirate va réussir à lire le fichier
de config (première anomalie à la base, mais admettons). Où est-ce
qu'on mettrait bien la clef pour qu'elle, au moins, échappe au pirate ?

La quasi totalité des admins que je connais stockent leurs clés
privées dans le bon vieux ~/.ssh et en sont satisfait. Mais si vraiment
tu es paranoïaque tu peux aussi la mettre sur une clé USB, elle n'est
alors vulnérable qu'au moment où tu l'utilises. Et si tu es vraiment
extrèmement paranoïaque, tu la stockes sur une clé USB cryptée avec le
logiciel de décryptage sur ton ordinateur, comme ça il faut faire plus
que te voler la clé pour pouvoir l'utiliser.
Mais bon, je répète que la quasi totalité des admins se contente du
bon vieux ~/.ssh et de la confiance qu'ils ont dans la sécurité de leur
propre machine.

--
17/06/1969 - 18/01/2011

Repose en paix mon amour :'(

Nicolas George n'était pas loin de dire :

Il y a deux erreurs dans ce paragraphe.

D'une part, on est à ma connaissance encore loin d'attaques en préimage
efficaces contre MD5.

Ta connaissance à besoin d'être mise à jour. Je pensais cela aussi en
2011, jusqu'à ce qu'Ankama se fasse dumper la base de données des
clients de leur jeu Dofus. Il y a eu tellement de comptes compromis
parce qu'ils ne mettaient pas de grain de sel pour stocker le hash MD5
des mots de passe, qu'ils ont été obligé de forcer eux-mêmes le
changement de mot de passe de l'ensemble de leurs clients.
Une fois que tu as le hash, il suffit de demander à Google, ce ne sont
pas les sites publiants les collisions trouvées qui manquent. Et si tu
préfère un site unique, http://md5.noisette.ch/.
Je t'accorde que toutes les collisions ne sont pas encore connues,
mais j'ai fait dix essais avec le site que je donne. Sur dix hash
générés au hasard, et il m'a trouvé une collision pour quatre d'entre
eux. L'échantillon est trop faible pour avoir une réelle valeur
statistique, mais pour ma part même s'il n'avait trouvé qu'une seule
collision sur ces dix essais, ce serait suffisant pour justifier
l'emploie systématique d'un grain de sel.

D'autre part, un login n'est pas quelque chose de confidentiel, donc un
collision, ou même une préimage, ne serait pas un problème.

Dans l'absolue je suis d'accord avec toi, protéger un login ne sert
strictement à rien. Mais tu as apparament oublié la raison de cette
discussion, à savoir que Gloops veut protéger les adresses e-mail de
ses utilisateurs. Dès lors que cette adresse serait utilisée en tant
que login (ce qui est très répandu) le seul moyen de la protéger c'est
de crypter aussi le login.


[snip]

Pour pouvoir envoyer un mail en cas de perte du mot de passe, c'est très
facile : il suffit de re-demander l'adresse mail à l'utilisateur et de la
comparer au haché.

Euh oui, pourquoi je l'ai pas vu tout de suite ? :/

Une autre possibilité, perverse, est de doubler les données.
C'est-à-dire que tu as bien un champ "adresse e-mail" dans la table
contenant les données utilisateurs, mais avec des données aléatoires.
Le pirate croira avoir a faire à des données cryptées et ne cherchera
pas les vraies données qui sont situées dans une autre table.

Mouarf.

Sauf à gérer un site hyper spécialisé, 99% des attaquant qu'il aura en
face de lui seront trop cons pour ne pas se faire avoir.

--
17/06/1969 - 18/01/2011

Repose en paix mon amour :'(

Stéphane Catteau , dans le message <mn.74057dd3932c8055.30736@sc4x.org>,
a écrit :

Une fois que tu as le hash, il suffit de demander à Google, ce ne sont
pas les sites publiants les collisions trouvées qui manquent. Et si tu
préfère un site unique, http://md5.noisette.ch/.

Ça ne sont pas vraiment des attaques en préimage.

Et en particulier, elles ne permettent de retrouver que des préimages qui
ont déjà, d'une manière ou d'une autre, été publiées sur le web.

Dans l'absolue je suis d'accord avec toi, protéger un login ne sert
strictement à rien. Mais tu as apparament oublié la raison de cette
discussion, à savoir que Gloops veut protéger les adresses e-mail de
ses utilisateurs. Dès lors que cette adresse serait utilisée en tant
que login (ce qui est très répandu) le seul moyen de la protéger c'est
de crypter aussi le login.

Oui mais non. Une attaque en préimage te donnera une chaîne qui peut être
utilisée comme login sur le site à la place de la vraie adresse mail (ce qui
n'est pas grave, puisque c'est un login, donc pas secret), mais pas
l'adresse mail d'origine.

Stéphane Catteau a écrit, le 14/03/2013 16:46 :

A priori, si on dit qu'il faut crypter la chaîne de connexion dans l e
fichier de config,

Ah, au temps pour moi. Tu parles de ta connexion à toi en tant
qu'admin, genre ta clé privée, c'est ça ?

Absolument

La quasi totalité des admins que je connais stockent leurs clés
privées dans le bon vieux ~/.ssh et en sont satisfait.

Sous Windows ça s'appelle comment, ça ?

Mais si vraiment
tu es paranoïaque tu peux aussi la mettre sur une clé USB, elle n'e st
alors vulnérable qu'au moment où tu l'utilises. Et si tu es vraimen t
extrèmement paranoïaque, tu la stockes sur une clé USB cryptée avec le
logiciel de décryptage sur ton ordinateur, comme ça il faut faire p lus
que te voler la clé pour pouvoir l'utiliser.

Hum, déjà, l'hébergeur ne veut pas me laisser accéder aux command es IIS,
en mutualisé, alors faire huit cents kilomètres pour aller insérer une
clef USB dans un port du serveur, je le sens assez moyen ...

A supposer qu'on me laisse entrer, ce qui n'a rien de garanti.

Mais bon, je répète que la quasi totalité des admins se content e du
bon vieux ~/.ssh et de la confiance qu'ils ont dans la sécurité de leur
propre machine.

Il s'agirait plutôt de la confiance dans l'hébergeur, en l'occurrence ,
non ? A moins d'avoir un serveur à la maison, avec une IP fixe et tout
le tremblement ? Il faut pouvoir suivre, derrière.

OK, ça rejoint ce que dit Nicolas, du coup j'ai répondu de l'autre cô té.

Enfin comme je crois j'ai évoqué quelque part, il y a quand même qu elque
chose qui m'échappe dans le raisonnement : ou l'accès aux répertoir es du
serveur est considéré comme fiable, et alors pourquoi crypter ? Ou il ne
l'est pas, et alors pourquoi mettre la clef de cryptage dedans ? Ou
c'est moi qui ai loupé une étape ?

Gloops a écrit, le 14/03/2013 18:44 :

Stéphane Catteau a écrit, le 14/03/2013 16:46 :

A priori, si on dit qu'il faut crypter la chaîne de connexion dans le
fichier de config,

Ah, au temps pour moi. Tu parles de ta connexion à toi en tant
qu'admin, genre ta clé privée, c'est ça ?

Absolument

Du moins la clef de cryptage pour la connexion à la base, oui.
En fait, pour se connecter à une base avec un mot de passe crypté, c' est
la clef publique, de cryptage, qu'on utilise, non ? La clef privée,
elle, est utilisée lors du cryptage, et par définition elle n'apparaî t
nulle part.

Mais là, peut-être que je pinaille ?

Nicolas George n'était pas loin de dire :

Une fois que tu as le hash, il suffit de demander à Google, ce ne sont
pas les sites publiants les collisions trouvées qui manquent. Et si tu
préfère un site unique, http://md5.noisette.ch/.

Ça ne sont pas vraiment des attaques en préimage.

Et en particulier, elles ne permettent de retrouver que des préimages qui
ont déjà, d'une manière ou d'une autre, été publiées sur le web.

Je n'ai pas dit le contraire, je me cite : "[...] MD5 est de plus en
plus fragilisé par les collisions connues."
Je n'ai pas dit que MD5 était vulnérable, mais qu'il était fragilisé,
et j'ai limité cette fragilité aux collisions connues.

Après c'est un débat plus philosophique que technique. Est-ce qu'un
algorithme de hachage peut encore être considéré comme robuste parce
que les centaines de milliers de collisions rendues publiques ne
représentent pas même un hash sur cent mille ?
Statistiquement parlant, les chances de tomber sur une collision sont
extrèmement faibles, je suis parfaitement d'accord avec toi sur ce
point. Mais humainement parlant, il me semble que c'est tout autre
chose, puisque la plus part des hash ayant une collision rendue
publique correspondent à des chaînes courtes, donc des mots de passe
potentiels.
Je maintiens donc ce que j'ai dit, sans ajout d'un grain de sel, la
confiance que j'accorde à MD5 est maintenant relativement faible pour
certains cas de figure. Je continue à l'utiliser largement pour un tas
de choses, y compris des données transitant par le réseau, mais plus
pour une chaine "élémentaire" (composée d'une seule donnée).
Utiliser un hash MD5 pour faire transiter un couple login/password ne
pose aucun problème, l'utiliser pour stocker un mot de passe (sans
grain de sel) est par contre sujet à caution.

[snip]

Oui mais non. Une attaque en préimage te donnera une chaîne qui peut
être utilisée comme login sur le site à la place de la vraie adresse
mail (ce qui n'est pas grave, puisque c'est un login, donc pas secret),
mais pas l'adresse mail d'origine.

C'est en fait le corrolaire de ce que je dis juste avant. La confiance
que j'accorde à MD5 étant maintenant faible, c'est devenu un réflexe ;
dès qu'il y a chaine "élémentaire", je rajoute un grain de sel. Mais tu
as raison, dans le cas présent c'est totalement inutile.
Cela dit (parce que je suis tetu, mais tu as du le remarquer) ça n'est
pas forcément une mauvaise habitude, cela évite de l'oublier le jour où
il est indispensable.

--
17/06/1969 - 18/01/2011

Repose en paix mon amour :'(

Nicolas George a écrit, le 14/03/2013 15:06 :

Gloops , dans le message <khsjpf$rdj$1@nntp.pasdenom.info>, a écrit :

C'est quoi, des « chaînes de connexion » ? Il faut les graisser
régulièrement, comme des chaînes de vélo ? Ça rend Charlot fou, comme les
chaînes de production dans _Les temps modernes_ ?

Il faut rire ?

C'est une option. Mais répondre à la question serait utile ?

Ah mais je croyais que tu plaisantais.
Tu fais comment une connexion à une base de données, toi ?
Tu n'as pas une chaîne de caractères qui contient le type de base, le
mot de passe, éventuellement le protocole ?

Évidemment, si wikipedia s'y met aussi, et répond Canalsat, eh bien
comme disait un chef de projet dont tu apprécieras l'élégance, "on n'a
pas le cul sorti des ronces".

http://www.trucsweb.com/ASP/trucs.asp?no=102&type=7

Euh, gnî ? Le mail de confirmation sert à activer le compte ; une f ois que
le compte est activé, il n'y a plus besoin de mail.

Ah, tu veux dire que tu conserves le pseudo et le mot de passe ?
C'est aussi une option, effectivement. Si on n'a pas de newsletter à
diffuser.