On dira ce qu'on veut à propos de l'utilisateur (il est nul, il ne vérifie pas 100% de ce qu'il a devant les yeux), mais ne jamais se tromper est impossible. Donc "aider" l'utilisateur à ne pas se tromper est une bonne chose.
Cependant je trouve que le procédé décrit ici est problématique: il faut que le navigateur le prenne en charge. Il faut se connecter une première fois au site. Et il faut que le navigateur enregistre quelque chose.
Ca fait trois conditions. La première est inévitable, ok. Les deux autres sont des contraintes, des sources de problèmes, et des failles potentielles.
Exemples: j'utilise un autre ordinateur. Je suis dans un cyber café. J'ai un live-cd. Etc.
Pourquoi ne pas utiliser un champ dns ?
Il faut également un navigateur adapté, ça ne change pas.
Pas besoin d'effectuer une première connexion.
Pas besoin de stocker l'information.
Est-ce plus vulnérable que la page non sécurisée lors de la première connexion ?
# Mauvaise réponse à un vrai problème ?
Posté par Kerro . En réponse à la dépêche HTTP Strict Transport Security. Évalué à 5.
On dira ce qu'on veut à propos de l'utilisateur (il est nul, il ne vérifie pas 100% de ce qu'il a devant les yeux), mais ne jamais se tromper est impossible. Donc "aider" l'utilisateur à ne pas se tromper est une bonne chose.
Cependant je trouve que le procédé décrit ici est problématique: il faut que le navigateur le prenne en charge. Il faut se connecter une première fois au site. Et il faut que le navigateur enregistre quelque chose.
Ca fait trois conditions. La première est inévitable, ok. Les deux autres sont des contraintes, des sources de problèmes, et des failles potentielles.
Exemples: j'utilise un autre ordinateur. Je suis dans un cyber café. J'ai un live-cd. Etc.
Pourquoi ne pas utiliser un champ dns ?
Il faut également un navigateur adapté, ça ne change pas.
Pas besoin d'effectuer une première connexion.
Pas besoin de stocker l'information.
Est-ce plus vulnérable que la page non sécurisée lors de la première connexion ?