Discussion :

[Progmeur]

Certes c'est justement ce qu'on appelle un crasher ou un black hacker, qui s'intéresse en général a des grosses entreprise pour ceux qui sont très doué. Pour un site "normal", les tutoriel sur internet en recherchant sur google sont largement suffisant pour sécuriser le dis site car les hacker s'intéressant a faire crasher des sites "normaux" n'ont en général encore très peut de connaissance dans le domaine du hacking, autrement il s’attaquerait a plus grand, le meilleur que j'ai connu personnellement (j'en connais d'autres mais rien de personnel), a réussis a trouver une faille xss sur le site de l'onisep (à 16ans), mais finalement s'a ne l'a pas intéresser d'exploiter la faille pour dire "lol I PWND UR SITE".

Donc la plupart des hacker on un but, la prévention, l'argent, la popularité dans ce milieu. Mais si monsieur veut faire un site non commercial et qui touche peut de monde, alors il aura juste affaire a des white hacker.

Âpres, c'est sur que si tu veut faire un gros site tu risque de te faire hacker, mais le gros site ne se fait pas en solitaire et ne se sécurise pas juste par une personne.

Mais oui une faille permet d'effectuer des injections permettant d'infecter tout les internaute, cela peut être une motivation mais sur un gros site pour que sa touche plus de monde.

[Muchos]

@Progmeur
1. Je pense que les white hat ne s'intéressent pas aux petits sites. Par définition, ils ne crackent pas mais aident à trouver des failles.
2. Au contraire, je pense que les black s'y intéressent, parce que c'est plus simple et même profitable de cracker 1000 petits sites mal sécurisés qu'un gros mieux sécurisé.

[Progmeur]

Les black hacker et crasher n'en n'ont pas grand chose a faire des petits sites vue que leurs motivation est la réputation qu'ils ont auprès d'autres hacker et entre hacker 1000 petit site et un site ultra connue pour la réputation il faut hacker le site connue. Les white hacker quand a eux cherche justement de petit site pour prévenir des failles, ce qui ne servirais a rien sur des gros site vue que toute les failles commune d'un gros site sont scellé (sauf exception).

[Progmeur]

Les black hack s'en fiche de l'argent et des comptes. Sa c'est encore d'autres hacker qui s’intéresse a sa. Mais le black hacker et le crasher font de la destruction de site et laisse une signature.

[Clorge]

s'il vous plait....

Si vous désirez entrer dans le débat, utilisez les bons termes.

Hacker : bidouilleur, il cherche à comprendre le fonctionnement des systèmes, en soit il n'y a rien de mal à ça.

WhiteHat : hacker qui veut le bien dans le meilleur des mondes, il cherche des failles sur les sites sur lequels il est autorisé, bidouille son pc pour voir comment tous ça marche, et si il y a un problème, il en fait part aux dévellopeurs pour le corriger.

BlackHat : L'opposé du Whitehat, il veut du fric, du pouvoir, c'est LUI LE MECHANT!

ScriptKiddie : gamin de 12ans qui prétend savoir pirater les sites, mais qui n'utilise que des softs fait par d'autres, et lui est fier d'avoir HOIC d'installer vous pouvez rire de lui sans soucis

Cracker : hacker spécialisé dans les LOGICIELS.

Bon, désormais que les présentations soient faites :
Il est idiot de croire qu'un site même un blog de gamine soit inutile, AU CONTRAIRE, c'est une proie facile pour obtenir une machine supplémentaires, le blackhat (ou pirate) n'en n'as rien à faire de ses tweet, mais qu'il puisse envoyer du spam, ddos, etc, ça c'est intéressant.

Il faut s'intéresser à la sécurité informatique quand on programme!
Mais bon, un membre du staff as expliquer la position du forum pour les explications des failles et les corrections, j'en dirais rien alors Je connait pas tout, loin de là, mais mes conseils auraient pus en aider certain.

Internet est un réseau immense, ne croyez pas c'est parce que vous n'etes pas connu, qu'on scanneras pas votre serveur, vos ports, vos services et votre site web!

ps : les whitehat s'intéressent à tous les sites, et il m'arrive de tester une xss par ci par là (souvent sous la forme <span></span> afin de ne causer AUCUN tort) et si je trouve quelque chose, je préviens le webmaster, après il en fait ce qu'il veut C'est vraiment dans une optique d'AIDER, et pas causer des problèmes.

[Etanne]

