Autenticazione chiave (token di sessione) vs autenticazione di accesso / passata predefinita

La chiave segreta sarebbe una (strong) password equivalente. Quindi, dovresti memorizzare un hash della password (perché non vuoi che qualcuno irrompa nel tuo sistema in possesso di tutte le chiavi segrete delle chiavi segrete dell'utente in un colpo solo).

A causa del requisito di hash della password, è necessario un metodo per identificare l'hash della password che è necessario confrontare con il dato segreto. Questo è normalmente fatto per mezzo di un identificatore pubblico (più comunemente il nome utente dell'utente).

Quindi, se estendi il tuo schema per utilizzare una sorta di identificatore pubblico (chiamalo ID o chiave API o qualsiasi cosa sia più appropriata nel tuo caso d'uso esatto), oltre alla chiave crittografica sicura, il tuo schema sarà meglio (a causa della "password" più strong) rispetto alla tipica combinazione nome utente-password.

Tuttavia, questo è solo un singolo elemento di una configurazione sicura: altre cose includono l'uso di SSL / TLS, un buon algoritmo di hash per la memorizzazione delle password (BCrypt per esempio) un metodo sicuro per comunicare inizialmente la chiave crittograficamente sicura all'utente, ecc ecc.

Forse mi manca qualcosa, ma mi sembra ancora di reinventare la ruota. Mentre continui ad aggiungere disposizioni per potenziali problemi, credo che convergere vicino a qualcosa che usiamo attualmente.

Penso all'autenticazione come questa:

• All'iscrizione dichiaro di essere X (il mio ID utente / email); e fornisco un segreto (la password Y) che solo tu (il sito) e conosco.
• Quando torno al login la prossima volta, ti dico che sono X; e per dimostrarlo, vi dico il segreto condiviso Y che abbiamo concordato quando mi sono iscritto. Quindi accetti di essere lo stesso X.

Nel linguaggio della sicurezza trattiamo questo come solo uno dei 3 fattori comuni. Potresti aggiungere più fattori, ma non sono in grado di vedere come possiamo ridurre il primo fattore dalla coppia di elementi di dati (X, Y) a un solo elemento di dati.

In generale, tuttavia, è assolutamente essenziale fornire UX completamente agevole agli utenti e qualsiasi tentativo in quella direzione è lodevole. Ad esempio, il modo in cui lo facciamo nella nostra app di sicurezza del sito Web ActiFend è di

• Non richiede affatto la registrazione (accesso per la prima volta = registrazione)
• Accettazione dell'autenticazione federata: utilizza il suo account Google / FB / LinkedIn e ottieni l'indirizzo email (solo quello) da lì. Se Google dice "hey ho controllato questo utente e accetto questo utente come X", è sufficiente per noi per questo scopo.
• Per coloro che desiderano un'altra opzione, inviamo un OTP basato su e-mail, in modo che non sia necessario memorizzare / salvare alcuna password; complesso o altro.

Non siamo l'unico a provare nuove idee per questo ... ad esempio, Slack utilizza "link magici" (termine descrittivo per descrivere l'autenticazione a canali alterni); Twitter e Google accettano un'autenticazione alt-channel simile (autenticati da un altro dispositivo in cui hai già effettuato l'accesso).

Ci sono molte idee - ma nessuna di queste è riuscita a ridimensionare gli elementi di dati in uno solo. Potresti nascondere uno degli elementi dell'utente (ad esempio, potresti prendere l'ID del dispositivo come X o il loro indirizzo IP come X .. ognuno con i propri problemi), ma non posso evitarlo del tutto, credo.

Non riesco a spiegarlo meglio ... Spero che questo aiuti ancora.