Quando (se mai) la web app deve forzare gli accessi numerici, generati (quindi difficili da ricordare)?

Secondo me, mai.

Come hai detto tu, una politica di password corretta serve già allo scopo di ridurre la probabilità che un attacco di bruteforce abbia successo.

Forzare i numeri generati casualmente su un utente è un modo sicuro per darti un mal di testa, poiché il numero della richiesta "Password dimenticata" sarà travolgente.

Peggiore caso: costringe l'utente a scrivere il numero in un posto facile da trovare.

Non sono d'accordo con la premessa della tua domanda. Penso che lo schema della tua banca sia più sicuro che non consentire agli utenti di scegliere le proprie password.

Una cosa che sappiamo con grande sicurezza è che molti utenti scelgono password scadenti . Ad esempio, uno studio recente ha rilevato che se l'attaccante è valutato -limitato a 10 tentativi di password per account, quindi l'autore dell'attacco può aspettarsi di rompi circa l'1% degli account. Questi numeri sembrano essere abbastanza robusti su una vasta gamma di diversi tipi di sistemi protetti da password. Pertanto, qualsiasi sistema che consente agli utenti di selezionare le proprie password avrà una scarsa sicurezza per una frazione significativa della popolazione di utenti.

Al contrario, la tua banca genera la password per te. Ciò evita i problemi delle password generate dall'utente. Una password casuale a 8 cifre ha circa 26,6 bit di entropia. Non è troppo malandato. Ad esempio, se l'autore dell'attacco è limitato a 10 tentativi di password per account, quindi con lo schema della tua banca, l'attaccante può aspettarsi una violazione dello 0,00001% dei conti. Questo è un miglioramento significativo rispetto alle password generate dagli utenti.

Al contrario, le politiche di complessità della password sono fragili. Aiutano gli utenti a evitare alcune password errate, ma molte altre password errate sono spesso accettate. Fondamentalmente, poiché il controllore della politica delle password non ha visibilità su come hai scelto la tua password, e poiché come è la parte importante per calcolare l'entropia, sono limitate nella loro utilità. Per molti siti, queste limitazioni sono accettabili, ma posso capire perché un sito bancario potrebbe voler fare meglio.

Una possibile preoccupazione per lo schema della tua banca è che, se non implementano alcuna limitazione della velocità di indentazione della password, un utente malintenzionato che continua a provare tutte le possibili password a 8 cifre può essere in grado di indovinare la tua password. Se l'utente malintenzionato può automatizzare questo processo e provare 10 password / secondo, è necessario impiegare circa 115 giorni per esaurire lo spazio. Tuttavia, questo tipo di attacco è facile da difendere: la banca può semplicemente contare il numero di tentativi falliti di indovinare la password e il limite di velocità indovina o imporre qualche altra difesa contro l'identificazione automatica delle password.

Conclusione: l'approccio della banca è in realtà più ragionevole di quanto possa sembrare. Nel complesso, è probabilmente più sicuro che consentire agli utenti di scegliere le proprie password, specialmente se la banca applica meccanismi validi per limitare gli attacchi di individuazione delle password.

In uno scenario di banche, i soliti criteri di sicurezza bloccano un account utente quando vengono immesse password errate più volte. Quando l'ID di accesso è casuale, la possibilità per un utente malintenzionato di scegliere casualmente un ID di accesso e tentare di bloccare o bloccare l'accesso all'account si riduce di considerevole quantità. È necessario un compromesso tra sicurezza e requisiti aziendali, che è sempre una sfida nel mondo digitale.

Dubito che la banca consideri questo un problema di sicurezza. Piuttosto è un detal di implementazione.

Avendo lavorato per poche banche, posso dire che il numero di sistemi legacy di cui hanno bisogno per supportare e i problemi di interoperabilità che devono affrontare è davvero sorprendente. È già abbastanza brutto quando una banca esiste da 60 anni e continua a supportare sistemi originariamente gestiti su mainframe IBM, ma al giorno d'oggi la maggior parte delle banche ha attraversato diverse fusioni e ha avuto la sfida aggiuntiva di combinare interi ecosistemi di diverse banche. Il numero di casi speciali è sorprendente.

Molto probabilmente la banca ha deciso che era solo troppo difficile più lavoro di quanto non volessero fare per creare un meccanismo robusto affinché un utente potesse creare il proprio nome utente univoco che avrebbe funzionato su tutte le banche sistemi. Non lo considererebbero un rischio per la sicurezza se annoti il tuo nome utente fintanto che hai mantenuto segreta la tua password. Mentre potrebbe essere bello che i clienti scelgano il proprio nome utente, potrebbe anche essere necessario creare un altro sistema per gestire i nomi utente e creare un altro sistema di registrazione con costi amministrativi associati, poiché questo nuovo sistema dovrebbe anche essere disponibile al 100% con disaster recovery e pianificazione della continuità aziendale.