login et p'tits malins

par **Invité** » 01 août 2005, 19:41

encore un autre truc pas bon.
en passant par des fichier il faut gérer les accès concurrents.
donc plantage sur toute la ligne, je passe à autre chose.
++

par **Invité** » 01 août 2005, 17:50

si tu as mis les controles aux bon endroits ça devrait aller(en tout cas chez moi).

sinon je suis aller un peu vite avec le champs hidden, en fait je teste un truc qui existe forcément.

quand je le faisait avec le champs de login ça marchait paceque je me servait de sa valeur.
en gros le robot envoyait $_GET['ancien_champs'] alors que j'utilisais $_GET[$pass] pour tester le login.
donc pas de problème le robot avait forcément faux.

alors que là je teste si $_get[$pass] existe...et forcément il existe.

mais dans ce cas là on en revient au problème du stockage du mdp dans le navigateur si je trouve pas de solutions avec un autre champs que le login ou le mot de passe.

par **naholyr** » 01 août 2005, 17:28

Premier bug :

A vient sur la page => nom du champ = 2108
B vient sur la page => nom du champ = 3968
A s'identifie => ERREUR, le champ 2108 est invalide (on attend 3968)

Je ne vois pas de solution a priori (par exemple, si on se base sur la date pour modifier le fichier, on se retrouvera avec la situation où A vient sur la page, attend 5 minutes avant de s'identifier, et pouf erreur).

par **Invité** » 01 août 2005, 17:06

- elle empêche le stockage du mdp par l'utilisateur, sauf ajout de bidouille bizarroïde (et là forcément, je suis pas pour).

oublis, j'utlise maintenant un champs hidden.

Bref le gain ne me parait pas évident, aussi transparent soit le résultat. Mais l'expérience prouvera peut-être que j'avais tort Smile

c'est pour ça que j'en parle ici pour avoir des idées auxquelles je n'aurais pas pensé tout seul, et éviter que ça plante en prod.
et si il en ressort quelquechose d'interessant ça pourra toujours servir à d'autres.

je te files le code brut (phase de test donc ça marche mais c'est tout):

<?php
session_start();
if(isset($_GET['mdp']))
{
	$pass=file_get_contents('mdp.txt');
	file_put_contents('mdp.txt','');
	if(!isset($_GET[$pass])) exit;
}

?>

<html>
<body>
<form action="testmdp.php" method="GET">
<?php
$num=rand(1344,19000);
$ti=fopen('mdp.txt','r+');
fwrite($ti,$num);
echo'<input type="hidden" name="'.$num.'">';
?>
<input type="text" name='login'>
<input type="password" name='mdp'>
<input type="submit">
<?php

if(!isset($_GET['mdp'])) exit;

//traitement du mot de passe
?>
</form>
</body>
</html>

par **naholyr** » 01 août 2005, 16:44

Quoi qu'il en soit cumuler des protections n'est que positif tant que ça ne nuit pas à l'utilisateur...:
...
- blocage du compte
...
ça veut dire que tu es contre le boquage de compte?

Non non je suis pour toutes les méthodes que j'ai cité, car elles ne nuisent pas à l'utilisateur dans le cadre d'une utilisation "classique". Si son compte est bloqué ce n'est qu'un lien à suivre (comme lors de l'activation), donc rien de très contraignant.

Je me méfie plus de la bidouille sur les champs aléatoires pour plusieurs raisons :
- de toutes les méthodes c'est la plus lourdes à implémenter (je serais curieux de voir exactement comment tu l'implémenteras d'ailleurs), et plus c'est gros, plus c'est buggé.
- elle empêche le stockage du mdp par l'utilisateur, sauf ajout de bidouille bizarroïde (et là forcément, je suis pas pour).

Bref le gain ne me parait pas évident, aussi transparent soit le résultat. Mais l'expérience prouvera peut-être que j'avais tort

par **Invité** » 01 août 2005, 16:23

le problème avec les questions de sécurité c'est qu'on peut vite s'emballer pour pas grand chose, voir faire des trucs lourds et inutiles qui se feront cracker de toute manière.

basiquement je vois trois types d'attaquants possibles:
.joe le malin
.joe le motivé
.joe le déterminé

de mon côté je cherche une solution pour le malin voir le motivé.
pour ce qui est du déterminé je ne peux pas grand chose.

pour moi quelqu'un de déterminé sera une personne qui cherchera plutôt à attaquer le serveur ou le site avec ses propres outils(cheveaux de troye...)
pire, si c'est un vrai pirate et pas un gamin alors il n'aura même plus besoin d'outil informatique.
il lui suffira d'étudier la boîte qui utilise le site ou celle qui l'heberge(des fois la même).
trouver une faiblesse(ou la créer) chez un employé disposant d'infos confidentiel, et l'acheter en conséquence.
contre lui rien à faire(d'un autre côté je ne vois pas pourquoi il s'interesserait aux sites que je peux faire).

je dirais aussi que dans les solutions que je cherche c'est un peu comme lorsque je sors de chez moi.
si je ferme à double tour, c'est pas tellement pour empécher quelqu'un qui veut vraiment rentrer de le faire, mais plutôt pour être sûr qu'il se fatiguera avant de dépouiller mon appart.
question de principe.

après la psychologie d'un connards de base veut qu'il s'attaque à ce qui est faible.
donc avec un minimum de répondant je crois qu'on peut éviter 90% des problèmes.

Si j'écrivais un logiciel de crack je procèderai en 2 étapes :
...
1.2. recherche d'un couple de <input type="text"> et <input type="password"> dans le même formulaire

c'est vrai que c'est une possibilité mais avec un attribut visibility sur un autre champs texte ça devrait résoudre le problème(je vois mal un robot capable de choisir).
et puis imagine le temps que tu passes à scanner la page à chaque essai.
sinon je vois plus ce style de prog comme en étant un fait sur mesure pour un site donnée.

Quoi qu'il en soit cumuler des protections n'est que positif tant que ça ne nuit pas à l'utilisateur...:
...
- blocage du compte
...

ça veut dire que tu es contre le boquage de compte?

sinon le fait d'être obligé d'envoyer un mail ou de mettre une photo me plait pas trop justement pour ce que tu viens de dire de l'utilisateur.

c'est assez compliqué à gérer dans le code, ça peut engendrer des erreurs de traitements, et ça empêche l'utilisateur de pouvoir stocker son login/mot de passe dans son navigateur

c'est vrai que tu dois placer les instructions au bon endroit, mais il y a peut d'instruction à placer et après tout ça fait partie du boulot de régler au millimètre.
pour le stockage dans le navigateur j'y avait pas pensé, mais en gardant la même logique avec un champs hidden on arrive au même résultat, donc c'est réglé.

sinon j'aimerais bien que tu me dises les erreurs de traitement que tu imagines.

après rien n'empêche de garder un algo pour bloquer le compte, mais à moins que soit soulevé un problème qui me fasse dire que ça sert à rien, ça devrait éviter justement à devoir bloquer un compte, donc générer un truc moin lourd et transparent pour l'utilsateur avec un niveau de sécu acceptable.

par **naholyr** » 01 août 2005, 14:15

la deuxième est lié au fonctionnement du logiciel de crack.
ce type de logiciel nécessite de connaître le nom des champs login et mdp.

Si j'écrivais un logiciel de crack je procèderai en 2 étapes :
1.1. lecture de la page d'identification
1.2. recherche d'un couple de <input type="text"> et <input type="password"> dans le même formulaire
2. envoi du formulaire

et du coup les noms importent peu...

Quoi qu'il en soit cumuler des protections n'est que positif tant que ça ne nuit pas à l'utilisateur (comme ajouter une image à l'identification, on peut supposer que ça nuit à l'utilisabilité du site) :
- noms des champs aléatoires (à l'inscription et à l'identification)
- affichage d'une image à l'inscription pour différencier robot/humain
- blocage du compte
- affichage d'informations générales (ne pas préciser le type d'erreur d'identification)
- délai plus important de réponse (un sleep d'une ou deux secondes, voire plus) dans le cas d'une erreur d'identification (impossible pour le robot de déduire d'une lenteur que le mot de passe est erroné, ça peut très bien être une lenteur passagère sur la ligne).

Personnellement je n'accroche vraiment pas à la solution des noms de champs aléatoires parce que c'est assez compliqué à gérer dans le code, ça peut engendrer des erreurs de traitements, et ça empêche l'utilisateur de pouvoir stocker son login/mot de passe dans son navigateur, et au final je ne suis pas convaincu que ce soit efficace selon le logiciel de crack.

par **Invité** » 01 août 2005, 13:19

dans une méthode que j'envisageais je pesais le pour et le contre vis à vis de donner ou pas le login.
je me disais qu'après tout vu qu'il y avait un algo pour bloquer le compte c'était pas trop important même si par principe ça ne plaisait pas beaucoup.

finalement j'ai explorer deux autres pistes.

la première serait d'utiliser une image anti spam, mais ça obligerait l'utilisateur à remplir 3 champs au lieu de deux.

la deuxième est lié au fonctionnement du logiciel de crack.
ce type de logiciel nécessite de connaître le nom des champs login et mdp.

le truc est de générer dynamiquement un champs login(ou mdp) avec un nom aléatoire(rand(456,7896) marche très bien) et stocker ce nom dans un fichier placé dans un répertoire protégé.
il suffit ensuite de récupérer le nom générer et de tester si $_POST['nom_généré'] existe bien pour continuer le traitement.

pour l'instant ça pertube bien le robot, donc reste à savoir s'il n'y a pas de faille dans ce système.
en tout cas s'il n'y a pas de faille, plus de bloquage de compte, et cette idée me plairait bien.

par **naholyr** » 31 juil. 2005, 22:53

Une autre méthode :
- À chaque tentative si le compte n'existe pas, ou si le mot de passe est mauvais, on a le même message d'identification incorrecte.
- Au bout de 3 essais infructueux en moins de 5 minutes sur un compte existant, le compte est bloqué et un mail indiquant les instructions de déblocage est envoyé à l'utilisateur légitime.
- Tant que le compte est bloqué, toute tentative de login se solde par un message d'identification incorrecte.

Le message d'identification incorrecte est un message généraliste indiquant que "le compte est inexistant ou bloqué, ou bien le mot de passe est incorrect", accompagné bien sûr d'explications dans les différents cas (vérifiez votre boite mail, vérifiez le caps-lock, etc...).

On ne donne ainsi jamais aucune information quant à savoir si le login existe ou non, et surtout on ne différencie pas un compte bloqué d'un compte inexistant.

par **Invité** » 31 juil. 2005, 21:31

une petite précision sur les logiciels de crack pour que ceux qui n'en ont pas un sous la main évitent de se faire avoir.

un moyen de régler ce type de logiciel est de lui dire:
si la réponse à l'essai est différente d'un mauvais login, alors c'est que c'est le bon.

imaginons maintenant trois choses:
.le logiciel est sur un login qui existe et passe en revu les différents mdp.
.une fois le compte bloqué on pense à avertir l'utilisateur légitime, au cas où il viendrais se loguer, que son compte est bloqué(donc lorsque login et mot de passe sont bon).
.bloqué ou pas bloqué on garde la même réaction lorsque le mot de passe est mauvais.

donc lorsque le bon login/mdp sera trouvé par le logiciel, il interprétera l'avertissement du compte bloqué comme ayant trouvé le bon login/mdp...et il aura raison.

après à chacun de voir comment éviter ce piège

par **Invité** » 31 juil. 2005, 15:14

Enfin, dernière option, mais coûteuse, la partie identification via une page https (sécurisée).

exact, j'ai soulevé le problème du sniffage et j'attends de voir ce que décidera le client.

par contre bien vue l'histoire des lettres déformés j'avais pas du tout pensé au système ocr(en plus ça m'évitera de trop râler contre les images avec des lettres incompréhensibles).

sinon merci pour les réponses ça m'a bien aidé à réfléchir sur le sujet et à trouver des solutions, et même si je suis conscient qu'un système ne sera jamais fiable à 100% je reste preneur de tout autre proposition.

...et puis maintenant je peux commencer à coder le système de sécu

par **Cyrano** » 31 juil. 2005, 14:10

Quelque chose dans ce goût-là oui. j'ajouterais même autre chose.

Lorsqu'un internaute ouvre un compte, tu pourrais mettre en place un système avec image de caractères déformés un peu comme on voit sur certains sites: ces caractères ne peuvent pas être lus par un robot puisque c'est une image, les lettres déformées pour empécher la reconnaissance par des robots qui pourraient comporter un programme de reconnaissance de caractères OCR, et donc leur interdit toute inscription automatique. Ajoute à ça l'envoi d'un courriel comprenant une url variable de validation/confirmation et à mon avis ton site devrait être relativement bien protégé.

Enfin, dernière option, mais coûteuse, la partie identification via une page https (sécurisée).

par **Invité** » 31 juil. 2005, 13:35

histoire de savoir si j'ai bien compris:

.je garde l'idée d'une variable temporelle pour savoir qui fait les tentatives.
.au bout de n tentatives je bloque le compte pendant une durée déterminé.
.le fait de bloquer le compte pour une durée déterminé empêche le crackage du compte à cause d'un problème de temps, et évite à l'admin du site de le débloquer manuellement.
.je garde l'idée de ce système pour tout ce qui permet à un internaute d'envoyer des commentaires sur le site.

c'est ça?

par **naholyr** » 31 juil. 2005, 09:38

pour l'instant je pense à stocker une variable temporelle de l'ordre de la milliseconde hisoire de savoir si c'est un humain ou un robot qui fait les tentatives(je commence à être fatigué et c'est une des premières idées qui m'est passé par la tête).

C'est une très bonne idée, les protections de type anti-flood sont souvent mises en place et c'est efficace. Imagine un brute-force s'il doit s'écouler 5 secondes entre chaque tentative ! il aurait besoin de milliers d'années pour cracker le mot de passe

par **Invité** » 31 juil. 2005, 01:33

en fait j'ai mal lu vos réponses et j'étais resté sur l'idée d'une redirection alors que vous me parliez de bloquer le compte.

entre temps j'ai tester un logiciel de crack et c'est clair qu'une redirection sert à rien du tout.

pour l'instant je pense à stocker une variable temporelle de l'ordre de la milliseconde hisoire de savoir si c'est un humain ou un robot qui fait les tentatives(je commence à être fatigué et c'est une des premières idées qui m'est passé par la tête).

donc si vous avez une meilleur idée...

login et p'tits malins

Répondre

Étendre la vue Revue du sujet : login et p'tits malins