Quali metodi possono essere utilizzati per prevenire nomi utente errati?

Le banche che emettono nomi utente numerici sono piuttosto fastidiose. E anche se sono più paranoico che la maggior parte, probabilmente hai ragione che qualcuno ha appena toccato il loro ID e non se ne sono accorti fino a quando non ti hanno bloccato.

Per rispondere alla domanda, alcune banche aiutano a garantire che si stia tentando di accedere con l'account utente corretto. Quelle "Immagini di sicurezza" che vedi su alcune pagine di login bancarie, sì le banche ti dicono che quelle immagini ti aiutano ad assicurarti di accedere al loro sito web. Ma il vero vantaggio è aiutare gli utenti a capire che stanno tentando di accedere all'account di qualcun altro. I siti che utilizzano questa procedura chiederanno il tuo nome utente nella pagina di accesso principale, quindi ti porteranno a una nuova pagina con la tua 'immagine di sicurezza' e il campo della password. Potrebbero anche chiedere un'altra forma di autenticazione (domanda di sicurezza, ecc.) Prima di chiedere la password se si sta effettuando l'accesso da un computer che non hanno visto il login da prima.

Se ogni volta che accedi, vedi l'immagine che hai selezionato al momento dell'iscrizione, sei più probabile (supponendo che tu usi il sito abbastanza spesso) per notare quando quell'immagine è diversa. Ciò potrebbe significare che stai effettuando l'accesso a un sito di phishing, ma più probabilmente, hai perso le dita sull'account utente.

MODIFICA: - Per rispondere alla tua modifica -

Quando si tratta di userid numerici, ci sono solo 10 cifre e sono stipati in un'area molto piccola su 10 tasti e dispositivi mobili. Considerate molte decine (o centinaia) di migliaia di utenti, la scarsità di cifre e la loro vicinanza in due dei tre layout comuni, non c'è davvero alcun modo per garantire adeguatamente che un ID sia abbastanza diverso da un altro per prevenire errori di mistyping comuni .

Inoltre, se ci si pensa da un punto di vista delle prestazioni, rilevare se un nuovo ID è uniq è un processo molto efficiente e rapido in molti sistemi ben progettati. Tuttavia, rilevare se un nuovo ID è dissimile dagli altri richiederebbe un'iterazione su ogni altro ID utente e confrontando i due con qualunque sia l'algoritmo. Questo sarebbe un processo (relativamente) lento e doloroso. Con il tempo e l'impegno necessari, è possibile memorizzare nella cache gli ngram e qualsiasi altro punto di confronto per velocizzarlo, ma comunque sarà lento.

In breve, non sono a conoscenza di alcuna azienda che lo fa su ID utente, certamente non su quelli numerici. (Ma leggerei volentieri un whitepaper o un blog di ingegneria su qualcuno che lo fa)

Un paio di altri utenti (incluso Philipp) hanno menzionato le cifre del checksum, che non ho discusso dal momento che inizialmente mi sono concentrato sul lato del sistema e sul focus dei nomi utente dissimili della domanda. Ma in un secondo momento ha un posto in questa conversazione. I checksum vengono spesso utilizzati per aumentare i numeri di conto, ad esempio i numeri delle carte di credito, che ogni studente di programmazione del primo semestre può scrivere per uno strumento di convalida. Questo elimina completamente l'errore di digitazione e può essere controllato sul lato client senza postare nel modulo di iscrizione. È impossibile dire (senza sapere a fondo) se qualcuno lo sta usando su account utente numerici ... Mi azzarderei a dire che qualcuno è, ma non l'ho visto e dal momento che non lo farebbe discussione interessante (o documentazione) all'interno della comunità, non ho sentito nessuno che lo faccia. Penso che tutti possiamo essere d'accordo, la tua banca no. :)

È possibile generare il passcode prendendo un numero consecutivo e aggiungendo una o più cifre aggiuntive che sono un checksum del numero effettivo. È possibile verificare la validità di un codice di accesso sul lato client controllando se le cifre di checksum immesse dall'utente corrispondono alla parte effettiva del codice di accesso.

