Quando ti iscrivi a un servizio, hai buone possibilità di ottenere "Questo nome è già in uso, scegli un altro" - o qualcosa del genere.

Nel sistema che proponi, questo ti dirà che il codice di accesso è in uso - ottimo, apri un nuovo browser e accedi con questo codice di accesso! Hai appena violato l'account di qualcun altro.

È possibile trovare qualsiasi numero di codici di accesso esistenti, semplicemente cercando di cambiarne uno.

Inoltre, cosa succede se hai dimenticato il tuo codice di accesso? Questo può essere mitigato se il sistema conosce il tuo indirizzo e-mail e può inviarti un nuovo codice di accesso, ma in questo caso sarai vicino a un'autenticazione a due ingressi; potresti anche usare la tua e-mail per accedere in quel momento.

Il nome utente è un identificatore , un'etichetta che indica quale utente sei e identifica le risorse che ti appartengono (o che ti fanno riferimento).

La password è un autenticatore , un modo per dimostrare che è consentito assumere tale identità utente.

I nomi degli utenti non possono essere segreti, in quanto un sistema informativo ha bisogno di questa conoscenza in chiaro, per etichettare le risorse e autorizzare l'uso delle risorse. Le password dovrebbero essere segrete, anche per il servizio e i suoi operatori - questo è il motivo per cui le password memorizzate sono sottoposte a hash con una funzione unidirezionale.

Per "risorse" sopra, sono deliberatamente inclusivo. Per un accesso utente, potrebbe trattarsi di file e processi; come utente del database, hai tabelle e altri oggetti del database; per un sito web, potrebbero essere i tuoi post e i tuoi punti reputazione.

Lo usiamo in alcuni casi.

Un esempio è la funzione condivisione tramite link dei documenti Google. Il collegamento contiene una chiave di accesso o un ID documento di 45 caratteri alfanumerici. Questo è abbastanza lungo da garantire sia l'unicità che la forzatura bruta.

Questo sistema di autenticazione a ingresso singolo sarebbe interessante, ma con alcuni problemi di sicurezza:

L'ostacolo principale è il requisito dell'unicità. Affinché utenti diversi possano accedere ai loro rispettivi account, le credenziali di accesso (in genere username + password) devono essere uniche. In teoria, ciò significa che in un tipico sistema a doppio ingresso, i nomi utente non devono necessariamente essere univoci purché non ci siano due utenti che condividono lo stesso nome utente e password. Il problema è che in un sistema a input singolo, l'unica credenziale disponibile è la singola password, il che significa che ogni utente dovrebbe avere una password diversa l'una dall'altra, e questo introduce una serie di vulnerabilità:

1. Si potrebbe supporre che in un servizio sufficientemente popolare, un qualcuno utilizzi una serie di password ovvie. Semplicemente provando ad accedere con password come "password", "12345" e "Beatles", probabilmente potresti avere almeno alcuni account.
2. Come menzionato da S.L. Barth, chiunque poteva trovare le password esistenti semplicemente provando a cambiare la loro password fino a quando non si imbattono in un messaggio "password già utilizzata". Poiché le password devono essere univoche, devi impedire a un utente di scegliere una password esistente, rivelando così che la password è già in uso.
3. Attacchi del dizionario: fondamentalmente è solo la somma logica dei punti 1 e 2. Se crei un account e poi hai uno script, prova a cambiare la password usando un dizionario delle password, registrando ogni password "già in uso" che esegue lungo la strada, è possibile creare rapidamente e facilmente un elenco di migliaia o addirittura milioni di password esistenti, che è tutto ciò che è necessario suddividere in tutti questi account.