Internet est un réseau immense, ne croyez pas c'est parce que vous n'etes pas connu, qu'on scanneras pas votre serveur, vos ports, vos services et votre site web!

J'ai eu plusieurs serveurs sur le net (linux & windows), pour chaque serveur je me suis fait scanner, ou tentative d'accès aux urls typiques de phpmyadmin ou de l'administration wordpress.

Sans compter le nombre de petits malin qui s'amusent à faire des attaques DOS sur Teamspeak... grr

ps : les whitehat s'intéressent à tous les sites, et il m'arrive de tester une xss par ci par là (souvent sous la forme <span></span> afin de ne causer AUCUN tort) et si je trouve quelque chose, je préviens le webmaster, après il en fait ce qu'il veut C'est vraiment dans une optique d'AIDER, et pas causer des problèmes.

Idem, quand je vois qu'il y a une possibilité de valider un xss, je test mais je passe par zataz pour prévenir les administrateurs.

[ABCIWEB]

Pour protéger les mots de passe lors de la soumission d'un formulaire (et éviter de vous les faire pirater par un sniffeur de réseau) ce lien peut vous être utile.

[Clorge]

@ABCIWEB
O.o ton truc c'est de hash puis d'envoyer ? Si oui, c'est signe que tu as une mauvaise représentation des transactions qui ont lieu....
Tu hash ton mdp, OK
tu envoie ton hash EN CLAIR, OK
tu compare les hash OK

Sauf que là, tu viens simplement de transformer un mdp en un autre, le sniffeur récupere ton hash, et la vérification vas passer.

Si c'est pas ça, autant pour moi, j'ai pas compris.
Sinon, ton système ne CHANGE ABSOLUMENT RIEN.

SSL et c'est tout!
En revanche, on peux utiliser une vérification d'ip par exemple (pas de bypass)
, ou plus sournois, envoyer le mdp dans les header (BYPASS, mais personne ne fait ça, sauf... moi )

EDIT : quand je dis pas de bypass, c'est un peu faux, vu qu'on peut utiliser l'ip de qui on veut sur internet, le problème c'est que la réponse seras envoyer au propriétaire de l'ip et non l'inverse (logique et heureusement xD )

[ABCIWEB]

@ABCIWEB
O.o ton truc c'est de hash puis d'envoyer ? Si oui, c'est signe que tu as une mauvaise représentation des transactions qui ont lieu....
Tu hash ton mdp, OK
tu envoie ton hash EN CLAIR, OK
tu compare les hash OK

Sauf que là, tu viens simplement de transformer un mdp en un autre, le sniffeur récupere ton hash, et la vérification vas passer.

Bah non puisque le hash résultant est à chaque fois différent et dépendant de la session. C'est aussi cela l'intérêt, non seulement cela protège le mot de passe mais le post sniffé est inexploitable pour s'authentifier. Le code de l'exemple est complet, fais des tests !

[Clorge]

J'ai pris le temps de lire ton code source et c'est bien ce que je pensais...
Je m'explique :

Client <-----------|-------------> Server
....................../\
...................Pirate

Client et Server font des échanges, et Pirate voit TOUS !

Le système de connexion se passe en trois temps :
1. Client demande à Server la page pour se connecter,
Server lui envoit, et LA Pirate VOIT ton Hash (ligne 263)
2. Client envoie ses informations à Server.
3. Server renvoie un message en fonction de la validité des informations.

Dès l'étape 1 c'est mort
J'ai pas fait des tests, la flemme... si je me trompe, dit le moi

[ABCIWEB]

Le hash généré n'est valable qu'une seule fois et pour celui qui a ouvert la session ! Si le pirate le récupère et essaies de s'identifier avec il sera rejeté.

[Clorge]

bref, c'est un token, de plus ta sécurité repose sur le fait d'avoir javascript d'activé, ce qui ne devrais *jamais* être le cas dans une application web.

Sinon pour les conseils :
Never Trust user Input
isset && is_string
htmlspecialchars
token
ctype_alphanum
désactiver les phpsessid dans l'url
rtfm (Real The Fucking Manual ) pour l'implentation
Et n'hésitez jamais à faire un test supplémentaire, ça ne ralentiras jamais l'expérience utilisateur!

[ABCIWEB]

bref, c'est un token,

C'est pas simplement un token Cela fait aussi office de token mais c'est surtout une méthode qui permet de protéger son mot de passe sur le réseau !!! Sinon il transite en clair !