Una cifra di checksum riduce la possibilità di inserire accidentalmente un codice di accesso valido di un altro utente a uno su dieci, due a uno da centinaio a tre a uno su mille.

Il rovescio della medaglia, tuttavia, è che più lungo è il passcode, più difficile è memorizzarlo, che a sua volta porterà alla gente a dimenticare i propri passcode e di nuovo a consumare risorse umane per recuperarlo. Ciò significa che il progettista del sistema deve trovare il giusto equilibrio tra gli inconvenienti generati dalle persone che immettono i passcode di altre persone e le persone che si dimenticano dei loro passcode.

Hanno impedito un attacco al tuo account. Questo è un risultato desiderato: se avessero potuto provare password illimitate, avrebbero indovinato il tuo. L'attacco è stato fermato in tempo, a costo di un piccolo inconveniente. Se questo schema è stato ripetuto per poterti seriamente infastidire, la banca può semplicemente emettere un nuovo codice di accesso casuale.

Non sono così interessati a prevenire inconvenienti non costosi quanto a prevenire costose frodi.

EDIT:

Il problema con un numero di 8 cifre assegnato casualmente è che probabilmente non lo ricorderai se non dovessi usarlo regolarmente. Come ti ricordi se il tuo numero è 82640927 o 82604927?

Qualcosa che è stato a lungo usato per ridurre gli errori di battitura è l'algoritmo della cifra di controllo Luhn. Convaliderà il numero, chiedendo al sistema di chiedere a un utente di immettere nuovamente il numero se una cifra è errata o se una coppia di cifre viene trasposta accidentalmente. Le carte di credito lo usano da decenni. Ma l'algoritmo di Luhn non preverrà tutti i problemi accidentali, né fermerà i tentativi deliberati.

Il modo migliore per ridurre le collisioni accidentali è aumentare il numero potenziale di spazio e assegnare casualmente gli utenti attraverso lo spazio numerico. Il semplice numero a 10 cifre non ferma le collisioni se gli utenti sono numerati 0000000001, 0000000002, 0000000003, ... Un modo per ottenere ciò è utilizzare un seme sequenziale, quindi inserirlo in un algoritmo hash per produrre il numero a 10 cifre ( prendere un int unsigned dei quattro byte inferiori è un modo per ottenere ciò.) È abbastanza casuale che tutti e due i numeri non abbiano una relazione l'uno con l'altro, rendendo gli errori accidentali veramente pochi e distanti tra loro. Una cifra Luhn può anche servire come controllo di cortesia per aiutare l'utente a non sprecare tempo a inserire una password su un numero di conto evidentemente difettoso.

I servizi Web possono prendere in considerazione la posizione in cui le richieste di accesso provengono e sono correlate ai tentativi di accesso passati. Simile a come le società di carte di credito ti contatteranno quando noteranno "attività insolite" sulla tua carta di credito. Questo è un elemento logico che un'organizzazione che fornisce un servizio sul Web può utilizzare per affrontare incidenti come questo. Se possono dire con certezza che il nome utente associato alla connessione non sei tu, possono prendere provvedimenti per isolare quegli eventi dall'impatto sull'account reale.

Nel tuo caso, la banca potrebbe avere la logica programmata o l'analista dedurre se l'individuo che tenta di accedere con il tuo ID account proveniva dalla stessa area o se era sicuro che si trattasse di un'area geografica completamente diversa.

Un altro percorso che aiuterebbe a dare loro un'immagine sarebbero i registri disponibili per loro dall'evento. Sembra che il rappresentante del servizio clienti che hai parlato non abbia avuto accesso a tali log e probabilmente non avrebbe avuto l'esperienza per vederli. Anche se lo facessero - a chi dire che l'applicazione registra verbosamente tali informazioni? Lo avrebbero anche voluto? Quante persone avrebbero quindi accesso a tali informazioni?

