Autenticazione basata su moduli per siti Web

Riteniamo che Stack Overflow non dovrebbe essere solo una risorsa per domande tecniche molto specifiche, ma anche per linee guida generali su come risolvere le variazioni su problemi comuni. "Autenticazione basata su form per siti Web" dovrebbe essere un ottimo argomento per un simile esperimento.

Dovrebbe includere argomenti come:

• Come accedere
• Come disconnettersi
• Come rimanere connesso
• Gestione dei cookie (comprese le impostazioni consigliate)
• Crittografia SSL / HTTPS
• Come archiviare le password
• Usando domande segrete
• Funzionalità dimenticata per nome utente / password
• Uso di nonces per prevenire falsi di richieste tra siti (CSRF)
• OpenID
• Casella di controllo "Ricordami"
• Completamento automatico del browser di nomi utente e password
• URL segreti ( URL pubblico protetto da digest)
• Verifica della validità della password
• Convalida e-mail
• e molto altro sull'autenticazione basata su form ...

Non dovrebbe includere cose come:

• Ruoli e autorizzazione
• Autenticazione di base HTTP

Aiutateci per:

1. Suggerendo argomenti secondari
2. Invio di buoni articoli su questo argomento
3. Modifica della risposta ufficiale

PARTE I: Come accedere

Supponiamo che tu sappia già come creare un modulo HTML login + password che POST invii i valori a uno script sul lato server per l'autenticazione. Le sezioni seguenti tratteranno i modelli per un'autentica pratica pratica e come evitare le più comuni insidie ​​della sicurezza.

A HTTPS o non a HTTPS?

A meno che la connessione non sia già sicura (ovvero, tunneling tramite HTTPS tramite SSL / TLS), i valori del modulo di accesso verranno inviati in chiaro, il che consente a chiunque di intercettare sulla linea tra browser e server Web sarà in grado di leggere gli accessi mentre passano attraverso. Questo tipo di intercettazioni telefoniche viene eseguito di routine dai governi, ma in generale non affronteremo i fili "di proprietà" se non per dirlo: basta usare HTTPS.

In sostanza, l'unico modo pratico per proteggere dalle intercettazioni telefoniche / sniffing dei pacchetti durante l'accesso è utilizzare HTTPS o un altro schema di crittografia basato su certificati (ad esempio TLS ) o uno schema di risposta alla sfida collaudato (ad esempio Diffie-Hellman basato su SRP). Qualsiasi altro metodo può essere facilmente aggirato da un attaccante intercettativo.

Naturalmente, se sei disposto a diventare un po 'poco pratico, potresti anche utilizzare una qualche forma di schema di autenticazione a due fattori (ad esempio l'app Google Authenticator, un libro di codici fisico in stile "guerra fredda" o un dongle di generatore di chiavi RSA). Se applicato correttamente, potrebbe funzionare anche con una connessione non protetta, ma è difficile immaginare che uno sviluppatore sarebbe disposto a implementare l'autenticazione a due fattori ma non SSL.

(Non) Roll-your-own crittografia / hashing JavaScript

Dati i costi percepiti (sebbene ora evitabili ) e la difficoltà tecnica di impostare un certificato SSL sul tuo sito Web, alcuni sviluppatori sono tentati di implementare i propri schemi di hashing o crittografia nel browser per evitare di passare accessi in testo non crittografato su un filo non protetto.

Sebbene questo sia un pensiero nobile, è essenzialmente inutile (e può essere un difetto di sicurezza ) a meno che non sia combinato con uno dei precedenti - ovvero, proteggere la linea con una crittografia avanzata o utilizzare una risposta alla sfida collaudata meccanismo (se non sai di cosa si tratta, sappi solo che è uno dei concetti più difficili da dimostrare, più difficili da progettare e più difficili da implementare nella sicurezza digitale).