de plus ta sécurité repose sur le fait d'avoir javascript d'activé, ce qui ne devrais *jamais* être le cas dans une application web.

Oui il faut avoir javascript activé pour pouvoir se connecter, mais non la sécurité ne dépend pas de javascript puisque sans javascript activé le formulaire ne sera simplement pas envoyé (et un message indique dans ce cas qu'il faut activer javascript).
En d'autres termes cela restreint l'authentification aux seuls visiteurs ayant javascript (activé ou pouvant être activé soit plus de 99.99% des cas). Mais l'utilisation de javascript ne pose pas ici de problème de sécurité en soi, c'est même exactement le contraire puisque cela permet de hasher le mot de passe + sel côté client avant de l'envoyer dans les tuyaux

[Clorge]

Je reste pas convaincu par ton système, https et c'est tout pour moi.

Je propose d'ouvrir un peu plus le thème du sujet :
"Comment faire pour s'assurer du fonctionnement voulu de son application web ?"

Cela semblerais à certains le même sujet, mais cela serais faux, on peux par exemple parler du spam, du flood, etc....

Beaucoup utilise des captchas graphiques (moi également) mais actuellement je bosse aussi sur ça et je pense tenir quelque chose, mais j'en parlerais quand ça serais potable.
d'autres idée : if (substr_count($texte, "http://")>=3)spam();
limitation du nombre de commentaire horaire général, et plus élévée pour les membres (je parle d'un blog open)
le fameux display:none;

Et vous, vous faites quoi contre le spam ?

[Muchos]

Et vous, vous faites quoi contre le spam ?

Merci d'avoir lancé ce sujet

Avec l'affaire Spamhaus/Cyberbunker, j'ai découvert l'excellent travail (m'a-t-on dit) de Spamhaus et l'efficacité de leur liste de domaine à bloquer. Il y a aussi la HTTP Blacklist du projet HoneyPot.

Mais comment utiliser ce genre de liste ? Est-ce efficace en complément de filtres PHP, et éventuellement d'une captcha (dont je ne suis pas fan pour des raisons d'accessibilité. Je préfère une question par exemple) ?

d'autres idée : if (substr_count($texte, "http://")>=3)spam();

Qui signifie : si plus de 3 url dans le texte, c'est du spam ? Si c'est le cas, je ne suis pas convaincu : il y a du spam avec moins et des commentaires valides avec plus.

le fameux display:none;

Quel est le principe ?

[Clorge]

spamhus je connaisais pas, honeypot ouep, j'ai déjà utiliser et c'est vraiment sympa et facile d'utiliser en php (après c'était pas sur un site de trafic)

Qui signifie : si plus de 3 url dans le texte, c'est du spam ? Si c'est le cas, je ne suis pas convaincu : il y a du spam avec moins et des commentaires valides avec plus.

Tout à fait, c'était juste pour lancer des idées comme ça

le fameux display:none;
Quel est le principe ?

Il existe deux types de vérifications de captcha :
Ceux auquel tu doit prouver que tu est un humain
Ceux auquel tu doit prouver que tu n'est pas un robot

Quelle différence ?
Et bien les captchas graphiques c'est du premier type.
le display:none c'est le deuxième.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<form method="post" action="#">
<input type="hidden" name="if_not_empty_is_bot" />
<input style="display:none" name="if_not_empty_is_bot_2" />
</form>

L'user à rien à faire, c'est les stupides bot qui font le boulot.

[ABCIWEB]

Je reste pas convaincu par ton système...

Cela ne m'étonne pas puisque dès le début de ton intervention sur ce post tu as répondu de manière erronée et en plus à côté du sujet :

1/ Depuis le début j'ai précisé que c'était pour la protection du mot de passe et ta première réponse a été de dire que cela ne protégeait pas le post
Quand on parle de sécurité il faut être précis, chaque technique a une fonction précise et il ne faut la considérer que pour ce qu'elle a été conçue. C'est en empilant ensuite différentes techniques, chacune ayant son rôle bien défini, que l'on parvient à une protection globale satisfaisante.
En d'autres termes plus imagés, je montre une solution facile pour qu'on évite de pouvoir voler la clé qui se trouve dans ta poche, et tu me réponds que ce n'est pas un protège tibia... D'une part tu réponds à côté du sujet mais en plus il se trouve que cette solution protège aussi les tibias (le post n'est utilisable qu'une seule fois). Ce qui fait une double mauvaise réponse