Tieni presente che una sicurezza interessante, oltre a te, è che mentre sarebbe molto facile entrare in un numero qualsiasi di account casuali (come descritto sopra), sarebbe molto più difficile irrompere in un account qualsiasi in un attacco mirato. Poiché le password dovrebbero essere uniche, ti ritroverebbero con password più complesse in un sistema a input singolo rispetto ai sistemi dual-input di oggi e non ci sarebbe nessun nome utente che potresti utilizzare per indirizzare un particolare utente, quindi l'unico modo penetrare in un account di destinazione sarebbe forzare la tua forza in tutti degli account fino a quando non ottieni l'account che stai cercando. Inoltre, sarebbe più difficile confermare che l'account a cui hai effettuato l'accesso sia l'account che stai cercando, perché non puoi utilizzare il nome utente come prova di identità. Questo è un effetto di sicurezza davvero interessante, quindi bravo lì.

Il nome utente è un ID e non dovrebbe mai cambiare (*). Le best practice sulla sicurezza consigliano di cambiare la password su base regolare e ogni volta che potrebbe essere stata compromessa.

Poiché queste 2 parti hanno una durata diversa, è meglio tenerle separate.

(*) In effetti ci sono casi d'uso che richiedono una modifica di un nome utente, ad esempio quando c'è una fusione tra due entità e due utenti diversi usano lo stesso nome utente. Ma la durata di un nome utente dovrebbe essere molto più lunga di quella di una password

La moda della password per lo più

e in passato avrebbe richiesto ulteriori requisiti di archiviazione / elaborazione che ora sono molto più economici.

Non ci sono motivi tecnici significativi per questo

Un utente può accedere utilizzando solo una password complessa come "9so48dsf67 $ h9e6ghfoubyf2gfuDywbnefo8g2H3fg2fkngsd6_g3ty7g63gs74g" e il server potrebbe automaticamente abbinarlo con l'identità in questione e presumere che fosse corretto.

Questo è effettivamente ciò che fa Google Documenti ecc. quando genera un URL di un documento condiviso.

Lo usano solo per accedere a quel documento, non per l'identificazione.

cioè.

Non conoscono la tua identità (nessun nome di accesso)

Ma l'url autentica (è valido nel loro database)

e inoltre ti garantisce automaticamente autorizzazione (per visualizzare o modificare quel documento)

Il sistema potrebbe gestire facilmente password modificate / perse, "nickname", indirizzi email ecc.

Le persone sono MOLTO abituate a scegliere le proprie password molto più brevi e molto meno sicure che renderebbero questo approccio troppo insicuro per essere pratico

Le persone sono anche molto abituate al metodo "login" + "password" e richiederebbero una formazione significativa per comprendere e fidarsi di un'alternativa.

Wikipedia riporta quanto segue sull'autenticazione:

In contrast with identification which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing's identity, authentication is the process of actually confirming that identity.