Sebbene sia vero che l'hashing della password può essere efficace contro la divulgazione della password , è vulnerabile a ripetere gli attacchi, gli attacchi / dirottamenti Man-In-The-Middle (se un attaccante può iniettare qualche byte nella tua pagina HTML non protetta prima che raggiunga il tuo browser, possono semplicemente commentare l'hash nel JavaScript) o attacchi di forza bruta (dato che stai consegnando all'aggressore sia username, salt che hash password).

CAPTCHAS contro l'umanità

CAPTCHA ha lo scopo di contrastare una specifica categoria di attacco: dizionario automatizzato / prova di forza bruta e errore senza operatore umano. Non c'è dubbio che questa sia una vera minaccia, tuttavia, ci sono modi per gestirla senza problemi che non richiedono un CAPTCHA, schemi di limitazione dell'accesso lato server appositamente progettati, ne discuteremo più avanti.

Sappi che le implementazioni CAPTCHA non sono create allo stesso modo; spesso non sono risolvibili per l'uomo, la maggior parte di essi è effettivamente inefficace contro i robot, tutti sono inefficaci contro la manodopera a basso costo del terzo mondo (secondo OWASP , l'attuale tasso di sweatshop è di $ 12 per 500 test) e alcune implementazioni potrebbero essere tecnicamente illegale in alcuni paesi (consultare il Foglio informativo sull'autenticazione OWASP ). Se è necessario utilizzare un CAPTCHA, utilizzare reCAPTCHA di Google , poiché per definizione è difficile da OCR (poiché utilizza scansioni di libri già classificate erroneamente in OCR) e si impegna molto per essere intuitivo.

Personalmente, tendo a trovare fastidiosi CAPTCHAS, e li uso solo come ultima risorsa quando un utente non è riuscito ad accedere più volte e i ritardi di limitazione sono al massimo. Ciò accadrà raramente per essere accettabile e rafforza il sistema nel suo insieme.

Memorizzazione delle password / Verifica degli accessi

Questa potrebbe essere una conoscenza comune dopo tutti gli hack molto pubblicizzati e le perdite di dati degli utenti che abbiamo visto negli ultimi anni, ma va detto: non archiviare le password in chiaro nel database. I database degli utenti vengono sistematicamente hackerati, trapelati o ripuliti tramite l'iniezione SQL e, se si memorizzano password non crittografate, è un gioco istantaneo per la sicurezza dell'accesso.

Quindi, se non riesci a memorizzare la password, come puoi verificare che la combinazione login + password POSTED dal modulo di login sia corretta? La risposta è hashing usando una funzione di derivazione chiave . Ogni volta che viene creato un nuovo utente o viene modificata una password, si prende la password e la si esegue attraverso un KDF, come Argon2, bcrypt, scrypt o PBKDF2, trasformando la password in chiaro ("correcthorsebatterystaple") in una lunga stringa dall'aspetto casuale , che è molto più sicuro da archiviare nel database. Per verificare un accesso, si esegue la stessa funzione hash sulla password immessa, questa volta passando in salt e confrontando la stringa hash risultante con il valore memorizzato nel database. Argon2, bcrypt e scrypt memorizzano già il sale con l'hash. Dai un'occhiata a questo articolo su sec.stackexchange per informazioni più dettagliate.

Il motivo per cui viene utilizzato un sale è che l'hash in sé non è sufficiente: ti consigliamo di aggiungere un cosiddetto "sale" per proteggere l'hash dai tavoli arcobaleno . Un salt impedisce in modo efficace che due password che corrispondono esattamente vengano memorizzate come lo stesso valore di hash, impedendo che l'intero database venga scansionato in una corsa se un attaccante sta eseguendo un tentativo di indovinare la password.

Un hash crittografico non deve essere utilizzato per l'archiviazione delle password perché le password selezionate dall'utente non sono abbastanza forti (cioè non contengono in genere abbastanza entropia) e un attacco che indovina la password potrebbe essere completato in un tempo relativamente breve da un utente malintenzionato con accesso agli hash. Questo è il motivo per cui vengono utilizzati i KDF: questi effettivamente "allungano la chiave" , il che significa che ogni password indovina un attaccante provoca ripetizioni multiple dell'algoritmo hash, ad esempio 10.000 volte, che induce l'attaccante a indovinare la password 10.000 volte più lentamente.

Dati della sessione - "Hai effettuato l'accesso come Spiderman69"

Una volta che il server ha verificato l'accesso e la password nel database dell'utente e ha trovato una corrispondenza, il sistema ha bisogno di un modo per ricordare che il browser è stato autenticato. Questo fatto dovrebbe essere sempre e solo archiviato sul lato server nei dati della sessione.

Se non si ha familiarità con i dati della sessione, ecco come funziona: una singola stringa generata casualmente viene archiviata in un cookie in scadenza e utilizzata per fare riferimento a una raccolta di dati, i dati della sessione, memorizzati sul server. Se si utilizza un framework MVC, questo è già sicuramente gestito.

Se possibile, assicurati che il cookie di sessione abbia i flag di sicurezza e Solo HTTP impostati quando inviati al browser. Il flag HttpOnly fornisce una certa protezione contro il cookie letto attraverso l'attacco XSS. Il contrassegno sicuro garantisce che il cookie venga rispedito solo tramite HTTPS e quindi protegge dagli attacchi di sniffing della rete. Il valore del cookie non dovrebbe essere prevedibile. Quando viene presentato un cookie che fa riferimento a una sessione inesistente, il suo valore deve essere sostituito immediatamente per impedire la fissazione della sessione .

PARTE II: Come rimanere connesso - La famigerata casella di controllo "Ricordami"

I cookie di accesso persistenti (funzionalità "Ricordami") sono una zona pericolosa; da un lato, sono completamente sicuri come gli accessi convenzionali quando gli utenti comprendono come gestirli; e d'altra parte, rappresentano un enorme rischio per la sicurezza nelle mani di utenti negligenti, che possono usarli su computer pubblici e dimenticare di disconnettersi e che potrebbero non sapere quali sono i cookie del browser o come eliminarli.

Personalmente, mi piacciono gli accessi permanenti per i siti Web che visito regolarmente, ma so come gestirli in modo sicuro. Se sei sicuro che i tuoi utenti conoscano lo stesso, puoi usare accessi persistenti con coscienza pulita. Altrimenti, allora puoi iscriverti alla filosofia secondo cui gli utenti che sono disattenti con le loro credenziali di accesso se la sono presa se vengono hackerati. Non è come andare nelle case dei nostri utenti e strappare tutti quegli appunti Post-It che inducono il viso con password che hanno allineato sul bordo dei loro monitor.

Naturalmente, alcuni sistemi non possono permettersi di hackerare alcun account; per tali sistemi, non è possibile giustificare un accesso persistente.

Se decidi di implementare cookie di accesso persistenti, ecco come farlo:

1. Prima di tutto, prenditi del tempo per leggere l'articolo sull'Iniziativa Paragon . Avrai bisogno di avere un sacco di elementi giusti e l'articolo fa un ottimo lavoro nel spiegarli.

2. E solo per ribadire una delle insidie ​​più comuni, NON MEMORIZZARE IL COOKIE DI ACCESSO PERSISTENTE (TOKEN) NEL TUO DATABASE, SOLO UN TRATTAMENTO! Il token di accesso è equivalente alla password, quindi se un utente malintenzionato mette le mani sul database, può utilizzare i token per accedere a qualsiasi account, proprio come se fossero combinazioni di login-password in chiaro. Pertanto, utilizzare l'hash (secondo https://security.stackexchange.com/a/63438/5002 un hash debole funzionerà bene a questo scopo) quando si memorizzano token di accesso persistenti.

PARTE III: Uso di domande segrete

Non implementare "domande segrete" . La funzione "domande segrete" è un modello di sicurezza. Leggi l'articolo dal link numero 4 dall'elenco DEVE LEGGERE. Puoi chiedere a Sarah Palin di questo, dopo il suo Yahoo! l'account e-mail è stato violato durante una precedente campagna presidenziale perché la risposta alla sua domanda di sicurezza era ... "Wasilla High School"!

Anche con domande specifiche dell'utente, è molto probabile che la maggior parte degli utenti scelga:

• Una domanda segreta "standard" come il nome da nubile della madre o l'animale preferito

• Una semplice curiosità che chiunque potrebbe sollevare dal proprio blog, profilo LinkedIn o simili

• Qualsiasi domanda a cui è più facile rispondere che indovinare la propria password. Che, per qualsiasi password decente, è ogni domanda che puoi immaginare

In conclusione, le domande di sicurezza sono intrinsecamente insicure in praticamente tutte le loro forme e varianti e non devono essere utilizzate in uno schema di autenticazione per nessun motivo.

Il vero motivo per cui esistono anche domande sulla sicurezza in natura è che risparmiano comodamente il costo di alcune chiamate di supporto da parte di utenti che non possono accedere alla loro e-mail per ottenere un codice di riattivazione. Questo a scapito della sicurezza e della reputazione di Sarah Palin. Ne e 'valsa la pena? Probabilmente no.

PARTE IV: Funzionalità password dimenticata

Ho già menzionato il motivo per cui non dovresti mai usare le domande di sicurezza per gestire le password degli utenti dimenticate / perse; Va da sé che non si dovrebbe mai e-mail agli utenti le loro password effettive. Ci sono almeno altre due insidie ​​fin troppo comuni da evitare in questo campo:

1. Non reimpostare una password dimenticata su una password complessa generata automaticamente - tali password sono notoriamente difficili da ricordare, il che significa che l'utente deve modificarlo o scriverlo - diciamo, su un Post-It giallo brillante sul bordo del monitor. Invece di impostare una nuova password, lascia che gli utenti ne scelgano subito una nuova, che è comunque ciò che vogliono fare. (Un'eccezione a ciò potrebbe essere se gli utenti utilizzano universalmente un gestore di password per archiviare / gestire password che sarebbero normalmente impossibili da ricordare senza scriverle).