2/ Dans ta deuxième réponse, après avoir "pris le temps de lire le code", tu fais un beau shéma et termine par une conclusion hâtive qui montre à l'évidence que tu n'as pas compris le principe du script.
En effet le pirate peut voir le hash final et le sel mais ce qui l'intéresse c'est le mot de passe. Pour récupérer le mot de passe il devra donc essayer toutes les combinaisons de mot de passe (par force brute, dictionnaire impossible) pour trouver celui qui, concaténé au sel puis hashé, donnera le hash final. Le délai de calcul pour trouver un mot de passe un peu long de cette manière est considérable, c'est bien pour cela qu'on recommande d'utiliser cette même méthode pour stocker les mots de passe en bdd

3/ Dans ta troisième réponse tu résume cette technique à un token, mais c'est bien plus qu'un token puisque, encore une fois, il s'agit de protéger le mot de passe pour qu'il ne transite pas en clair sur le réseau.
Et tu termine avec comme bouquet final par le chapitre javascript avec une phrase "toute faite" mais qui est particulièrement mal venue dans ce contexte puisqu'il s'agit de renforcer la sécurité avec javascript, pas de mettre en péril celui qui ne l'a pas activé. A ton avis, comment sont programmés les claviers virtuels anti keylogger de certaines banques, avec de la poudre de perlinpinpin ? Essaies un peu de désactiver javascript pour voir Voilà le résultat :

Connexion sans javascript

La Banque Postale fait de la sécurité sa préoccupation constante, et s'applique en permanence à maintenir et à renforcer son dispositif de sécurité.

Le javascript n'est pas activé dans votre navigateur. Pour cette raison, vous avez été dirigé vers cette page lorsque vous avez voulu consulter vos comptes en ligne.

En effet, les objectifs élevés que nous nous sommes fixés pour assurer la protection de vos données bancaires, nous imposent des mesures de sécurité. Ces mesures nous ont conduit à proposer pour la saisie de votre mot de passe, un clavier de saisie virtuel sécurisé, qui nécessite le javascript.

Nous vous remercions d'avance pour votre compréhension.

4/ Donc avec autant de mauvaises réponses ta conclusion finale ne m'étonne guère et si c'est pour terminer par une pirouette en disant que cela ne procure pas une solution du même niveau que SSL, c'est justement ce que j'indiquais dans mon message pour les débutants :

...C'est pas nouveau mais pas difficile à mettre en place et ça offre une protection intéressante pour ceux qui n'utilisent pas SSL, et pour ceux qui utilisent SSL cela peut servir de protection complémentaire au cas où le certificat viendrait à être piraté (ce qui s'est déjà produit).

Je précise pour les débutants qu'en aucun cas cela procure une protection du niveau de SSL, notamment SSL protège votre session, ce qui n'est pas le sujet du script proposé dans le lien qui concerne uniquement la protection du mot de passe.

En fait que je t'ai convaincu ou pas cela m'importe peu. Si j'ai pris le temps de rentrer dans les détails c'est parce que ta manière de répondre très péremptoire pourrait troubler les débutants au point de les détourner d'une solution facile à mettre en place et quasi indispensable (sauf à transmettre les mots de passe en clair) pour ceux qui ne disposent pas de SSL. Et à ma connaissance (pour l'instant et sauf erreur) aucun hébergeur ne propose SSL dans ses offres mutualisés d'entrée de gamme. Et comme déjà dit même pour ceux disposant de SSL la technique de hash côté client permet un double blindage pour le mot de passe.

Enfin pour terminer (ouf ) ce n'est pas mon système, c'est un système bien connu de ceux qui s'intéressent de près à la sécurisation d'un mot de passe. Les premières versions php/javascript que j'ai connues utilisaient le md5, ça fait donc déjà largement plus de 10 ans. Quand je disais que c'était pas nouveau... De là à penser que c'est vieux donc obsolète, faudrait pas tirer de conclusions trop hâtives car si depuis tout ce temps les lib javascript ont été constamment mises à jour - on trouve aujourd'hui facilement des lib sha256 ou même sha512 proposée par google - ce n'est certainement pas pour faire du tricot

[Clorge]

1) Tu as raison de souligner la précisions qu'il faut avoir ses propos, étant donné que le terme "post" étant dans la tête la signication de la méthode du protocole http, et non d'une données envoyer dans un formulaire.

