Filtrage IP

Gloops devait dire quelque chose comme ceci :

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 ?

PuTTY vient avec un logiciel de gestion de clé dont le nom m'échappe.
Le contenu peut probablement être décrypté, mais de mémoire il se base
en partie sur des données uniques liées au système, il faut donc piquer
le fichier contenant les clés et arriver à lancer un programme
récupérant les données systèmes utilisées. Donc à mon sens le niveau de
sécurité est sensiblement équivalent à ~/.ssh.

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.

Hum, déjà, l'hébergeur ne veut pas me laisser accéder aux commandes 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 ...

J'ai du mal m'exprimer (ça semble récurent ces temps ci). Je me
plaçais dans l'optique d'une connexion avec un protocole
d'autentification clé publique/clé privée. C'est donc ta clé privée que
tu stockes sur une clé USB. Tu connectes donc ta clé USB à ton
ordinateur, ce qui te permet d'avoir accès à ta clé privée et de
t'autentifier.

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.

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.

Dans l'absolue, si tu as choisi cet hébergeur, c'est que tu as
confiance en lui. D'ailleurs dans l'absolue tu ne devrais même pas te
poser la question de l'autentification. Aussi rudimentaires qu'ils
puissent paraitre, les outils qu'il met à ta disposition sont fiables
et sécurisés. Après tout, il en va de sa réputation, donc de sa
clientèle et de sa pérénité en tant qu'entreprise commerciale.
Le seul point réellement faible ici, c'est ton propre ordinateur.
Admettons qu'il soit suffisement compromis pour qu'une personne soit en
mesure de récupérer les données que tu utilises pour te connecter aux
outils fournis par ton hébergeur. Ne crois-tu pas qu'il serait aussi
suffisement compromis pour qu'il récupère les données nécessaires au
protocole d'autentification que tu aurais toi-même mis en place ?

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

Repose en paix mon amour :'(

Gloops devait dire quelque chose comme ceci :

Enfin comme je crois j'ai évoqué quelque part, il y a quand même quelque
chose qui m'échappe dans le raisonnement : ou l'accès aux répertoires 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 ?

En matière de sécurité informatique, il n'existe rien qui soit fiable
à 100%. Tu n'as qu'à voir l'échange que j'ai avec Nicolas George
concernant MD5.
Dans l'absolue, l'accès à un répertoire est sur, mais lire des données
dans un répertoire tiers est de toutes les actions malveillantes
possibles, celle qui est la plus simple (relativement parlant
évidement). A titre d'exemple, il y a très très longtemps de cela, un
simple serveur HTTP permettait de parcourir l'ensemble d'un disque dur,
parce que les '/../' ne s'arrêtait pas à la racine du répertoire
utilisé par le serveur HTTP.
Le simple fait de mettre les données dans un répertoire n'est donc pas
une garantie suffisante en terme de sécurité. Utiliser un répertoire
caché (qui ne sera donc pas présenté dans la liste), un fichier caché,
crypter les données, et ainsi de suite, sont autant d'actions qui
augmentent le niveau de sécurité dans le cas où.

Pour prendre un exemple plus proche de la réalité quotidienne, il y a
quelques années de cela, des voleurs s'introduisaient de nuit dans les
maisons, prenaient les clés de la voiture et volaient la voiture.
Dans l'absolue, les clés étant dans ta maison, ta voiture est en
sécurité. Mais bon, mettre les clés dans un tiroir, au lieu de les
laisser posée sur la table basse à côté de la porte, augmente ton
niveau de sécurité. Si quelqu'un arrive à forcer ta porte, il faudra
encore qu'il trouve dans quel tiroir sont les clés.
Cela ne veut pas dire qu'il faille sombrer dans la paranoïa, mais
avoir toujours un minimum de deux niveaux de sécurité est une garantie
suplémentaire. Si le premier niveau est percé, ce qui est toujours
possible, le second est là pour te protéger.

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

Repose en paix mon amour :'(

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

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 ?

Donc tu parlais de la chaîne qui sert à décrire la connexion à la base de
données pour l'API que tu utilises. Ça n'avait rien d'évident.

É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".

Rien compris.

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

« SQL Server, Access, Oracle, BD2, Foxpro, MySQL, Excel... »

-> poubelle.