2. Crea sempre l'hash nel codice / token della password persa nel database. DI NUOVO , questo codice è un altro esempio di password equivalente, quindi DEVE essere sottoposto a hash nel caso in cui un utente malintenzionato abbia messo le mani sul database. Quando viene richiesto un codice password perso, invia il codice in chiaro all'indirizzo e-mail dell'utente, quindi esegui l'hash, salva l'hash nel tuo database e getta l'originale . Proprio come una password o un token di accesso persistente.

Un'ultima nota: assicurati sempre che la tua interfaccia per l'immissione del "codice password perso" sia sicura almeno quanto il modulo di accesso stesso, altrimenti un utente malintenzionato lo utilizzerà semplicemente per ottenere l'accesso. Accertarsi di generare "codici password persi" molto lunghi (ad esempio, 16 caratteri alfanumerici con distinzione tra maiuscole e minuscole) è un buon inizio, ma si consiglia di aggiungere lo stesso schema di limitazione utilizzato per il modulo di accesso stesso.

PARTE V: Verifica della forza della password

Per prima cosa, ti consigliamo di leggere questo piccolo articolo per un controllo di realtà: le 500 password più comuni

Va bene, quindi forse l'elenco non è l' elenco canonico delle password più comuni su qualsiasi sistema in qualsiasi luogo , ma è una buona indicazione di come le persone scarsamente sceglieranno le loro password quando non esiste una politica applicata. Inoltre, l'elenco appare spaventosamente vicino a casa quando lo si confronta con le analisi disponibili al pubblico delle password rubate di recente.

Quindi: senza requisiti minimi di sicurezza delle password, il 2% degli utenti utilizza una delle 20 principali password più comuni. Significato: se un attaccante ottiene solo 20 tentativi, 1 su 50 account sul tuo sito Web sarà crackabile.

Per contrastare ciò è necessario calcolare l'entropia di una password e quindi applicare una soglia. La pubblicazione speciale NIST (National Institute of Standards and Technology) 800-63 ha una serie di ottimi suggerimenti. Ciò, se combinato con un'analisi del layout di tastiera e dizionario (ad esempio, "qwertyuiop" è una password errata), può rifiutare il 99% di tutte le password scarsamente selezionate a un livello di entropia di 18 bit. Il semplice calcolo della sicurezza della password e la visualizzazione di un misuratore della forza visiva per un utente è buono, ma insufficiente. A meno che non venga applicato, molti utenti lo ignoreranno molto probabilmente.

E per una rinfrescante comprensione della facilità d'uso delle password ad alta entropia, xkcd di password password Randall Munroe è altamente raccomandato.

Utilizza l' API Have I Been Pwned di Troy Hunt per verificare le password degli utenti rispetto alle password compromesse nelle violazioni dei dati pubblici.

PARTE VI: Molto altro - Oppure: Prevenire i tentativi di accesso al fuoco rapido

Innanzitutto, dai un'occhiata ai numeri: Velocità di recupero password - Per quanto tempo rimarrà la tua password

Se non hai il tempo di consultare le tabelle in quel link, ecco l'elenco di loro:

1. Ci vuole praticamente nessun tempo per rompere una password debole, anche se si sta di cracking con un abaco