2) "pris le temps de lire le code" != comprendre || ne pas se tromper
Et à ce que j'ai compris du script, il utilisais le hash comme mdp, donc ça ne changeais rien au problème.

3)"A ton avis, comment sont programmés les claviers virtuels anti keylogger de certaines banques" Tu mélange l'insertion de données dans un formulaire et leur envoi.
(J'aurais également pas déjà programmer un clavier virtuel si je trouvais ça inutile, mais c'est se battre sur un autre front, qui d'ailleurs n'est pas vraiment le notre...PEKBAC)
Alors pour reprendre ta phrase : Essaies un peu de refuser de naviguer en https sur un site bancaire.

Comme tu confond le hashage et le chiffrement, md5, sha1, et co ne sont pas des alternatives à ssl, c'est même pas un mini-mini ssl. Les données circulent donc en clair sur le réseau, hashé ou non.

Je ne conçoit peut-etre|surement pas correctement le fonctionnement du système, mais je reste les membres explorer cette voie si ils le souhaitent.

@ABCIWEB je ne ferme pas le débat à ta proposition, mais je préfère qu'on en reste là afin d'explorer d'autres pistes.

Que pensez-vous d'un captcha qui compte sur les sentiments ? Par exemple
Tuer un homme c'est :
-utile
-horrible
-drole
-nécessaire

bon le ratio de chance est élevé mais avec deux questions et une bdd, ça peut le faire (en complément à d'autres techniques) et puis ça éliminent tous les bots généralistes.

[rodolphebrd]

Bonjour,

Que pensez-vous d'un captcha qui compte sur les sentiments ? Par exemple
Tuer un homme c'est :
-utile
-horrible
-drole
-nécessaire

Je pense que c'est une plaisanterie.
Mais j'y répondrais sinon en disant qu'un captcha basé sur des sentiments induit :
-des dérives
-des réponses erronées
-la potentiel fuite d'internautes

Quant la question que vous posez : tuer un homme peut éveiller des sentiments différents selon l'angle sous lequel on se place.

Un captcha doit être incontestable avec une réponse et une seule : comme de quelle couleur est la neige avec un choix entre blanc et noir.

[ABCIWEB]

Je ne conçoit peut-etre|surement pas correctement le fonctionnement du système, mais je reste les membres explorer cette voie si ils le souhaitent.

Ce que tu devrais retenir de cet échange c'est que quand on ne comprend pas un script, soit on ne le commente pas, soit on demande des explications, mais en tous cas on évite d'en tirer des conclusions pour les affirmer haut et fort.

Parce qu'en faisant ainsi :

1/ Tu peux tromper des débutants par des affirmations fausses (et il y en a une collection remarquable dans tes réponses sur le sujet).

2/ Tu force ton interlocuteur à passer sur le mode contradictoire (plutôt que pédagogique) ce qui risque d'être désagréable à ton égard, et ce faisant pour ne pas perdre la face cela t'incite à faire des réponses approximatives qui t'enfoncent à chaque fois un peu plus.
Remarque que c'est exactement le processus de déroulement de tes réponses. Et pour te charrier un peu j'ai bien envie de te demander si vraiment tu n'es pas un boot, parce qu'avec un comportement aussi prévisible on pourrait s'interroger...

Cela dit suivant le caractère et l'age de chacun, j'ai bien conscience qu'on peut s'amuser à adopter ce comportement en pensant qu'on apprendra toujours quelque chose. Peut-être mais pas toujours et à quel prix et avec quelle perte de temps ? Au final dans cet exemple j'ai plutôt l'impression que le bilan est que tu n'as rien appris et qu'au passage tes réponses peuvent induire de l'incompréhension et des contre sens pour les débutants.

Car enfin que veux-tu dire avec

...c'est même pas un mini-mini ssl. Les données circulent donc en clair sur le réseau, hashé ou non.

Si tu ne vois pas la différence entre un mot de passe qui circule hashé et salé par rapport à un mot de passe qui circule en clair, tu as un vrai gros problème, surtout pour quelqu'un qui s'intéresse à des problèmes de sécurité. Dans le premier cas, pour retrouver le mot de passe il faudra lancer des calculs avec un temps de résolution imprévisible, dans le second cas c'est un cadeau gratuit instantané. Tu ne vois vraiment toujours aucune différence ? Pour le sniffeur qui veut connaître ton mot de passe c'est la même différence qu'entre se retrouver devant un excellent blindage ou une porte ouverte.