Perché ci autenticiamo chiedendo a un utente di inserire sia nome utente che password? La richiesta di password è sufficiente?

Penso che il problema sia nel richiedere che le password siano uniche. Se ho inserito la mia password desiderata e mi hai detto che non posso usarla, è già in uso, quindi so che posso accedere a un account di persone a caso con la password che avrei voluto.

Quindi, hai bisogno di un nome utente, che è unico e può essere conosciuto da tutti. Poi hai una password personale, che non è necessariamente unica, rendendo ancora più difficile da indovinare.

Mentre ci sei, hash e salvi quella password.

Ci sono già buone risposte qui, ma il semplice concetto di base è ancora mancante:

Identification and Authentication are not the same thing.

In parole povere, questi sono due requisiti separati e non devono essere confusi.
Un nome utente fornisce l'identificazione e una password consente di verificare l'identità richiesta (cioè l'autenticazione).

Vedi anche Differenza tra autenticazione e identificazione [Crypto e prospettiva di sicurezza]

Sia l'utente che l'amministratore beneficiano di un nome utente, in genere unico, che non è un segreto, che possono liberamente utilizzare per fare riferimento all'account. Se il nome utente non è univoco, può essere associato a un indirizzo email o altro identificativo univoco. In questo modo, un utente può reimpostare la propria password e ottenerne una nuova o modificarne la password senza modificare il proprio account.

Inoltre, come notato da altri, richiedere una password univoca è anche problematico quando è l'unico identificatore e c'è una collisione.

Ancora non posso commentare: (

Le tue probabilità di trovare una password sono decisamente sbagliate.

Esempio:

hai 8 utenti e amp; ogni password è lunga 64 bit (8 caratteri standard, non salati in alcun modo).

Per il caso due:

Un utente malintenzionato dovrà eseguire la sua violazione dell'algoritmo della password solo una volta per ottenere tutti gli 8 utenti (lavoro totale nel peggiore dei casi = 64 bit, 32 bit in media)

Per il caso uno:

Per rompere tutte le password un utente malintenzionato dovrà eseguire il suo algoritmo 8 volte (una volta per ogni utente), che è ovviamente più lavoro (ad esempio, lavoro totale nel peggiore dei casi = 67 bit, 33-34 bit in media)

Probabilità di violazione della password dovrebbe essere:

Per il caso uno:

1 / (2 ^ bitsUsedForPassword)

Per il secondo caso:

numberOfUsers / (2 ^ bitsUsedForPassword)

quindi il secondo caso ha più possibilità di ottenere la password, se ci sono più di un utente.

Avere un nome utente e una password è sicuramente più sicuro. Supponiamo che il tuo sito contenga un milione di utenti:

• Se si utilizza solo una password, l'autore dell'attacco deve solo indovinare una delle milioni di password valide per penetrare nel sito.

• Se utilizzi un nome utente e una password, l'utente malintenzionato deve trovare un nome utente valido e la password corretta per tale nome utente (non solo una password sul sito). Questo è un lotto più difficile per l'aggressore.

Richiedere sia un nome utente che una password offre una sicurezza molto migliore.

Esempio: Supponiamo di assumere che ogni password sia scelta in modo uniforme a caso da un insieme di un miliardo di possibilità, ad esempio un numero casuale di 9 cifre. (Sì, so che è un'ipotesi non realistica, quindi questo esempio sarà una semplificazione, ma i risultati simili si applicano a ipotesi più realistiche.)

• Se il sito richiede solo una password valida per l'accesso, un utente malintenzionato che immette numeri a 9 cifre casuali riuscirà a entrare nel sito dopo circa 1000 tentativi, in media.

• Se il sito richiede un nome utente valido e la password corrispondente per accedere, allora anche supponendo che l'utente malintenzionato conosca il nome utente di tutti, l'hacker dovrà provare circa 1.000.000.000 (un miliardo) volte prima di entrare nel sito, in media. (In realtà, metà di questo, ma qualunque cosa.)

Puoi vedere che la differenza di sicurezza è drammatica.

Inoltre, i commenti di @Justin C e @ nealmcb forniscono ulteriori motivi ortogonali per richiedere sia un nome utente che una password. Ognuno di questi motivi sarebbe sufficiente; presi insieme, il caso per richiedere sia un nome utente sia una password è molto più strong.

In teoria @Sigtran è corretto che avere un nome utente è sempre meglio, in base a una regola generale più offuscamento maggiore è la sicurezza :) Nell'implementazione, in situazioni in cui non hai bisogno di UUID o privilegi specifici dell'utente, davvero non lo fai Ho bisogno di un nome utente (qualcosa come un repository generale a cui stanno accedendo più persone). In questi scenari, richiede una password lunga e complessa (alfanumerici + caratteri speciali) e poi salarlo è la strada da percorrere.

Il motivo per cui hai bisogno sia di un nome utente sia di una password è che puoi cercare il sale univoco di quell'utente prima di eseguire l'hashing e verificare la password.

Uno schema tipico e sicuro ha una tabella utente con almeno 3 colonne: username, salt, passwordhash. Passwordhash è la password dell'utente con il suo sale unico (una combinazione casuale di caratteri univoca) aggiunta ad essa, quindi esegue l'algoritmo di hashing. L'autenticazione richiede la ricerca dell'utente per nome utente, aggiungendo il proprio sale salt alla propria password, eseguendo l'hashing del risultato e verificando che corrisponda al passwordhash nel database.

Se hai appena cancellato la password e la memorizzi nel database, un utente malintenzionato che ha accesso alla tua tabella utente può capire alcune delle password comuni utilizzando una tabella arcobaleno (elenco di password comuni). Cioè, prendono la lista delle password comuni, le cancellano tutte e vedono se qualcuno di loro corrisponde al passwordsh memorizzato nel tuo db. Se ogni utente ha un sale unico, allora dovrebbe aggiungere quel sale ad ogni password nella tabella arcobaleno, quindi cancellarli tutti, solo per vedere se trovano una corrispondenza per quell'unico utente. Quindi devono ripetere questo per ogni utente nella tua tabella. Questo aumenta enormemente il calcolo necessario per trovare una password corrispondente da una tabella utente rubata.

Oppure puoi ignorare l'intero argomento usando Open ID. Tutto ciò di cui l'utente ha bisogno è un ID di accesso o un URL e il resto è curato dal fornitore. :)