2. Non ci vuole praticamente tempo per decifrare una password alfanumerica di 9 caratteri se non fa distinzione tra maiuscole e minuscole

3. Ci vuole praticamente nessun tempo per rompere un intricato, simboli-e-lettere-e-numeri, la password in alto a e-minuscolo se è lungo meno di 8 caratteri (un PC desktop può cercare l'intero spazio delle chiavi fino a 7 caratteri in una questione di giorni o addirittura ore)

4. Tuttavia, occorrerebbe una quantità eccessiva di tempo per decifrare anche una password di 6 caratteri, se si fosse limitati a un tentativo al secondo!

Quindi cosa possiamo imparare da questi numeri? Bene, un sacco, ma possiamo concentrarci sulla parte più importante: il fatto che prevenire un gran numero di tentativi di accesso successivi a fuoco rapido (cioè l' attacco di forza bruta ) non è poi così difficile. Ma prevenirlo nel modo giusto non è così facile come sembra.

In generale, hai tre opzioni che sono tutte efficaci contro gli attacchi di forza bruta (e gli attacchi del dizionario, ma poiché stai già impiegando una solida politica di password, non dovrebbero essere un problema) :

• Presenta un CAPTCHA dopo N tentativi falliti (fastidiosamente infernali e spesso inefficaci - ma mi sto ripetendo qui)

• Blocco degli account e richiesta di verifica tramite e-mail dopo N tentativi falliti (si tratta di un attacco DoS in attesa di verificarsi)

• E infine, la limitazione del login : ovvero, impostare un ritardo tra i tentativi dopo N falliti tentativi (sì, gli attacchi DoS sono ancora possibili, ma almeno sono molto meno probabili e molto più complicati da realizzare).

Best practice n. 1: un breve ritardo che aumenta con il numero di tentativi falliti, come:

• 1 tentativo fallito = nessun ritardo
• 2 tentativi falliti = 2 secondi di ritardo
• 3 tentativi falliti = 4 secondi di ritardo
• 4 tentativi falliti = 8 secondi di ritardo
• 5 tentativi falliti = ritardo di 16 secondi
• eccetera.

L'attacco a questo schema sarebbe molto impraticabile, poiché il tempo di blocco risultante è leggermente più grande della somma dei precedenti tempi di blocco.

Per chiarire: il ritardo non è un ritardo prima di restituire la risposta al browser. È più simile a un periodo di timeout o refrattario durante il quale i tentativi di accesso a un account specifico o da un indirizzo IP specifico non saranno accettati o valutati affatto. In altre parole, le credenziali corrette non verranno restituite in caso di accesso riuscito e le credenziali errate non determineranno un aumento del ritardo.

Best practice n. 2: un ritardo di media durata che entra in vigore dopo N tentativi falliti, come:

• 1-4 tentativi falliti = nessun ritardo
• 5 tentativi falliti = ritardo di 15-30 minuti

Attaccare questo schema sarebbe piuttosto poco pratico, ma sicuramente fattibile. Inoltre, potrebbe essere rilevante notare che un ritardo così lungo può essere molto fastidioso per un utente legittimo. Gli utenti dimenticati non apprezzeranno te.

Best practice n. 3: Combinazione dei due approcci: un ritardo fisso e breve che diventa effettivo dopo N tentativi falliti, come:

• 1-4 tentativi falliti = nessun ritardo
• 5+ tentativi falliti = 20 secondi di ritardo

Oppure, un ritardo crescente con un limite superiore fisso, come:

• 1 tentativo fallito = 5 secondi di ritardo
• 2 tentativi falliti = ritardo di 15 secondi
• 3+ tentativi falliti = ritardo di 45 secondi

Questo schema finale è stato preso dai suggerimenti sulle migliori pratiche di OWASP (collegamento 1 dall'elenco MUST-READ) e dovrebbe essere considerato la migliore prassi, anche se è certamente sul lato restrittivo.

Come regola empirica, tuttavia, direi: più forte è la tua politica di password, meno devi infastidire gli utenti con ritardi. Se hai bisogno di password alfanumeriche forti (maiuscole / minuscole + numeri e simboli richiesti) 9+ caratteri, potresti dare agli utenti 2-4 tentativi di password non ritardati prima di attivare la limitazione.

L'attacco a questo schema di limitazione del login finale sarebbe molto impraticabile. E come tocco finale, consenti sempre agli accessi persistenti (cookie) (e / o un modulo di accesso verificato da CAPTCHA) di passare, in modo che gli utenti legittimi non vengano nemmeno ritardati mentre l'attacco è in corso . In questo modo, l'attacco DoS molto poco pratico diventa un attacco estremamente poco pratico.

Inoltre, ha senso fare un throttling più aggressivo sugli account di amministrazione, poiché questi sono i punti di ingresso più interessanti

PARTE VII: Attacchi di forza bruta distribuiti

A parte questo, gli aggressori più avanzati cercheranno di aggirare il throttling di accesso "diffondendo le loro attività":

• Distribuire i tentativi su una botnet per impedire la segnalazione dell'indirizzo IP

• Invece di scegliere un utente e provare le 50.000 password più comuni (che non possono, a causa della nostra limitazione), sceglieranno LA password più comune e la proveranno invece contro 50.000 utenti. In questo modo, non solo aggirano misure di massimo tentativo come CAPTCHA e limitazione del login, ma aumentano anche le loro possibilità di successo, poiché la password più comune numero 1 è molto più probabile rispetto al numero 49.995

• Distanziare le richieste di accesso per ciascun account utente, diciamo, a distanza di 30 secondi, per sgattaiolare sotto il radar

Qui, la migliore pratica sarebbe quella di registrare il numero di accessi non riusciti, a livello di sistema , e utilizzare una media corrente della frequenza di accesso errato del tuo sito come base per un limite superiore che imponi quindi a tutti gli utenti.

Troppo astratto? Lasciami riformulare:

Supponiamo che il tuo sito abbia avuto in media 120 accessi non validi al giorno negli ultimi 3 mesi. Usando quello (media corrente), il tuo sistema potrebbe impostare il limite globale a 3 volte quello - cioè. 360 tentativi falliti per un periodo di 24 ore. Quindi, se il numero totale di tentativi falliti su tutti gli account supera quel numero entro un giorno (o anche meglio, controlla la velocità di accelerazione e si attiva su una soglia calcolata), attiva la limitazione dell'accesso a livello di sistema, il che significa brevi ritardi per TUTTI gli utenti (sempre, ad eccezione degli accessi ai cookie e / o degli accessi CAPTCHA di backup).

Ho anche pubblicato una domanda con maggiori dettagli e una discussione davvero valida su come evitare insidie nel respingere gli attacchi di forza bruta distribuita

PARTE VIII: Provider di autenticazione e autenticazione a due fattori

Le credenziali possono essere compromesse, a causa di exploit, password scritte e perse, laptop con chiavi rubate o utenti che accedono a siti di phishing. Gli accessi possono essere ulteriormente protetti con l'autenticazione a due fattori, che utilizza fattori fuori banda come codici monouso ricevuti da una telefonata, un messaggio SMS, un'app o un dongle. Diversi provider offrono servizi di autenticazione a due fattori.

L'autenticazione può essere completamente delegata a un servizio Single Sign-On, in cui un altro provider gestisce la raccolta delle credenziali. Ciò spinge il problema a una terza parte attendibile. Google e Twitter forniscono entrambi servizi SSO basati su standard, mentre Facebook fornisce una soluzione proprietaria simile.

LINK DA LEGGERE Informazioni sull'autenticazione Web

1. Guida OWASP all'autenticazione / Foglio informativo sull'autenticazione OWASP
2. Cosa fare e cosa non fare dell'Autenticazione client sul Web (documento di ricerca MIT molto leggibile)
3. Wikipedia: cookie HTTP
4. Domande sulla conoscenza personale per l'autenticazione di fallback: domande sulla sicurezza nell'era di Facebook (documento di ricerca Berkeley molto leggibile)

Articolo definitivo

Invio di credenziali

L'unico modo pratico per inviare le credenziali in modo sicuro al 100% è utilizzando SSL . L'uso di JavaScript per l'hash della password non è sicuro. Insidie ​​comuni per l'hash delle password lato client:

• Se la connessione tra client e server non è crittografata, tutto ciò che fai è vulnerabile agli attacchi man-in-the-middle . Un utente malintenzionato potrebbe sostituire il javascript in arrivo per interrompere l'hash o inviare tutte le credenziali al proprio server, potrebbe ascoltare le risposte dei client e impersonare perfettamente gli utenti, ecc. Ecc. SSL con autorità di certificazione affidabili è progettato per prevenire attacchi MitM.
• La password con hash ricevuta dal server è meno sicura se non si esegue un lavoro aggiuntivo e ridondante sul server.

C'è un altro metodo sicuro chiamato SRP , ma è brevettato (anche se è concesso in licenza liberamente ) e ci sono alcune buone implementazioni disponibili.

Memorizzazione delle password

Non archiviare mai le password come testo normale nel database. Nemmeno se non ti interessa la sicurezza del tuo sito. Supponiamo che alcuni dei tuoi utenti riutilizzeranno la password del loro conto bancario online. Quindi, memorizza la password con hash e getta l'originale. E assicurati che la password non venga visualizzata nei registri di accesso o nei registri delle applicazioni. OWASP consiglia l'uso di Argon2 come prima scelta per nuove applicazioni. Se questo non è disponibile, utilizzare PBKDF2 o scrypt. E infine se nessuna delle precedenti è disponibile, usa bcrypt.

Anche gli hash da soli sono insicuri. Ad esempio, password identiche significano hash identici: questo rende le tabelle di ricerca hash un modo efficace per decifrare molte password contemporaneamente. Conserva invece l' hash salato . Un salt è una stringa aggiunta alla password prima dell'hashing - usa un salt diverso (casuale) per utente. Il sale è un valore pubblico, quindi è possibile memorizzarlo con l'hash nel database. Vedi qui per ulteriori informazioni al riguardo.

Ciò significa che non puoi inviare all'utente le password dimenticate (perché hai solo l'hash). Non reimpostare la password dell'utente a meno che tu non abbia autenticato l'utente (gli utenti devono dimostrare di essere in grado di leggere le e-mail inviate all'indirizzo e-mail memorizzato (e validato).)

Domande di sicurezza

Le domande di sicurezza non sono sicure - evita di usarle. Perché? Qualunque cosa faccia una domanda di sicurezza, una password fa meglio. Leggi la PARTE III: Uso delle domande segrete in @Jens Roland rispondi qui in questo wiki.

Cookie di sessione

Dopo che l'utente ha effettuato l'accesso, il server invia all'utente un cookie di sessione. Il server può recuperare il nome utente o l'id dal cookie, ma nessun altro può generare tale cookie (TODO spiega i meccanismi).

I cookie possono essere dirottati : sono sicuri solo come il resto della macchina del cliente e altre comunicazioni. Possono essere letti dal disco, sniffati nel traffico di rete, sollevati da un attacco di scripting cross-site, phishing da un DNS avvelenato in modo che il client invii i loro cookie ai server sbagliati. Non inviare cookie persistenti. I cookie devono scadere al termine della sessione del client (chiusura del browser o uscita dal dominio).

Se vuoi autologare i tuoi utenti, puoi impostare un cookie persistente, ma dovrebbe essere distinto da un cookie di sessione completa. È possibile impostare un flag aggiuntivo a cui l'utente ha effettuato l'accesso automatico e deve eseguire l'accesso reale per operazioni sensibili. Questo è popolare tra i siti di shopping che vogliono offrirti un'esperienza di acquisto personalizzata e senza interruzioni, pur proteggendo i tuoi dettagli finanziari. Ad esempio, quando torni a visitare Amazon, ti mostrano una pagina che sembra che tu abbia effettuato l'accesso, ma quando vai a effettuare un ordine (o cambi indirizzo di spedizione, carta di credito ecc.), Ti chiedono di confermare la tua password.

I siti Web finanziari come banche e carte di credito, d'altra parte, hanno solo dati sensibili e non dovrebbero consentire l'accesso automatico o una modalità a bassa sicurezza.

Elenco di risorse esterne

• 
  Articolo accademico di 21 pagine Dos and Don'ts of Client Authentication on the Web (PDF) con molti ottimi consigli.
• Chiedere a YC:
  discussione sulle Best Practices for User Authentication Forum sull'argomento
• Probabilmente stai memorizzando le password in modo errato
  Articolo introduttivo sulla memorizzazione delle password
• Discussione: Coding Horror: probabilmente stai memorizzando le password in modo errato
  Discussione del forum su un articolo di Coding Horror.
• Non archiviare mai le password in un database!
  Un altro avvertimento sulla memorizzazione delle password nel database.
• Password cracking
  Articolo di Wikipedia sui punti deboli di diversi schemi di hashing delle password.
• Basta con le tabelle arcobaleno: cosa devi sapere sugli schemi di password sicure
  Discussione sulle tabelle arcobaleno e su come difenderle e contro altri thread. Include un'ampia discussione.

Innanzitutto, un forte avvertimento sul fatto che questa risposta non è la soluzione migliore per questa domanda esatta. Non dovrebbe assolutamente essere la risposta migliore!

Vado avanti e menzionerò il BrowserID proposto da Mozilla (o forse più precisamente, il Protocollo e-mail verificato ) nello spirito di trovare un percorso di aggiornamento per approcci migliori all'autenticazione in futuro.

Riassumo in questo modo:

1. Mozilla è un'organizzazione no profit con valori che si allineano bene con la ricerca di buone soluzioni a questo problema.
2. La realtà oggi è che la maggior parte dei siti Web utilizza l'autenticazione basata su moduli
3. L'autenticazione basata su form presenta un grosso svantaggio, che comporta un aumento del rischio di phishing . Agli utenti viene chiesto di inserire informazioni riservate in un'area controllata da un'entità remota, anziché in un'area controllata dal proprio User Agent (browser).
4. Poiché i browser sono implicitamente attendibili (l'idea di un agente utente è di agire per conto dell'utente), possono aiutare a migliorare questa situazione.
5. La forza principale che trattiene i progressi qui è il deadlock di spiegamento . Le soluzioni devono essere scomposte in passaggi che forniscono da soli alcuni vantaggi incrementali.
6. Il metodo decentralizzato più semplice per esprimere un'identità integrata nell'infrastruttura Internet è il nome di dominio.
7. Come secondo livello di espressione dell'identità, ogni dominio gestisce il proprio set di account.
8. Il modulo " @dominio dell'account " è conciso e supportato da una vasta gamma di protocolli e schemi URI. Tale identificatore è, ovviamente, riconosciuto universalmente come un indirizzo e-mail.
9. I provider di posta elettronica sono già di fatto i principali provider di identità online. I flussi di reimpostazione della password corrente in genere ti consentono di assumere il controllo di un account se puoi provare di controllare l'indirizzo e-mail associato a tale account.
10. Il protocollo e-mail verificato è stato proposto per fornire un metodo sicuro, basato sulla crittografia a chiave pubblica, per semplificare il processo di dimostrazione al dominio B che si dispone di un account sul dominio A.
11. Per i browser che non supportano il protocollo e-mail verificato (attualmente tutti), Mozilla fornisce uno shim che implementa il protocollo nel codice JavaScript lato client.
12. Per i servizi di posta elettronica che non supportano il protocollo di posta elettronica verificato, il protocollo consente a terzi di agire come intermediario di fiducia, affermando di aver verificato la proprietà di un account da parte di un utente. Non è desiderabile avere un gran numero di tali terzi; questa funzionalità ha il solo scopo di consentire un percorso di aggiornamento ed è molto preferibile che i servizi di posta elettronica forniscano tali affermazioni.
13. Mozilla offre il proprio servizio per agire come una terza parte di fiducia. I fornitori di servizi (vale a dire le parti affidatarie) che implementano il protocollo e-mail verificato possono scegliere di fidarsi o meno delle affermazioni di Mozilla. Il servizio di Mozilla verifica la proprietà dell'account degli utenti utilizzando i mezzi convenzionali per inviare un'e-mail con un link di conferma.
14. I fornitori di servizi possono, ovviamente, offrire questo protocollo come opzione in aggiunta a qualsiasi altro metodo o metodi di autenticazione che potrebbero voler offrire.
15. Un grande vantaggio dell'interfaccia utente ricercato qui è il "selettore di identità". Quando un utente visita un sito e sceglie di autenticarsi, il suo browser mostra loro una selezione di indirizzi email ("personale", "lavoro", "attivismo politico", ecc.) Che possono utilizzare per identificarsi nel sito.
16. Un altro grande vantaggio dell'interfaccia utente che viene richiesto come parte di questo sforzo è quello di aiutare il browser a conoscere meglio la sessione dell'utente - chi ha effettuato l'accesso come attualmente, principalmente - quindi potrebbe visualizzarlo nel browser Chrome.
17. A causa della natura distribuita di questo sistema, evita il blocco di siti importanti come Facebook, Twitter, Google, ecc. Ogni individuo può possedere il proprio dominio e quindi agire come proprio provider di identità.

Questa non è strettamente "autenticazione basata su form per siti Web". Ma è uno sforzo per passare dall'attuale norma di autenticazione basata su form a qualcosa di più sicuro: l'autenticazione supportata dal browser.

Ho solo pensato di condividere questa soluzione che ho trovato funzionare bene.

Lo chiamo Dummy Field (anche se non l'ho inventato, quindi non mi accreditare).

In breve: devi solo inserire questo nel tuo <form>e verificare che sia vuoto in durante la convalida:

<input type="text" name="email" style="display:none" />

Il trucco è ingannare un bot nel pensare che debba inserire dati in un campo obbligatorio, ecco perché ho chiamato l'input "email". Se hai già un campo chiamato e-mail che stai utilizzando, dovresti provare a nominare il campo fittizio con qualcosa di simile a "azienda", "telefono" o "indirizzo e-mail". Scegli qualcosa che sai di non aver bisogno e che cosa sembra qualcosa che le persone normalmente troverebbero logico da compilare in un modulo web. Ora nascondere il inputcampo utilizzando CSS o JavaScript / jQuery - qualunque cosa si adatta meglio - semplicemente non impostare l'ingresso typeal hiddenaltrimenti il bot non cadrà per esso.

Quando si convalida il modulo (lato client o server), verificare se il campo fittizio è stato compilato per determinare se è stato inviato da un essere umano o da un bot.

Esempio:

Nel caso di un essere umano: l'utente non vedrà il campo fittizio (nel mio caso denominato "e-mail") e non tenterà di riempirlo. Quindi il valore del campo fittizio dovrebbe essere ancora vuoto quando il modulo è stato inviato.

Nel caso di un bot: il bot vedrà un campo il cui tipo è texte un nome email(o come lo si chiama) e tenterà logicamente di riempirlo con i dati appropriati. Non importa se hai modellato il modulo di input con alcuni CSS fantasiosi, gli sviluppatori web lo fanno sempre. Qualunque sia il valore nel campo fittizio, non ci importa finché è più grande dei 0personaggi.

Ho usato questo metodo su un libro degli ospiti in combinazione con CAPTCHA , e da allora non ho più visto un singolo spam. In precedenza avevo usato una soluzione solo CAPTCHA, ma alla fine ha prodotto circa cinque messaggi spam ogni ora. L'aggiunta del campo fittizio nel modulo ha interrotto (almeno fino ad ora) la visualizzazione di tutto lo spam.

Credo che questo possa anche essere usato bene con un modulo di login / autenticazione.

Avvertenza : ovviamente questo metodo non è sicuro al 100%. I robot possono essere programmati per ignorare i campi di input con lo stile display:noneapplicato ad esso. Devi anche pensare alle persone che usano una forma di completamento automatico (come la maggior parte dei browser ha incorporato!) Per compilare automaticamente tutti i campi del modulo per loro. Potrebbero anche raccogliere un campo fittizio.

Puoi anche variare un po 'lasciando il campo fittizio visibile ma al di fuori dei confini dello schermo, ma dipende da te.

Essere creativo!

Non credo che la risposta di cui sopra sia "sbagliata" ma ci sono ampie aree di autenticazione che non vengono toccate (o piuttosto l'enfasi è su "come implementare le sessioni di cookie", non su "quali opzioni sono disponibili e quali sono gli scambi) -offs".

Le mie modifiche / risposte suggerite sono

• Il problema risiede più nella configurazione dell'account che nel controllo della password.
• L'uso dell'autenticazione a due fattori è molto più sicuro dei mezzi più intelligenti di crittografia delle password

• NON tentare di implementare il proprio modulo di accesso o l'archiviazione del database delle password, a meno che i dati archiviati non abbiano valore al momento della creazione dell'account e si auto-generino (vale a dire, stile web 2.0 come Facebook, Flickr , ecc.)

  1. Digest Authentication è un approccio basato su standard supportato in tutti i principali browser e server, che non invierà una password anche su un canale sicuro.

Questo evita qualsiasi necessità di avere "sessioni" o cookie poiché il browser stesso ricodificherà la comunicazione ogni volta. È l'approccio di sviluppo più "leggero".

Tuttavia, non lo consiglio, ad eccezione dei servizi pubblici di basso valore. Questo è un problema con alcune delle altre risposte sopra - non tentare di implementare nuovamente i meccanismi di autenticazione sul lato server - questo problema è stato risolto ed è supportato dalla maggior parte dei browser principali. Non utilizzare i cookie Non archiviare nulla nel proprio database eseguito manualmente. Basta chiedere, per richiesta, se la richiesta è autenticata. Tutto il resto dovrebbe essere supportato dalla configurazione e da software affidabile di terze parti.

Così ...

Innanzitutto, stiamo confondendo la creazione iniziale di un account (con una password) con il ricontrollo della password successivamente. Se sono Flickr e creo il tuo sito per la prima volta, il nuovo utente ha accesso al valore zero (spazio web vuoto). Non mi interessa davvero se la persona che crea l'account sta mentendo sul loro nome. Se sto creando un conto dell'ospedale intranet / extranet, si trova il valore di tutte le cartelle cliniche, e così mi faccio la cura circa l'identità (*) del conto creatore.

Questa è la parte molto difficile. L' unica soluzione decente è una rete di fiducia. Ad esempio, ti unisci all'ospedale come medico. Crei una pagina web ospitata da qualche parte con la tua foto, il tuo numero di passaporto e una chiave pubblica e li hash tutti con la chiave privata. Quindi visiti l'ospedale e l'amministratore di sistema esamina il tuo passaporto, verifica se la foto corrisponde a te e quindi esegue l'hashing della pagina Web / dell'hash della foto con la chiave privata dell'ospedale. D'ora in poi possiamo scambiare in modo sicuro chiavi e token. Come può chiunque abbia fiducia nell'ospedale (c'è la salsa segreta BTW). L'amministratore di sistema può anche fornire un dongle RSA o altra autenticazione a due fattori.

Ma questo è un sacco di fastidio, e non molto web 2.0. Tuttavia, è l'unico modo sicuro per creare nuovi account che hanno accesso a informazioni preziose che non sono auto-create.

1. Kerberos e SPNEGO - meccanismi di accesso singolo con una terza parte attendibile - sostanzialmente l'utente verifica contro una terza parte attendibile. (NB questo non è in alcun modo il non attendibile OAuth )

2. SRP - una sorta di autenticazione intelligente della password senza una terza parte attendibile. Ma qui stiamo entrando nei regni di "è più sicuro utilizzare l'autenticazione a due fattori, anche se è più costosa"

3. Lato client SSL : fornisce ai clienti un certificato con chiave pubblica (supporto in tutti i principali browser) ma solleva domande sulla sicurezza della macchina client.

Alla fine, è un compromesso: qual è il costo di una violazione della sicurezza rispetto al costo dell'implementazione di approcci più sicuri. Un giorno potremmo vedere una corretta PKI ampiamente accettata e quindi non più moduli e database di autenticazione personalizzati. Un giorno...

Quando si esegue l'hashing, non utilizzare algoritmi hash veloci come MD5 (esistono molte implementazioni hardware). Usa qualcosa come SHA-512. Per le password, gli hash più lenti sono i migliori.

Più velocemente è possibile creare hash, più velocemente può funzionare qualsiasi controllo della forza bruta. Gli hash più lenti rallenteranno quindi la forza bruta. Un algoritmo di hash lento renderà la forzatura bruta poco pratica per password più lunghe (8 cifre +)

Un buon articolo sulla stima realistica della forza della password è:

Dropbox Tech Blog »Blog Archive» zxcvbn: stima realistica della forza della password

La mia regola preferita per quanto riguarda i sistemi di autenticazione: usare passphrase, non password. Facile da ricordare, difficile da decifrare. Ulteriori informazioni: Coding Horror: Passwords vs. Pass Phrases

Vorrei aggiungere un suggerimento che ho usato, basato sulla difesa in profondità. Non è necessario disporre dello stesso sistema di autenticazione e autenticazione per gli amministratori degli utenti normali. Puoi avere un modulo di accesso separato su un URL separato che esegue un codice separato per le richieste che garantiranno privilegi elevati. Questo può fare delle scelte che sarebbero un dolore totale per gli utenti regolari. Uno di quelli che ho usato è quello di mescolare l'URL di accesso per l'accesso dell'amministratore e inviare all'amministratore il nuovo URL. Interrompe immediatamente qualsiasi attacco di forza bruta poiché il nuovo URL può essere arbitrariamente difficile (stringa casuale molto lunga) ma l'unico inconveniente dell'utente amministratore è seguire un collegamento nella sua e-mail. L'attaccante non sa più dove nemmeno POSTARE.

Non so se fosse meglio rispondere come risposta o come commento. Ho optato per la prima opzione.

Per quanto riguarda la parte PARTE IV: Funzionalità password dimenticata nella prima risposta, vorrei fare un punto sugli attacchi a tempo.

Nei moduli Ricorda la tua password , un utente malintenzionato potrebbe potenzialmente controllare un elenco completo di e-mail e rilevare quali sono registrati nel sistema (vedi link sotto).

Per quanto riguarda il modulo Password dimenticata, aggiungerei che è una buona idea eguagliare i tempi tra query riuscite e non riuscite con qualche funzione di ritardo.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Vorrei aggiungere un commento molto importante: -

• "In un aziendale, intra impostazione rete," la maggior parte se non tutti di quanto sopra potrebbe non si applica!

Molte aziende distribuiscono siti Web "solo per uso interno" che sono, in effetti, "applicazioni aziendali" che sono state implementate tramite URL. Questi URL possono (presumibilmente ...) essere risolti solo all'interno della "rete interna dell'azienda". (Quale rete include magicamente tutti i "guerrieri della strada" connessi alla VPN).

Quando un utente è debitamente connesso alla suddetta rete, la sua identità ("autenticazione") è [già ...] "definitivamente conosciuta", così come il suo permesso ("autorizzazione") di fare determinate cose ... come. .. "per accedere a questo sito Web".

Questo servizio "autenticazione + autorizzazione" può essere fornito da diverse tecnologie, come LDAP (Microsoft OpenDirectory) o Kerberos.

Dal tuo punto di vista, lo sai semplicemente: che chiunque finisca legittimamente sul tuo sito Web deve essere accompagnato da [una variabile d'ambiente che contiene magicamente ...] un "token". ( ovvero l'assenza di tale token deve essere motivo immediato per 404 Not Found.)

Il valore del token non ha senso per te, ma, in caso di necessità, "esistono mezzi appropriati" con cui il tuo sito web può "[autorevolmente] chiedere a qualcuno che conosce (LDAP ... ecc.)" Di qualsiasi (!) domanda che potresti avere. In altre parole, non ti avvali di alcuna "logica coltivata in casa". Invece, informi l'Autorità e ti fidi implicitamente del suo verdetto.

Uh huh ... è abbastanza un cambiamento mentale da "Internet selvaggio e lanoso".

Usa OpenID Connect o Accesso gestito dall'utente .

Poiché nulla è più efficiente di non farlo affatto.