_{(l'enfasi è mia)}

Nel mondo reale immagina di andare in banca:

1. Tu: Ciao, mi chiamo John Doe e vorrei aprire un account.
2. Impiegato: puoi fornirmi una prova della tua identità?
3. Tu: (Fornisce una carta d'identità o una patente di guida)

Al punto uno ti sei identificato come John Doe e al punto tre hai dimostrato quell'identità in un modo che la banca si fida. Nel mondo reale la tua identità veniva solitamente decisa dai tuoi genitori molto tempo fa quando sceglievano il tuo nome.

Nel mondo online, i siti che utilizzano il tradizionale processo di registrazione a due input ti consentono di scegliere la tua identità e anche il modo in cui provi quell'identità .

È vero che potresti provare a unire sia l'identità sia la prova nella stessa porzione di dati effettiva, ma c'è davvero qualche vantaggio ? L'utente nome oltre a un altro dato da utilizzare come prova è già compreso da tutti, perché corrisponde in qualche modo alla vita reale. Inoltre, rende molto più semplice l'implementazione sottostante, come è stato indicato su altre risposte e commenti.

È anche vero che essere costretti a creare sempre un'identità e una prova in ogni sito online a cui vai è piuttosto noioso . Considerando in particolare che la parte dell'identità deve essere unica all'interno di quel sito e sei un utente tardivo, il che significa che tutte le identità sono già state selezionate.

Inizialmente questo problema è stato risolto accettando il tuo indirizzo email come identità, in questo modo l'utente non ha bisogno di pensarci e l'unicità è ancora garantita.

Tuttavia, alcuni stanno addirittura facendo un passo in più e cercano di semplificare ulteriormente il processo consentendo ciò che è noto come autenticazione senza password. La cosa interessante qui è che non è necessario creare né una nuova identità né una nuova password per provare l'identità.

Un esempio di questo è l'implementazione Auth0 di autenticazione senza password che consente a un utente di autenticare in un sito tramite un link fornito tramite il loro indirizzo email o un codice monouso fornito tramite un SMS .

Passwordless connections in Auth0 allow users to login without the need to remember a password. This improves the user experience, especially on mobile applications, since users will only need an email address or phone number to register for your application.

Without passwords, your application will not need to implement a password-reset procedure and users avoid the insecure practice of using the same password for many purposes.

_{(l'enfasi è mia)}

Dal punto di vista dell'utente questo molto semplice da eseguire e dal punto di vista del sito utilizzando questo tipo di autenticazione è ancora possibile identificare gli utenti ricorrenti abbinando il proprio indirizzo email o numero di telefono.

Se ci pensi, questo è solo semplificare ciò che molti utenti usavano fare. Io, per esempio, ammetto che molte volte che volevo autenticarmi in un nuovo sito avrei semplicemente usato il mio indirizzo email e una password casuale che non avrei mai ricordato e nell'eventualità che il mio browser avesse perso la sessione o memorizzato la password avrei basta ripristinare la password.

_{Divulgazione : lavoro su Auth0.}

L'autenticazione basata su certificato PKI è un po 'come un ID utente e una password in uno.

firma la chiave pubblica

PKI

Questo non è veramente fattibile con le password. Questo è fattibile con qualsiasi schema in cui la chiave / segreto / credenziale / token / qualsiasi cosa sia memorizzata sul computer di un cliente e non all'interno del cervello umano.

contorto? Trasforma esattamente la stessa cosa in giro: se hai una chiave sufficientemente sufficiente e sufficientemente complicata / segreto / credenziale / token / qualsiasi cosa, non ha nemmeno senso chiedere ad un utente un nome utente , un nickname, un GUID, qualsiasi altro identificazione per un'autenticazione quotidiana. Il software dirà loro tutto questo.

Se il tuo software non accetta gli account suckpuppet . Ad esempio, ssh è felice con "sockpuppets", diversi account usati da un essere umano, chiede il nome dell'account anche se si fornisce una chiave RSA. Sockpuppet Le chiavi private RSA che si trovano una accanto all'altra sullo stesso dispositivo sarebbero complicazione inutile, non più sicurezza.) Chiedere un soprannome è il modo più semplice per supportare i sockpuppet.

La chiave "sufficientemente complicata" implica che non ci si aspetterebbe mai una collisione . Implica che non ci si aspetterebbe mai che sia necessario salt . Implica che il umano medio non possa ricordare . E implica che non abbiamo bisogno di ulteriori parti di complessità da parte di umani che ricordano il nome utente.

Ripristino dell'account

L'unico problema viene ripristinato dopo aver perso la chiave o dopo che è stata compromessa. Significa un dispositivo smarrito o compromesso. Qui abbiamo bisogno di usare un'autenticazione più sicura (probabilmente anche più problematica). Hai bisogno di un utente per ricordare il loro soprannome qui? Se chiedi all'utente solo il cognome da nubile di una madre, la collisione è quasi certa. Ciò non significa che tu abbia bisogno di un soprannome, significa che l'autenticazione del cognome è troppo debole! Tutti gli attacchi riguarderebbero i nomi da nubile delle madri povere. Ma probabilmente dovrai chiedere un identificatore globale fuori dall'app, molto probabilmente un numero di cellulare per la verifica tramite SMS (questo esclude la minaccia di un malintenzionato che controlla il tuo cellulare).

Lo schema alternativo è la verifica della posta elettronica, che richiede anche un identificatore globale fuori dall'app (questo esclude la minaccia di attaccante che controlla qualsiasi dispositivo, quindi è molto debole in questa impostazione).

Osserva che, nella maggior parte dei casi, gli umani non hanno bisogno di ricordare il loro identificatore globale, ma a volte hanno bisogno di andare a controllarlo e inserirlo manualmente.

Lo schema alternativo è la verifica della carta pre-condivisa: chiedi all'utente un numero di password una tantum 04 dalla scheda cartacea inviata loro quando hanno aperto un account. È un caso in cui trovo utile aumentare con un'autenticazione "banale segreto", in modo tale che quasi ogni persona che ottiene una lettera non resetta l'accesso solo per divertimento o per pura curiosità. Potrebbe essere "quale codice postale usiamo per spedire questo articolo?", Potrebbe essere il temuto nome da nubile, ma potrebbe anche usare un soprannome.

Password memorizzate dagli esseri umani

La password, o un breve testo segreto che potrebbe essere ricordato da un essere umano, è uno schema inferiore che è in ritardo da tempo. I costi non necessari associati includono:

• "effettua l'accesso" pagina
• "questo nickname è occupato" problema
• "questa password è troppo debole" problema
• bisogno di un server side-sale (aggiornando il segreto debole a uno veramente casuale per contrastare le tabelle arcobaleno)
• KeePass e database simili - soluzione complicata a un semplice problema di ottenere uno schema corretto per lavorare su vecchi prompt di accesso

Questi svaniscono tutti con uno schema di tasti memorizzato su macchina (simmetrico o asimmetrico, quest'ultimo suggerito).

Non lo usiamo perché non è pratico.

Immagina di avere un enorme database di utenti, diciamo, 8 miliardi, perché tutti sulla terra usano il tuo sito web. Qualcuno ti ha appena consegnato la chiave di input singola. Come fai a sapere se sono nel database?

Non puoi semplicemente archiviare le chiavi e cercarle perché sono fondamentalmente password di testo, e memorizzare le password in testo semplice è sbagliato. Non puoi limitarlo a poche centinaia di volte con md5 perché sei vulnerabile alle tabelle arcobaleno. È necessario utilizzare un algoritmo di hashing della password corretto come bcrypt con un grande sale casuale.

Ora hai una chiave e un grande tavolo di sali, e hai bisogno di capire quale si usa con questa chiave. Ma se potessi controllare il sale, potresti aver alzato gli occhi sulla chiave con l'hash in primo luogo! Sei bloccato.

La tua unica scelta è quella di cancellare la chiave con tutti gli 8 miliardi di sali, quindi cercare nel database 8 miliardi di volte (una volta per ogni chiave). Molte persone suggeriscono di impostare l'hashing in circa 1/10 di secondo. Immagina che: 8 miliardi di hash a 1/10 di secondo ciascuno impiegherebbe 25 anni per accedere.

A meno che i tuoi utenti non siano particolarmente pazienti, avrai bisogno di un enorme numero di computer per calcolare tutti gli hash in parallelo, il che costa un sacco di soldi, che i tuoi clienti dovranno pagare, il che rende la competizione più attraente. Altrimenti dovrai ridurre il fattore di lavoro in modo che gli hash siano facili da calcolare per te (e, per estensione, per gli attaccanti). O magari sviluppare hardware specializzato che ha lo stesso effetto di ridurre il fattore lavoro dal momento che puoi scommettere che anche gli aggressori lo compreranno.

Tutto ciò è convenientemente sfruttato lateralmente se l'utente fornisce un nome. Il nome non è segreto, quindi può essere memorizzato come testo normale nel database. Quindi il database può ordinare le sue tabelle in base al nome in modo che il server possa cercare in modo efficiente il sale che va con la password dell'utente.

Ecco perché probabilmente avremo sempre nomi utente in una forma o nell'altra: abbiamo bisogno di una chiave di ricerca per rendere efficiente il processo di login, e le richieste di password salate e hash rendono qualsiasi cosa simile alla password un cattivo candidato per l'attività.