Si un site Web a un délai de 5 secondes avant d'afficher le formulaire de connexion, est-ce probablement une mesure de sécurité?
La page d'accueil de JP Morgan Chase a un délai de 5 secondes avant l'apparition du formulaire de connexion. Si vous rafraîchissez le délai est toujours là. Si vous ne parvenez pas à entrer un mot de passe correct, la page de connexion ayant échoué n'a pas un tel délai lors du chargement de la page, quel que soit le nombre de demandes d'actualisation.
La page d'accueil met-elle en œuvre une sorte de mesure de sécurité?
La page d'accueil met-elle en œuvre une sorte de mesure de sécurité?
Si vous faites référence à https://www.chase.com , alors non, c'est juste lent à charger et à faire la transition. Terrible UX peut-être, mais ce n'est pas une fonction de sécurité. Un bot de crack de connexion n'utilisera généralement pas l'interface utilisateur de toute façon.
Fondamentalement, c'est un site Web bancaire et la terrible UX est malheureusement la norme.
Bien que ce cas particulier ne soit pas lié à la sécurité, il n'est pas rare d'avoir une limitation de débit entre les demandes de connexion. Cela devrait être implémenté dans le code principal pour que toutes les demandes soient efficaces.
Un scénario possible où ce retard pourrait être dû à une mesure de sécurité est si le site utilise quelque chose comme Client Puzzle Protocol (CPP) . Cela ne semble pas être le cas avec https://www.chase.com/ , mais les CPP peuvent être utilisés pour empêcher les attaques par déni de service contre les fonctions de hachage lentes . Il s'agit essentiellement d'une implémentation de système de preuve de travail . Plus de détails ici .
L'idée de base est de forcer le client à effectuer une quantité importante de travail, et de prouver qu'il l'a fait, avant d'accepter une paire nom d'utilisateur/mot de passe et d'essayer de la valider. Aperçu de base de l'approche du poste lié:
Le serveur génère un puzzle aléatoire et envoie le puzzle au client. Le serveur génère le casse-tête de manière à pouvoir prédire raisonnablement bien les efforts nécessaires pour résoudre le casse-tête (par exemple, 100 ms de calcul). Le client résout le casse-tête, puis envoie la solution avec le nom d'utilisateur et le mot de passe de l'utilisateur.
Dans un environnement Web, cela serait probablement implémenté avec Javascript: la page de connexion contiendrait le code Javascript pour résoudre le puzzle et la description du puzzle. Le navigateur Web d'un utilisateur légitime exécuterait le Javascript sur la page, ce qui résoudrait le casse-tête et inclurait la solution dans le formulaire avec le nom d'utilisateur et le mot de passe.
En fonction de la façon dont cela est mis en œuvre, un site peut retarder le chargement de la page de connexion jusqu'à ce que le client (votre navigateur) résolve le puzzle. Encore une fois, une mauvaise conception de l'interface utilisateur - je désactiverais simplement le bouton de connexion jusqu'à ce que le puzzle soit résolu et activer le bouton pour la soumission du formulaire de connexion une fois que le client a une solution.
Regarder le code source à l'aide de Chrome:
view-source:https://www.chase.com/
le
<form name="homeLogonForm" class="container-fluid chase-home-login" action="https://mfasa.chase.com/auth/alogin.jsp" method="post" autocomplete="off">
l'élément est présent lorsque la page se charge, il n'est donc certainement pas "caché" aux robots simples via JavaScript, mais semble plutôt être une décision UX de retarder sa présence.
Sans demander à Chase Bank, je ne peux que conjecturer que cela a été fait pour des raisons d'utilisabilité découvertes pendant leur phase de test.