La homepage di JP Morgan Chase ha un ritardo di 5 secondi prima che compaia il modulo di accesso. Se si aggiorna il ritardo è sempre lì. Se non si immette una password corretta, la pagina di accesso non riuscita non ha un tale ritardo quando la pagina viene caricata, indipendentemente dal numero di richieste di aggiornamento.
La home page implementa una sorta di misura di sicurezza?
Is the homepage implementing some sort of security measure?
Se ti riferisci al link , allora no, è solo lento caricare e fare la transizione. Forse UX terribile, ma questa non è una funzionalità di sicurezza. Un bot di cracking di accesso in genere non utilizza in genere l'interfaccia utente.
Fondamentalmente, si tratta di un sito Web bancario e la terribile UX è tristemente la norma.
Anche se questo caso particolare potrebbe non essere correlato alla sicurezza, non è raro avere un limite di velocità tra le richieste di accesso. Questo dovrebbe essere implementato nel codice back-end per fare in modo che tutte le richieste siano efficaci.
Uno scenario possibile in cui questo ritardo potrebbe essere dovuto a una misura di sicurezza è se il sito utilizza qualcosa come un Protocollo del Puzzle del client (CPP) ) . Questo non è il caso del link , ma i CPP possono essere utilizzati per prevenire attacchi denial of service contro le funzioni di hashing lente . È fondamentalmente un'implementazione del sistema Proof-of-Work . Maggiori dettagli qui .
L'idea di base è di costringere il cliente a svolgere una notevole quantità di lavoro e dimostrare di averlo fatto, prima di accettare una coppia nome utente / password e provare a convalidarla. Panoramica di base dell'approccio dal post collegato:
The server generates a random puzzle, and sends the puzzle to the client. The server generates the puzzle in a way that it can predict reasonably well how much effort will be required to solve the puzzle (e.g., 100ms of computation). The client solves the puzzle, and then sends the solution along with the user's username and password.
In a web setting, this would probably be implemented with Javascript: the login page would contain the Javascript code to solve the puzzle and the puzzle description. A legitimate user's web browser would run the Javascript on the page, which would solve the puzzle and include the solution in the form along with the username and password.
In base a come viene implementato, un sito potrebbe ritardare il caricamento della pagina di accesso finché il client (il tuo browser) non risolve il problema. Ancora una cattiva progettazione dell'interfaccia utente - Disattiverei semplicemente il pulsante di accesso fino a quando il puzzle non verrà risolto e abiliterò il pulsante per l'invio del modulo di accesso una volta che il client ha una soluzione.
Esame del codice sorgente mediante Chrome:
view-source:https://www.chase.com/
il
<form name="homeLogonForm" class="container-fluid chase-home-login" action="https://mfasa.chase.com/auth/alogin.jsp" method="post" autocomplete="off">
è presente quando la pagina viene caricata, quindi non è sicuramente "nascosto" dai bot semplici tramite JavaScript, ma sembra piuttosto una decisione UX per ritardare la sua presenza.
Senza chiedere a Chase Bank posso solo fare una congettura che ciò sia stato fatto per ragioni di usabilità scoperte durante la fase di test.
Leggi altre domande sui tag authentication web-browser web-application