I siti che controllano la tua password durante la digitazione rappresentano un rischio per la sicurezza?

I moderni crittosistemi non sono generalmente suscettibili agli attacchi con testo in chiaro. In termini di algoritmi di crittografia, ci sono fondamentalmente 3 algoritmi comunemente in uso in TLS:

1. AES
2. RC4
3. DES (in 3DES)

Tutti e 3 di questi sono ritenuti resistenti agli attacchi con testo in chiaro e sono stati ben studiati per tali attacchi.

L'unica cosa che mi chiedo sono gli attacchi da canale laterale. Ci sono (potenzialmente) diversi pezzetti di informazioni trapelati sulla tua password, ma quelli che posso pensare a tutti richiedono un aggressore che sia in grado di osservare il tuo traffico (ovviamente, così come l'attacco di testo in chiaro che hai chiesto).

1. Se la compressione TLS è abilitata (cosa che in realtà non dovrebbe essere, dato l'attacco CRIME ) e un utente malintenzionato è in grado di indovinare correttamente tutti gli altri dati inviati nella richiesta (che non è difficile se non ci sono cookie unici), quindi è possibile che siano in grado di capire la tua password inviando sottostringhe e vedendo quali si comprimono stessa lunghezza della tua password.

2. Attacchi a tempo. A seconda della velocità con cui il JavaScript invia richieste al server dopo aver digitato i tasti e i tuoi schemi di battitura, un utente malintenzionato può distinguere (o almeno restringere) i caratteri che stai digitando in base agli intervalli tra i pacchetti (che indica la intervalli tra le sequenze di tasti). Questo attacco è stato dimostrato contro SSH di Song et. al. nel 2001, quindi non è esattamente un romanzo, solo un romanzo per HTTPS. (Generalmente HTTPS non è in tempo reale, ma ciò che stai descrivendo lo rende approssimativamente in tempo reale.)

3. La lunghezza della password. L'autore dell'attacco può misurare il numero di pacchi inviati al server e le loro dimensioni e fare una buona stima della lunghezza dal numero di caratteri digitati. Conoscere la lunghezza di una password riduce la base di 1. Quindi, invece di dover indovinare le password 11 ^ 5, l'utente malintenzionato deve solo indovinare 10 ^ 5 password per le password numeriche.

Nel complesso, questo non è quello di cui mi preoccuperei. È molto più probabile che questo sito Web sia vulnerabile alle vulnerabilità XSS, SQL injection, di gestione delle sessioni, ecc., Piuttosto che un utente malintenzionato utilizzerà questa tecnica "avanti e indietro" per compromettere il tuo account.

Se non altro, è un'API per il controllo delle password senza ritardi . Deve essere: se avessero avuto un ritardo di tempo dopo ogni ipotesi errata, avrebbe sconfitto il punto di verifica del live della password. Se la password è "password", il server deve controllare sette password errate prima di raggiungere quella corretta e non è possibile avere un ritardo dopo ogni pressione di un tasto. Un utente potrebbe aggirare questo tagliando / incollando la password da qualche altra parte, ma questo non è un comportamento che vogliamo incoraggiare.

Per ragioni simili, questa API quasi certamente non blocca le persone dopo ripetuti tentativi errati . Anche se così fosse, la soglia è probabilmente inaccettabilmente alta. Un cracker basato su malware funzionerebbe particolarmente bene qui: potrebbe raschiare il disco rigido di un utente per le password probabili, quindi emulare copia / incolla in modo tale da sprecare solo un'ipotesi per intera password invece di lunghezza - 1 .

Le persone che implementano questo tipo di correttore significano bene, ma il concetto alla base di esso è fondamentalmente imperfetto. Nessuno dovrebbe farlo. Ti stai solo aprendo agli attacchi malevoli, per nessun vero guadagno di UX.

Forse una domanda stupida, ma sei sicuro di non ottenere un ✓ che significa che la password che hai inserito ha soddisfatto i requisiti minimi per la politica della password dei siti? Tale che il codice lato client sta dicendo "sì, questa è una password valida e lo accetterò, anche se non ho ancora convalidato la correttezza." Quando inserisci la password come "password1234" è ancora una ✓?

Riesco a vedere un problema con sever qui: puoi provare a forzare la forza bruta mentre il server esegue il sollevamento pesante. Nel caso di un server sufficientemente potente, l'hacker ha buone probabilità di successo con costi di elaborazione minimi o nulli (lato client). Se il server è troppo debole, apre un bel canale per un attacco denial of service.

L'ultima volta che ho controllato, era considerato una buona pratica introdurre un piccolo (casuale) sonno prima di restituire i risultati; controllare la password per ogni carattere digitato sembra funzionare a ritroso da questo.

Non vedo alcun motivo per cui la password incompleta venga mai inviata al server - il client conosce le regole della password (cioè 8 caratteri, deve contenere il numero, ecc.) e può convalidarlo e visualizzare lo stato all'utente prima di inviare qualsiasi richiesta