Ah, tu veux dire que tu conserves le pseudo et le mot de passe ?

Tu conserves ce que tu as besoin de conserver, dont un champ qui te dit si
le compte a été effectivement activé.

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

Gloops devait dire quelque chose comme ceci :

Mais crypter quoi ? :/

Les chaînes de connexion notamment.

Traduction littérale d'un "connection's strings" trouvé quelque p art ?
Tu parles des trucs du genre "/login.php?user=blabla&password=blibl i"
(je simplifie à l'extrème évidement) ?
Si oui, un bon vieux hash MD5 et hop. Normalement tu n'as même pas
besoin d'un grain de sel à ce niveau là.

Oui c'est bien ça. Tu notes le mot de passe en clair, c'est juste ça le
point qui fâche.
Bon alors je connais MD5 pour vérifier qu'il n'y ait pas d'erreur de
transmission, comme une preuve par 9. Mais es-tu capable de refournir le
texte originel à partir du MD5 ?

Je suis désolé pour tphilippet qui se contente de compter les points,
mais ... C'est quand même vrai que lorsqu'on collecte des adresses mail ,
en garantir la confidentialité fait partie des implications ...
Si j'ai soulevé le point, c'est que je l'ai appris à mes dépens, cô té
intervenant sur le forum.

La question que je cherchais à traiter était, "une fois qu'on a
encouragé les participants à fournir leur adresse e-mail pour pouv oir
écrire sur le forum, comment éviter de se faire pirater la base de
données, pour éviter que le lendemain les participants reçoivent du spam
sur l'adresse e-mail qu'ils viennent de fournir ?"

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éatoi res.
Le pirate croira avoir a faire à des données cryptées et ne cherc hera
pas les vraies données qui sont situées dans une autre table.

J'ai l'impression que voilà un certain nombre de bonnes idées qu'il f aut
prendre le temps d'exploiter pour se rendre compte.
Pour ce dernier point : un temps je me connectais sur usenet avec des
adresses email bidon et proclamées comme telles, mais un certain nombre
de personnes me sont tombées dessus en me disant que je n'avais pas de
garanties que ces adresses ne seraient pas utilisées un jour, auquel ca s
le nouveau propriétaire se retrouverait spammé à cause de cette
utilisation. ça paraissait au départ une bonne idée pour divertir l es
spammeurs, et puis finalement il n'y a pas unanimité dessus.

Oui enfin bon quoi. Il y a un an et demi, un jeu en ligne français
affichant plusieurs millions d'utilisateurs s'est fait trouer par une
injection SQL qui a dumpé toutes ses données clients. Et tous les
comptes utilisateurs se sont retrouvé vulnérables parce que les
identifiants étaient stockés sous forme de hash MD5 sans grain de s el.
Et ce n'est, hélas, qu'un exemple parmis des centaines d'autres.

Oui, enfin vu le temps de réponse dans le cas que j'ai subi, si c'éta it
ça c'est que je suis arrivé juste avant, ce n'était vraiment pas de bol.
ça ne doit pas être évident de garantir une confidentialité absol ument
fiable, d'où l'utilisation d'adresses forum, mais que ça ne mette que
quelques heures à fuir, je trouve que ça fait désordre.

Imagine : tu loues un coffre à la banque, tu mets un lingot d'or dedans ,
deux heures après le clochard du coin vient retirer le lingot, et on es t
embêté pour faire les constatations tellement ça sent mauvais dans la
salle des coffres ...

Je dis la base de données, donc en sous-entendant que le piratage so it
passé par trouver la chaîne de connexion, [...]

Pourquoi il se casserait la tête à faire ça ? Il suffit qu'il o uvre un
compte valide avec une adresse hotmail qu'il a créé et consulté v ia un
proxy anonymisant. Il se connecte légitimement et profite ensuite des
failles du site.

Enfin ... Il se connecte en tant qu'utilisateur.
Tu donnes accès à la liste des mails à tes utilisateurs, toi ?

Gloops n'était pas loin de dire :

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.

En l'occurence, j'avais à l'esprit le modèle de SSH. C'est-à-dire
qu'il existe deux clés. La clé publique d'une part, que tu diffuses
largement et qui est celle connue de la base de donnée, et la clé
privée, dont tu es le seul détenteur. Les deux clés sont différentes,
l'une servant à vérifier que la seconde est la bonne.
C'est *un peu*[1] comme si tu avais un verrou biométrique qui relève
tes empreintes et que celles-ci étaient stockées sur une clé USB. Pour
entrer, il faut que tu mettes ta main sur le capteur (clé privée), et
qu'elle correspondent aux données contenues dans la clé USB portant ton
nom (clé publique) ; clé que l'agent de sécurité aurait inséré lorsque
tu t'es présenté.
Le "publique" du nom de la clé voulant dire que c'est celle qui est
partagée par le public. Alors que l'autre clé est "privée" parce que tu
es le seul à l'avoir. Ainsi, dans mon exemple, n'importe qui peut
potentiellement avoir un double des données biométriques de ta main,
mais il est évident que tu es la seule et unique personne à posséder
cette main.


[1]
J'insiste sur le "un peu", sinon Nicolas George va encore me reprendre
et il aurait pas tout à fait tort.

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

Repose en paix mon amour :'(

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

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 ?

Euh, attends, je pense que j'ai compris ce que tu n'as pas compris.

MD5 est cassé parce qu'on a des attaques en collision. C'est à dire qu'on
sait fabriquer, exprès, deux fichiers différents qui ont la même image par
MD5.

Il est également possible que les méthodes qui conduisent à des collisions
permettront à terme des attaques pires, par exemple en préimage. Ce n'est
pas encore le cas, mais comme on a des remplacements meilleurs, il vaut
mieux l'éviter.

Mais ce n'est pas ça dont tu as parlé. Tu as évoqué des sites du genre de
<URL: http://md5.noisette.ch/ > : ce ne sont pas des collisions que ce site
exploite, c'est juste une grosse base de données de MD5 connus, c'est une
attaque par dictionnaire. N'importe quel fonction de hachage est vulnérable
à une attaque par dictionnaire de ce genre. Par exemple :

http://www.sha1-lookup.com/index.php?qˆ43d7f92416211de9ebb963ff4ce28125932878

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

Mais es-tu capable de refournir le
texte originel à partir du MD5 ?

Non, évidemment, c'est le principe d'une fonction de hachage.

Mais il ne faut plus utiliser MD5. De nos jours, le choix le plus évident
est SHA-2.

Stéphane Catteau a écrit, le 14/03/2013 19:10 :

Gloops devait dire quelque chose comme ceci :

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 ?

PuTTY vient avec un logiciel de gestion de clé dont le nom m'écha ppe.
Le contenu peut probablement être décrypté, mais de mémoire il se base
en partie sur des données uniques liées au système, il faut donc piquer
le fichier contenant les clés et arriver à lancer un programme
récupérant les données systèmes utilisées. Donc à mon sens le niveau de
sécurité est sensiblement équivalent à ~/.ssh.

Sur un serveur propre, ça a l'air pas mal.
Sur un mutualisé, je crois bien que tout le monde a les mêmes donné es
système ?
A moins d'introduire le nom d'application quelque part, dedans.

C'est vrai que quand je faisais un test sur le nom d'application, je
devais mettre tous les noms admis : celui sur la machine de
développement, celui sur le serveur ... Si à la place, le nom
d'application est introduit dans la clef de cryptage ... J'imagine qu'il
faut saisir le mot de passe directement sur le serveur ?

En faisant des cryptages à plusieurs étages on devrait finir par fair e
quelque chose de propre ...

J'ai du mal m'exprimer (ça semble récurent ces temps ci). Je me
plaçais dans l'optique d'une connexion avec un protocole
d'autentification clé publique/clé privée. C'est donc ta clé pr ivée que
tu stockes sur une clé USB. Tu connectes donc ta clé USB à ton
ordinateur, ce qui te permet d'avoir accès à ta clé privée et d e
t'autentifier.

Mais ... La clef publique, enfin celle qui sert à décoder, doit êtr e
dans le fichier de configuration ?

Dans l'absolue, si tu as choisi cet hébergeur, c'est que tu as
confiance en lui. D'ailleurs dans l'absolue tu ne devrais même pas te
poser la question de l'autentification. Aussi rudimentaires qu'ils
puissent paraitre, les outils qu'il met à ta disposition sont fiables
et sécurisés. Après tout, il en va de sa réputation, donc de sa
clientèle et de sa pérénité en tant qu'entreprise commerciale.
Le seul point réellement faible ici, c'est ton propre ordinateur.
Admettons qu'il soit suffisement compromis pour qu'une personne soit en
mesure de récupérer les données que tu utilises pour te connecter aux
outils fournis par ton hébergeur. Ne crois-tu pas qu'il serait aussi
suffisement compromis pour qu'il récupère les données nécessair es au
protocole d'autentification que tu aurais toi-même mis en place ?

C'est vrai que les alertes remontées par l'anti-espion de mon pare-feu
m'ont rendu assez parano, donc du coup on n'est pas sortis ... Surtout
maintenant que les machines sont vendues sans CD pour remettre le
système d'aplomb.

Quand une base liée à un forum a été piratée, tu crois que c'es t le plus
souvent en espionnant la machine perso du développeur ?

Mais alors on pourrait mettre le fichier de config en clair, dans ce cas
? ça serait plus simple, non ?

Stéphane Catteau a écrit, le 14/03/2013 19:20 :

Pour prendre un exemple plus proche de la réalité quotidienne, il y a
quelques années de cela, des voleurs s'introduisaient de nuit dans le s
maisons, prenaient les clés de la voiture et volaient la voiture.
Dans l'absolue, les clés étant dans ta maison, ta voiture est en
sécurité. Mais bon, mettre les clés dans un tiroir, au lieu de le s
laisser posée sur la table basse à côté de la porte, augmente t on
niveau de sécurité. Si quelqu'un arrive à forcer ta porte, il fau dra
encore qu'il trouve dans quel tiroir sont les clés.
Cela ne veut pas dire qu'il faille sombrer dans la paranoïa, mais
avoir toujours un minimum de deux niveaux de sécurité est une garan tie
suplémentaire. Si le premier niveau est percé, ce qui est toujours
possible, le second est là pour te protéger.

C'est un peu pour ça que j'imaginais introduire des variations dans le
stockage de la clef de cryptage, pour que le pirate ne sache pas tout de
suite où chercher ...

Gloops devait dire quelque chose comme ceci :

Traduction littérale d'un "connection's strings" trouvé quelque part ?
Tu parles des trucs du genre "/login.php?user=blabla&password=blibli"
(je simplifie à l'extrème évidement) ?
Si oui, un bon vieux hash MD5 et hop. Normalement tu n'as même pas
besoin d'un grain de sel à ce niveau là.

Oui c'est bien ça. Tu notes le mot de passe en clair, c'est juste ça le
point qui fâche.

Pourquoi ? Ok, c'est mieux lorsque c'est crypté, mais voyons un peu
les points faibles possibles :

1) La machine chez ton hébergeur est compromise. Ok, quelqu'un
pourrait intercepter ton mot de passe à ce moment là, mais il n'en
aurait pas besoin en fait.
2) Un routeur de ton hébergeur est compromis. Quelqu'un pourrait
sniffer tout le trafic et donc obtenir ton mot de passe. C'est un
risque réel, mais sauf à avoir choisi un hébergeur moldo-slovaque dont
les machines sont hébergés dans une grange, je doute que ton hébergeur
ne s'en rende pas compte très rapidement ; probablement avant même que
toi tu ne te connectes.
3) Un routeur entre chez toi et ton hébergeur est compris et tu n'as
vraiment pas de bol parce que c'est par là que passe tes données.
J'aurais tendance à dire que c'est comme le point précédent. Les
réseaux sont gérés par des professionnels qui savent ce qu'ils font.
4) Ta machine est compromise. Là, qu'importe ce que tu fais, tu es
foutu de toute façon.

