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.

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.

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

- 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>

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).

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.

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.
++