Discussion :

[Sergejack]

Bonjour.

J'aimerais vos avis.

Je suis en train d'employer un mécanisme de sécurité que j'ai mis au point, je ne lui trouve pas de failles mais peut-être serez vous plus judicieux (vicieux ? ) que moi.

Voilà le principe :

le client envoies au serveur l'id de l'utilisateur (publique, si on peut dire), la date courrante (synchronizée avec le serveur), une clé aléatoire (déterminée par le client) et un code calculé : le hash md5 de date + clé + password utilisateur.

Le serveur vérifie d'abord si la date n'est ni future, ni trop éloignée dans le passé (délais Y).
Ensuite le serveur opère au même calcul du code (avec sa propre connaissance du password utilisateur).
Si les codes correspondent, le serveur vérifie (en DB) si la clé et la date n'ont pas déjà été utilisées pour cet utilisateur.
Si ce ne fut bien pas le cas, l'identification est réussie, on en profite pour supprimer de notre DB les date-clés-utilisateur obsolète (délais Y dépassé) et on enregistre le date-clés-utilisateur qui a servit à l'identification.

Grace à ça :
Le password n'est jamasi transmis en clair.
Le code n'est jamais réutilisable.
Les clés obsolètes ne sont pas conservées et ne sont pas réutilisables.

Malgré cela :
Une attaque man in the middle peut être faite si le message est remplacé en conservant les éléments d'indentification (pourrait être rendu "impossible" en incorporant un "hash du message" dans le calcul du code).

Qu'en pensez vous ?

[Sergejack]

Je n'ai peut-être pas mis l'avantage essentiel en évidence :
Avec ce mécanisme, il n'y a pas besoin d'échanger de grain de sel (sable) depuis le serveur vers le client, ce qui permet à l'utilisateur d'ouvrir par exemple 100.000.000 de page d'identification en parallèlle et de toute pouvoir les exploités sans rencontrer le problème de "grain de sel obsolète".

[FoxLeRenard]

Je n'ai peut-être pas mis l'avantage essentiel en évidence :
Avec ce mécanisme, il n'y a pas besoin d'échanger de grain de sel (sable) depuis le serveur vers le client, ce qui permet à l'utilisateur d'ouvrir par exemple 100.000.000 de page d'identification en parallèlle et de toute pouvoir les exploités sans rencontrer le problème de "grain de sel obsolète".

Tu as déjas mis des barages, mais la saisie d'un texte sur image plus la déconnection sur un IP aprés trois essais empéch toute robotisation

[Sergejack]

Les images gênent aussi l'utilisateur surtout si l'opération d'identification se fait fréquement (par exemple lors d'une commande sur un site de vente non https).

Les IP peuvent être spooler, un robot intéligent le fera et pourrait aussi bloquer des tiers*.

La seule chose qui peut être faite, c'est de bloquer l'accès à un compte temporairement après trop d'essaie*.

*gênant mais pas trop