Impedisci l'accesso premendo Enter - sicurezza per oscurità?

Question

Impedisci l'accesso premendo Enter - sicurezza per oscurità?

#1 da (2 voti)
#2 da (0 voti)

1

Un sito di banking online che utilizzo, ha una "funzione" che impedisce a un utente di premere Invio per inviare un modulo di accesso. Ad esempio, se hai inserito il tuo nome utente nel campo Nome utente, premendo Invio verrà visualizzato il messaggio "Fai clic su Accedi per accedere".

La maggior parte degli utenti seguirebbe usando il mouse per puntare e fare clic. Tuttavia, in realtà è possibile premere semplicemente Tab per spostare lo stato attivo sul pulsante e premere Spazio per inviare il modulo.

Pensi che "prevenire l'invio di un modulo premendo Invio" o "chiedere all'utente di usare il mouse" è un caso di sicurezza per oscurità? Non stanno usando le tastiere sullo schermo, anche se credo che dovrebbero aggirare i keylogger.
Quale tipo di attacco / minaccia potrebbe aggirare questa misura?

authentication obscurity

posta jingtao 23.10.2014 - 17:27

fonte

2 risposte

Leggi altre domande sui tag authentication obscurity

IDS su account AWS separati CloudFlare: richiesto "attenzione necessaria"

score 2 · Answer 1

Sospetto che questa decisione non sia affatto legata alla sicurezza. Probabilmente hanno avuto problemi con gli utenti che cambiano accidentalmente il focus sul modulo prima che fossero pronti a causa del loro comportamento chiave di immissione. Facebook è molto cattivo su questo.

Questa azienda voleva semplicemente dare all'utente la possibilità di impedire alla chiave di invio di fare qualsiasi cosa se non inserendo un cr / lf.

score 0 · Answer 2

Alcune banche dispongono di JavaScript che crittografano / cancellano i dati sul lato client utilizzando, ad esempio, una chiave pubblica o un algoritmo hash e quindi inviandolo. Inviare il modulo con INVIO su un computer con JavaScript disabilitato, invierebbe i dettagli "in chiaro" (nota: il sito potrebbe ancora essere crittografato tramite SSL se utilizza SSL, ma i dettagli di accesso verrebbero inviati in chiaro all'interno della sessione SSL quindi un MITMer avrebbe avuto accesso a quelli rispetto a non ottenere accesso a quelli se JavaScript fosse attivo). Pertanto, un utente malintenzionato può disabilitare JavaScript per forzare la trasmissione del testo in chiaro, rimuovendo così un speedbump per l'utente malintenzionato, quindi l'autore dell'attacco deve gestire solo SSL invece di crittografia SSL + JS. Si noti che un'azione chiara="" o un'azione non specificata, invierà il modulo alla stessa pagina del modulo. Quindi non esiste un modo infallibile per disabilitare assolutamente l'invio di moduli per un computer con JavaScript disabilitato.

Il banco qui ha quindi utilizzare un tipo di input="button", che chiama una funzione JavaScript, e i campi di input, i tag modulo OUTSIDE. Ciò blocca in modo efficace il modulo per SOLO lavorare su JavaScript. Molti clienti quindi premere INVIO, che non farebbe nulla in quanto i campi di input non sono contenuti in un modulo, quindi, hanno appena aggiunto un controllo Sporco per l'immissione e, se viene premuto, mostrano solo un messaggio per utilizzare il pulsante.