Autrement dit, que le mot de passe transite en clair ou en crypté ne
change pas grand chose. C'est plus sur lorsque c'est crypté, mais sauf
à considérer que les données sont hyper sensibles, le cryptage est
relativement inutile à ce niveau là. Dans tous les cas, si un mot de
passe non crypté est intercepté, cela signifie qu'il y a une faille de
sécurité nettement plus importante que le simple fait que les données
transitent en clair.

Bon alors je connais MD5 pour vérifier qu'il n'y ait pas d'erreur de
transmission, comme une preuve par 9. Mais es-tu capable de refournir le
texte originel à partir du MD5 ?

Non, c'est justement tout l'intérêt d'un hash MD5 à ce niveau là. Tu
ne stockes les données que pour leur valeur de preuve.
Prend par exemple ce que me rétorquait Nicolas George lorsque j'ai
parlé d'une adresse e-mail conservée pour pouvoir envoyer un nouveau
mot de passe. Tu demandes son adresse e-mail à la personne, et tu
compares le hash MD5 de cette adresse à celle que tu as stockée. Si les
deux hash sont identiques, tu envoies le nouveau mot de passe, sinon tu
affiches une erreur.

C'est quand même vrai que lorsqu'on collecte des adresses mail,
en garantir la confidentialité fait partie des implications ...