La logica di avanzamento in queste situazioni può essere complicata rapidamente. Come la tua banca in questa istanza ha gestito, sembra la risposta più semplice e meno costosa per tutti i soggetti coinvolti. Se l'unica interruzione per te in servizio è stata una telefonata di 5 minuti con la tua banca, è un modo molto basso per affrontare una situazione di danno potenzialmente elevata.

C'è un vantaggio chiave per un nome utente o una password assegnati - di solito è più casuale di quanto un utente possa generare. Per un nome utente numerico di soli 8 caratteri, ci sono 100 milioni (10 ^ 8) di permutazioni possibili. Questo è meno di 1/3 della popolazione degli Stati Uniti e circa 1/2 della popolazione dell'Indonesia. Quindi questo metodo certamente non supererà il numero di utenti di servizi bancari online.

Sì, questo significa che i nomi utente sono facilmente ipotizzabili - un utente malintenzionato deve solo ripetere i numeri a 8 cifre. Ovviamente, si dovrebbe essere molto fortunati a forzare la forza bruta in questo modo in un account di valore netto elevato.

Tuttavia, come hai sperimentato, la stessa attività può essere facilmente utilizzata per eseguire un attacco di tipo Denial of Service. Indovina casualmente la password N volte per nome utente in rapida successione (dove N è il numero di tentativi richiesti per attivare un blocco account). In poche ore, la banca dovrà verificare telefonicamente tutti i clienti bancari online e il loro call center sarà sopraffatto.

La soluzione è espandere il set di caratteri del nome utente. Consentendo anche lettere sensibili al maiuscolo / minuscolo, il numero di permutazioni si espande a 218 trilioni ((26 + 26 + 10) ^ 8), riducendo notevolmente l'efficacia del suddetto attacco di negazione del servizio, così come le collisioni accidentali come quella che sperimentato.

Lo svantaggio è che i nomi utente diventano più complessi per gli utenti da ricordare e da inserire. Questo può essere parzialmente mitigato consentendo agli utenti di scegliere i nomi utente. E il lato negativo di che è una perdita di casualità.

Una cosa che alcuni siti web, come Google, sembrano fare per prevenire questo tipo di attacco è, dopo una certa quantità di tentativi di accesso, non bloccarti, ma darti qualcosa chiamato CAPTCHA. Questo è usato di più per prevenire gli accessi bot, ma rallenta anche un utente umano malintenzionato, poiché deve ancora capire la password, e alcuni CAPTCHA sono difficili. Potrebbe anche arrecare disturbo ad un utente legittimo, ma nel momento in cui ottieni un CAPTCHA su questi siti, è probabile che tu non ricordi la tua password.

Un'altra cosa che alcuni siti sembrano fare è bloccare temporaneamente un nome utente, non in modo permanente. Ad esempio, il sito del mio college di 2 anni ti ha bloccato per 15 minuti quando hai inserito la password errata per 3 volte, quindi un ulteriore, cumulativo 5 minuti per ogni nuovo tentativo di password prima che il blocco sia attivo. Anche lo schermo di molti telefoni Android fa questo. Questo metodo potrebbe consentire attacchi DOS, poiché l'utente malintenzionato potrebbe tentare così tanti tentativi che il vero utente non sarebbe mai in grado di accedere nuovamente, sebbene il collegamento del limite di tempo a specifici IP, cookie, ecc. Potrebbe attenuare questo, tenendo presente che Gli IP possono essere falsificati.

Entrambi questi metodi funzionano più per dissuadere i bot dagli utenti umani malintenzionati, ma rallentano gli utenti umani, mentre non bloccano in modo permanente l'account dell'utente legittimo in caso di incidenti. Non sono sicuro di quanto bene ciascun metodo possa funzionare per le banche, in quanto sono molto più paranoici rispetto, ad esempio, a Google. Inoltre, la maggior parte dei siti li ho visti su nomi utente usati specificati dall'utente, ma presumo che possano funzionare anche per nomi utente numerici specificati dalla banca.