Tout dépend en fait de l'utilité de ces adresses. Mais bon il arrive
un moment où l'on ne peut rien faire d'autre que les stocker en clair
ou codés avec un algorithme réversible. Cela étant obligatoire dès lors
que l'on est amené à utiliser cette adresse alors que la personne n'est
pas connectée.
Dans ce cas, la meilleure solution est de blinder la base de donnée et
tous les accès SQL. Même en codant les données, tu ne peux pas être sur
que la personne ne saura pas comment renverser ton codage. Or pour
faire cela il n'est pas toujours obligé de pirater ton site, il peut
tout aussi bien créer quelques dizaines de comptes et se servir ensuite
des données qu'il connait pour essayer de comprendre comment tu les as
codées.

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.

J'ai l'impression que voilà un certain nombre de bonnes idées qu'il faut
prendre le temps d'exploiter pour se rendre compte.

Tout dépend de ce que tu t'attends à avoir en face de toi. Mais
n'oublie pas une chose importante :
Plus c'est compliqué pour l'adversaire, plus ça l'est aussi pour toi.
Donc plus il y a de risque que tu ais merdé quelque part et laissé une
porte grande ouverte.

Pour ce dernier point : un temps je me connectais sur usenet avec des
adresses email bidon [...] ça paraissait au départ une bonne idée pour
divertir les spammeurs, et puis finalement il n'y a pas unanimité dessus.

Comme je le disais juste avant, tout dépend de ce que tu t'attends à
trouver en face de toi. Mon adresse e-mail est en clair et valide telle
qu'elle. Je l'utilise depuis de très nombreuses années et elle est
quasiment pas spammée. Ici la solution est simple, ce que je m'attends
à trouver en face de moi, ce sont des robots qui vont retirer le
".nospam", et force m'est de constater qu'ils le font.

Evidement ce n'est pas aussi simple lorsqu'il s'agit de sécuriser une
base de données, mais je pense que dans ton cas 95% des attaques que tu
pourrais rencontrer seront des tentatives d'injection SQL. C'est-à-dire
que tu auras à faire à des personnes qui visent les failles de ton
site, et non des personnes qui essaient d'attaquer directement la base
de données.
Tout simplement parce que c'est ce public là que tu intéresses, les
vilains pas beaux plus compétents auront d'autres chats à foueter que
ton site. Il en ira autrement si un jour tu peux te tarquer d'avoir une
base de plusieurs dizaine de milliers d'adresses e-mail, mais en
attendant il y a plus simple et plus rapide pour eux s'ils veulent
trouver des adresses à spammer.

ça ne doit pas être évident de garantir une confidentialité absolument
fiable, [...]

On en revient encore à mon, "tout dépend de ce...". Plus tu es exposé,
plus il est difficile de garantir la fiabilité. Mais pour un site sans
grandes prétentions, les mesures élémentaires sont généralement
suffisantes.

Je dis la base de données, donc en sous-entendant que le piratage soit
passé par trouver la chaîne de connexion, [...]

Pourquoi il se casserait la tête à faire ça ? Il suffit qu'il ouvre un
compte valide avec une adresse hotmail qu'il a créé et consulté via un
proxy anonymisant. Il se connecte légitimement et profite ensuite des
failles du site.

Enfin ... Il se connecte en tant qu'utilisateur.

Oui, l'erreur vient de la confusion qu'il y a eu sur ce que tu
appelais "chaine de connexion". Maintenant que l'expression est
explicité il semble évident que ce que je dis n'a pas de rapport.

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

Repose en paix mon amour :'(