Domanda La guida definitiva all'autenticazione del sito Web basata su moduli [chiusa]


Autenticazione basata su modulo per siti Web

Crediamo che Stack Overflow non debba essere solo una risorsa per domande tecniche molto specifiche, ma anche per linee guida generali su come risolvere variazioni su problemi comuni. "L'autenticazione basata su moduli per i siti Web" dovrebbe essere un buon argomento per un simile esperimento.

Dovrebbe includere argomenti come:

  • Come accedere
  • Come disconnettersi
  • Come rimanere loggato
  • Gestione dei cookie (comprese le impostazioni consigliate)
  • Crittografia SSL / HTTPS
  • Come conservare le password
  • Utilizzando domande segrete
  • Funzionalità di username / password dimenticata
  • Uso di nonces  impedire falsi di richieste cross-site (CSRF)
  • OpenID
  • Casella "Ricordami"
  • Completamento automatico del browser di nomi utente e password
  • URL segreti (pubblici URL  protetto da digest)
  • Controllo della forza della password
  • Convalida e-mail
  • e molto altro ancora   autenticazione basata su form ...

Non dovrebbe includere cose come:

  • Ruoli e autorizzazione
  • Autenticazione di base HTTP

Per favore aiutaci con:

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

4992


origine


risposte:


PARTE I: Come accedere

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

Per HTTPS o non per HTTPS?

A meno che la connessione non sia già sicura (ovvero tramite tunnel attraverso HTTPS che utilizza SSL / TLS), i valori del modulo di accesso verranno inviati in chiaro, consentendo a chiunque intercetta la linea tra browser e server Web di leggere gli accessi mentre passano attraverso. Questo tipo di intercettazioni viene eseguito di routine dai governi, ma in generale non indirizzeremo i fili "di proprietà" se non per dire questo: se stai proteggendo qualcosa di importante, usa HTTPS.

In sostanza, l'unico pratico  il modo per proteggersi contro l'intercettazione di wiretapping / pacchetti durante l'accesso è utilizzando HTTPS o un altro schema di crittografia basato su certificato (ad esempio, TLS ) o uno schema di sfida / risposta collaudato e testato (ad esempio, il Diffie-Hellman basato su SRP). Qualsiasi altro metodo può essere facilmente aggirato  da un attaccante intercettatore.

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 codice di codice fisico "stile di guerra fredda" o un dongle del generatore di chiavi RSA). Se applicato correttamente, questo 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

Dato il costo diverso da zero e la difficoltà tecnica percepita di impostare un certificato SSL sul tuo sito web, alcuni sviluppatori sono tentati di implementare i propri schemi di hashing o di crittografia nel browser per evitare di passare accessi di testo non crittografato su un filo non protetto.

Mentre questo è un pensiero nobile, è essenzialmente inutile (e può essere un difetto di sicurezza ) a meno che non sia combinato con uno dei precedenti - cioè, proteggendo la linea con una crittografia forte o usando un meccanismo di risposta-risposta comprovato (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).

Mentre è vero che hashing la password può essere  efficace contro divulgazione di password , è vulnerabile agli attacchi di riproduzione, attacchi / dirottamenti Man-In-The-Middle (se un utente malintenzionato può iniettare alcuni byte nella pagina HTML non protetta prima che raggiunga il browser, può semplicemente commentare l'hashing nel codice JavaScript), o attacchi a forza bruta (dal momento che stai consegnando al malintenzionato sia il nome utente, la password salt e hash).

CAPTCHAS contro l'umanità

CAPTCHA  hanno lo scopo di contrastare una specifica categoria di attacco: dizionario automatico / forza bruta trial-and-error senza operatore umano. Non c'è dubbio che questa sia una vera minaccia, tuttavia ci sono modi per affrontarla senza problemi che non richiedono un CAPTCHA, in particolare schemi di limitazione dell'accesso serveride appositamente progettati - ne discuteremo più avanti.

Sappi che le implementazioni CAPTCHA non sono create allo stesso modo; spesso non sono risolvibili dall'uomo, molti di questi sono inefficaci contro i robot, tutti sono inefficaci contro il lavoro del terzo mondo a buon mercato (secondo OWASP , il tasso attuale di sweatshop è di $ 12 per 500 test), e alcune implementazioni potrebbero essere tecnicamente illegali in alcuni paesi (vedi Scheda cheat dell'autenticazione OWASP ). Se è necessario utilizzare un CAPTCHA, utilizzare Google reCAPTCHA , dal momento che è OCR-difficile per definizione (dal momento che utilizza già scansioni di libri erroneamente classificate da OCR) e cerca molto duramente di essere user-friendly.

Personalmente, tendo a trovare fastidi CAPTCHAS, e li uso solo come ultima risorsa quando un utente non è riuscito a effettuare il login un numero di volte e i rallentamenti sono limitati. Ciò accadrà raramente per essere accettabile e rafforzerà il sistema nel suo complesso.

Memorizzazione password / verifica accessi

Questo può essere finalmente una conoscenza comune dopo tutti gli hack altamente 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 raccolti attraverso SQL injection e, se si memorizzano password in chiaro e in chiaro, questo è un gioco istantaneo per la sicurezza di accesso.

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

Il motivo per cui viene usato un sale è perché l'hashing di per sé non è sufficiente - ti consigliamo di aggiungere un cosiddetto "sale" per proteggere l'hash contro tavoli arcobaleno . Un sale impedisce in modo efficace due password che corrispondono esattamente all'essere memorizzate come lo stesso valore di hash, impedendo l'intero database di essere analizzato in una sola esecuzione se un utente malintenzionato sta eseguendo un attacco indovinatore di password.

Un hash crittografico non dovrebbe essere utilizzato per l'archiviazione delle password perché le password selezionate dall'utente non sono abbastanza potenti (ovvero non contengono in genere abbastanza entropia) e un attacco di indovinamento della password potrebbe essere completato in un tempo relativamente breve da un utente malintenzionato con accesso agli hash. Questo è il motivo per cui viene utilizzato un KDF - questi in modo efficace "allunga la chiave"  il che significa che ogni password che indovina un utente malintenzionato comporta più volte l'iterazione dell'algoritmo di hashing, ad esempio 10.000 volte, rendendo la password dell'attaccante indovinando 10.000 volte più lentamente.

Dati di sessione - "Accesso come Spiderman69"

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

Se non hai familiarità con i dati della sessione, ecco come funziona: una singola stringa generata a caso viene memorizzata in un cookie in scadenza e utilizzata per fare riferimento a una raccolta di dati, i dati della sessione, che sono archiviati sul server. Se si utilizza un framework MVC, questo è già gestito senza dubbio.

Se possibile, assicurarsi che il cookie di sessione abbia i flag sicuri e solo HTTP impostati quando inviati al browser. Il flag httponly fornisce una certa protezione contro il cookie che viene letto da un attacco XSS. Il flag di sicurezza 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 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 quanto gli accessi convenzionali quando gli utenti capiscono come gestirli; e dall'altro lato, rappresentano un enorme rischio per la sicurezza nelle mani di utenti incuranti, che potrebbero utilizzarli 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 persistenti per i siti web che visito regolarmente, ma so come gestirli in modo sicuro. Se sei sicuro che i tuoi utenti lo sappiano, puoi usare accessi persistenti con la coscienza pulita. Altrimenti, beh, allora puoi sottoscrivere la filosofia secondo cui gli utenti che sono incuranti delle loro credenziali di accesso lo hanno portato su se stessi se vengono violati. Non è che andiamo nelle case dei nostri utenti e strappiamo tutte quelle note Post-It che inducono facepalm con le password che hanno allineato sul bordo dei loro monitor.

Certo, alcuni sistemi non possono permettersi di avere qualunque  account violati; per tali sistemi, non è possibile giustificare l'accesso persistente.

Se decidi di implementare cookie di accesso persistenti, questo è il modo in cui lo fai:

  1. Per prima cosa, prenditi del tempo per leggere Articolo di Paragon Initiative  a questo proposito. Avrai bisogno di ottenere un sacco di elementi giusti, e l'articolo fa un ottimo lavoro di spiegazione di ciascuno.

  2. E solo per reiterare una delle trappole più comuni, NON MEMORIZZARE I COOKIE (TOKEN) LOGIST PERSISTENTI NELLA TUA BANCA DATI, SOLO UN PROBLEMA!  Il token di accesso è equivalente alla password, quindi se un utente malintenzionato ha messo le mani sul tuo database, potrebbe utilizzare i token per accedere a qualsiasi account, proprio come se fossero combinazioni di login-password in chiaro. Pertanto, usa l'hashing (secondo https://security.stackexchange.com/a/63438/5002  un hash debole andrà bene per questo scopo) quando si memorizzano i token di accesso persistenti.

PARTE III: Utilizzo di domande segrete

Non implementare "domande segrete" . La funzione 'domande segrete' è un anti-pattern di sicurezza. Leggi la carta dal link numero 4 dall'elenco MUST-READ. Puoi chiedere a Sarah Palin di quello, dopo il suo Yahoo! l'account di posta elettronica è stato violato durante una precedente campagna presidenziale perché la risposta alla sua domanda di sicurezza era ... "Wasilla High School"!

Anche con le domande specificate dall'utente, è molto probabile che la maggior parte degli utenti sceglierà:

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

  • Un semplice pezzo di 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 insicuri in quasi tutte le loro forme e variazioni e non dovrebbero essere utilizzate in uno schema di autenticazione per nessuna ragione.

Il vero motivo per cui le domande di sicurezza esistono persino in natura consiste nel fatto che risparmiano convenientemente il costo di alcune chiamate di supporto da parte degli utenti che non possono accedere alla loro posta elettronica 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à detto perché dovresti non usare mai domande di sicurezza per gestire password utente dimenticate / perse; è anche ovvio che non si dovrebbero mai inviare agli e-mail gli utenti le loro password effettive. Ci sono almeno altre due insidie ​​più comuni da evitare in questo campo:

  1. non reset  una password dimenticata per una password complessa autogenerata - tali password sono notoriamente difficili da ricordare, il che significa che l'utente deve modificarlo o scriverlo, ad esempio su un Post-It giallo brillante sul bordo del monitor. Invece di impostare una nuova password, lascia che siano gli utenti a sceglierne una nuova subito - che è ciò che vogliono fare comunque. (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. Ha sempre cancellato il codice / token della password persa nel database. ANCORA , questo codice è un altro esempio di equivalente di password, quindi DEVE essere hash nel caso in cui un utente malintenzionato abbia messo le mani sul tuo database. Quando viene richiesto un codice password smarrito, invia il codice in chiaro all'indirizzo e-mail dell'utente, quindi cancellalo, salva l'hash nel tuo database - e buttare via l'originale . Proprio come una password o un token di accesso persistente.

Un'ultima nota: assicurati sempre che l'interfaccia per l'inserimento del "codice della password persa" sia sicura almeno quanto il modulo di accesso stesso, altrimenti un utente malintenzionato lo utilizzerà semplicemente per ottenere l'accesso. Assicurarsi di generare "codici password persi" molto lunghi (ad esempio, 16 caratteri alfanumerici sensibili al maiuscolo / minuscolo) è un buon inizio, ma si consideri l'aggiunta dello stesso schema di limitazione che si fa per il modulo di login stesso.

PARTE V: Controllo della forza della password

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

Ok, forse la lista non è la canonico  elenco delle password più comuni in uso qualunque  sistema ovunque , ma è una buona indicazione di quanto male le persone sceglieranno le loro password quando non ci sarà alcuna politica applicata. Inoltre, l'elenco sembra spaventosamente vicino a casa quando lo si confronta con analisi pubblicamente disponibili di password rubate di recente.

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

Per contrastare ciò è necessario calcolare l'entropia di una password e quindi applicare una soglia. L'Istituto nazionale degli standard e della tecnologia (NIST) Pubblicazione speciale 800-63  ha una serie di ottimi consigli. Questo, quando combinato con un dizionario e l'analisi del layout della tastiera (ad esempio, 'qwertyuiop' è una password errata), can rifiuta il 99% di tutte le password scarsamente selezionate  a un livello di 18 bit di entropia. Semplicemente calcolando la forza della password e mostrando un misuratore di forza visiva  per un utente è buono, ma insufficiente. A meno che non venga applicato, molto probabilmente molti utenti lo ignoreranno.

E per rinfrescare la user-friendliness delle password ad alta entropia, Randall Munroe's Forza password xkcd  è altamente raccomandato

PARTE VI: Molto di più - Oppure: Prevenire tentativi di accesso rapidi

Per prima cosa dai un'occhiata ai numeri: Velocità di recupero della password - Quanto durerà la tua password

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

  1. Ci vuole praticamente senza tempo  per decifrare una password debole, anche se la stai incrinando con un abaco

  2. Ci vuole praticamente senza tempo  per decifrare una password alfanumerica di 9 caratteri, se lo è maiuscole e minuscole

  3. Ci vuole praticamente senza tempo  per rompere un intricato, simboli e lettere e numeri, password maiuscole e minuscole, se lo è meno di 8 caratteri  (un PC desktop può cercare nell'intero spazio della tastiera fino a 7 caratteri in pochi giorni o addirittura ore)

  4. Tuttavia, richiederebbe una quantità eccessiva di tempo per decifrare anche una password di 6 caratteri, se tu fossi limitato a un tentativo al secondo!

Quindi cosa possiamo imparare da questi numeri? Bene, molte cose, ma possiamo concentrarci sulla parte più importante: il fatto che prevenire un gran numero di tentativi di accesso successivi a fuoco rapido (ad es. forza bruta  attacco) non è poi così difficile. Ma impedirlo destra  non è così facile come sembra.

In generale, hai tre scelte che sono tutte efficaci contro gli attacchi di forza bruta (e gli attacchi di dizionario, ma dal momento che si sta già utilizzando una politica per password complesse, non dovrebbero essere un problema) :

  • Presente a CAPTCHA  dopo N tentativi falliti (fastidioso come l'inferno e spesso inefficace - ma mi sto ripetendo qui)

  • Bloccare i conti  e richiede la verifica dell'e-mail dopo N tentativi falliti (questo è un DoS  attacco in attesa di accadere)

  • E infine, limitazione dell'accesso : ovvero, impostare un intervallo di tempo tra i tentativi dopo N tentativi falliti (sì, gli attacchi DoS sono ancora possibili, ma almeno sono molto meno probabili e molto più complicati da estrarre).

Best practice # 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 = 16 secondi di ritardo
  • eccetera.

Il DoS che attacca questo schema sarebbe molto poco pratico, poiché il tempo di blocco risultante è leggermente maggiore della somma dei tempi di blocco precedenti.

Per chiarire: il ritardo è non  un ritardo prima di restituire la risposta al browser. È più come un timeout o periodo refrattario durante il quale i tentativi di accesso a un account specifico o da uno specifico indirizzo IP non saranno accettati o valutati del tutto. Cioè, le credenziali corrette non torneranno in un login riuscito e le credenziali errate non innescheranno un aumento di ritardo.

Best practice n. 2:  Un ritardo di tempo medio che diventa effettivo dopo N tentativi falliti, come:

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

Il DoS che attacca questo schema sarebbe piuttosto poco pratico, ma certamente fattibile. Inoltre, potrebbe essere importante notare che un ritardo così lungo può essere molto fastidioso per un utente legittimo. Gli utenti dimenticati non ti apprezzeranno.

Best practice # 3:  Combinando i due approcci - sia un breve ritardo fisso 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 = 15 secondi di ritardo
  • 3+ tentativi falliti = 45 secondi di ritardo

Questo schema finale è stato preso dai suggerimenti delle best practice OWASP (link 1 dell'elenco MUST-READ) e dovrebbe essere considerato la migliore pratica, anche se è ammesso sul lato restrittivo.

Tuttavia, come regola generale, direi: più è forte la tua politica sulle password, meno devi infastidire gli utenti con ritardi. Se hai bisogno di caratteri alfanumerici (maiuscole e minuscole maiuscole + numeri e simboli richiesti) di password di 9+ caratteri, puoi dare agli utenti 2-4 tentativi di password non ritardati prima di attivare la limitazione.

Il DoS che attacca questo schema finale di limitazione dell'accesso sarebbe molto  impraticabile. E come tocco finale, consentire sempre il login persistente (cookie) (e / o un modulo di accesso verificato da CAPTCHA), in modo che gli utenti legittimi non vengano nemmeno ritardati mentre l'attacco è in corso . In questo modo, l'attacco DoS molto impraticabile diventa un estremamente  attacco non pratico.

Inoltre, è logico eseguire una regolazione più aggressiva nei conti di amministrazione, dal momento che questi sono i punti di ingresso più interessanti

PARTE VII: Attacchi di forza bruta distribuita

Proprio come un lato, gli attaccanti più avanzati cercheranno di aggirare la limitazione dell'accesso "diffondendo le loro attività":

  • Distribuire i tentativi su una botnet per impedire la segnalazione degli indirizzi IP

  • Piuttosto che scegliere un utente e provare le 50.000 password più comuni (che non possono, a causa del nostro throttling), sceglieranno la password più comune e la provano invece contro 50.000 utenti. In questo modo, non solo si aggirano le misure di massimo tentativo come CAPTCHA e la limitazione dell'accesso, anche le loro possibilità di successo aumentano, poiché la password più comune numero 1 è molto più probabile del numero 49.995

  • Spaziatura tra le richieste di accesso per ciascun account utente, ad esempio a 30 secondi di distanza, per intrufolarsi sotto il radar

Qui, la migliore pratica sarebbe registrazione del numero di accessi non riusciti, a livello di sistema e utilizzando una media costante della frequenza di accesso errato del tuo sito come base per un limite massimo che imporrai a tutti gli utenti.

Troppo astratto? Lasciami riformulare:

Supponiamo che il tuo sito abbia avuto una media di 120 accessi non validi al giorno negli ultimi 3 mesi. Usando questo (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 in un giorno (o anche meglio, monitora la velocità di accelerazione e trigger su una soglia calcolata), attiva la limitazione dell'accesso a livello di sistema - significa ritardi brevi per TUTTI gli utenti (ancora, ad eccezione dei login dei cookie e / o dei login CAPTCHA di backup).

Ho anche pubblicato una domanda con maggiori dettagli e una discussione davvero buona su come evitare complicate buche  nel respingere gli attacchi di forza bruta distribuiti

PARTE VIII: Autenticazione a due fattori e provider di autenticazione

Le credenziali possono essere compromesse, sia da exploit, password scritte e perse, laptop con chiavi rubate, o utenti che inseriscono login in siti di phishing. Gli accessi possono essere ulteriormente protetti con l'autenticazione a due fattori, che utilizzano fattori fuori banda come i 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, dove un altro gestore gestisce la raccolta delle credenziali. Questo spinge il problema a una terza parte fidata. Google e Twitter forniscono entrambi servizi SSO basati su standard, mentre Facebook offre una soluzione proprietaria simile.

COLLEGAMENTI DEVE LEGGERE Informazioni sull'autenticazione Web

  1. Guida OWASP all'autenticazione  / Scheda cheat dell'autenticazione OWASP
  2. Cosa fare e cosa non fare dell'autenticazione del cliente sul web (documento di ricerca del MIT molto leggibile)
  3. Wikipedia: cookie HTTP
  4. Domande di conoscenza personale per l'autenticazione di fallback: domande di sicurezza nell'era di Facebook (documento di ricerca Berkeley molto leggibile)

3497



Articolo definitivo

Invio di credenziali

L'unico modo pratico per inviare credenziali al 100% in modo sicuro è usando SSL . Usando JavaScript per cancellare la password non è sicura. Problemi comuni per l'hashing della password sul lato client:

  • Se la connessione tra client e server non è criptata, tutto ciò che fai è vulnerabile agli attacchi man-in-the-middle . Un utente malintenzionato può sostituire il javascript in entrata per interrompere l'hashing o inviare tutte le credenziali al proprio server, ascoltare le risposte dei clienti e impersonare perfettamente gli utenti, ecc. Ecc. SSL con le autorità di certificazione attendibili è progettato per prevenire gli attacchi MitM.
  • La password hash ricevuta dal server è meno sicuro  se non si eseguono ulteriori lavori ridondanti sul server.

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

Memorizzazione di password

Non memorizzare mai le password come testo in chiaro nel database. Neanche se non ti interessa la sicurezza del tuo sito. Supponiamo che alcuni dei tuoi utenti riutilizzino la password del proprio conto bancario online. Quindi, memorizza la password con hash e getta via l'originale. E assicurati che la password non compaia nei log di accesso o nei log delle applicazioni. OWASP raccomanda l'uso di Argon2  come prima scelta per nuove applicazioni. Se questo non è disponibile, è necessario utilizzare PBKDF2 o scrypt. E infine se nessuno dei 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 metodo efficace per scomporre molte password contemporaneamente. Invece, memorizzare il salato  hash. Un salt è una stringa aggiunta alla password prima dell'hashing - usa un diverso (random) salt per utente. Il sale è un valore pubblico, quindi è possibile memorizzarli con l'hash nel database. Vedere Qui  per di più su questo.

Ciò significa che non puoi inviare all'utente le password dimenticate (perché hai solo l'hash). Non reimpostare la password dell'utente se non si è autenticato l'utente (gli utenti devono dimostrare di essere in grado di leggere le email inviate all'indirizzo di posta memorizzato (e convalidato).)

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. Leggere PARTE III: Utilizzo di domande segrete  in @Jens Roland risposta  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 quanto il resto della macchina del cliente e altre comunicazioni. Possono essere letti dal disco, annusati nel traffico di rete, sollevati da un attacco di scripting cross-site, prelevati da un DNS avvelenato, in modo che il client invii i loro cookie ai server sbagliati. Non inviare cookie persistenti. I cookie dovrebbero scadere alla fine della sessione client (chiusura del browser o uscita dal dominio).

Se desideri eseguire l'autologin dei tuoi utenti, puoi impostare un cookie persistente, ma dovrebbe essere diverso da un cookie di sessione completa. È possibile impostare un contrassegno aggiuntivo che l'utente ha effettuato l'accesso automatico e deve effettuare l'accesso per le operazioni sensibili. Questo è popolare tra i siti di shopping che desiderano offrirti un'esperienza di acquisto personalizzata e senza soluzione di continuità, ma proteggere i tuoi dati finanziari. Ad esempio, quando torni a visitare Amazon, ti mostrano una pagina che sembra aver effettuato l'accesso, ma quando vai a effettuare un ordine (o cambia il tuo indirizzo di spedizione, carta di credito, ecc.), Ti chiedono di confermare la tua password.

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

Elenco di risorse esterne


387



In primo luogo, un avvertimento forte che questa risposta non è la soluzione migliore per questa domanda esatta. Non dovrebbe assolutamente essere la risposta migliore!

Andrò avanti e menzionerò la proposta di Mozilla BrowserID  (o forse più precisamente, il Protocollo Email verificato ) nello spirito di trovare un percorso di aggiornamento per approcci migliori all'autenticazione in futuro.

Lo riassumerò in questo modo:

  1. Mozilla è un'organizzazione non profit con valori  che si allinea 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 ha un grosso svantaggio, che comporta un aumento del rischio di phishing . Agli utenti viene richiesto di inserire informazioni sensibili in un'area controllata da un'entità remota, piuttosto che in un'area controllata dal loro User Agent (browser).
  4. Poiché i browser sono implicitamente attendibili (l'intera idea di un agente utente deve agire per conto dell'utente), possono contribuire a migliorare questa situazione.
  5. La forza primaria che trattiene il progresso qui è stallo nella distribuzione . Le soluzioni devono essere scomposte in fasi che forniscono un vantaggio incrementale per conto proprio.
  6. Il metodo decentralizzato più semplice per esprimere l'identità che è incorporato nell'infrastruttura internet è il nome di dominio.
  7. Come secondo livello di espressione dell'identità, ciascun dominio gestisce il proprio insieme di account.
  8. Il modulo "account @dominio "è conciso e supportato da una vasta gamma di protocolli e schemi URI. Tale identificatore è, ovviamente, universalmente riconosciuto come indirizzo email.
  9. I provider di posta elettronica sono già di fatto i provider di identità primari online. Gli attuali flussi di reimpostazione della password ti consentono di assumere il controllo di un account se riesci a dimostrare di controllare l'indirizzo email associato a tale account.
  10. Il protocollo di posta elettronica verificato è stato proposto per fornire un metodo sicuro, basato sulla crittografia a chiave pubblica, per semplificare il processo di dimostrare al dominio B che si dispone di un account sul dominio A.
  11. Per i browser che non supportano il protocollo di posta elettronica 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 utente su un utente. Non è desiderabile avere un gran numero di tali terze parti; questa capacità è intesa solo per consentire un percorso di aggiornamento ed è molto preferibile che i servizi di posta elettronica forniscano tali asserzioni.
  13. Mozilla offre il proprio servizio per agire come una terza parte di fiducia. I fornitori di servizi (ovvero le Parti richiedenti) che implementano il protocollo di posta elettronica verificato possono scegliere di considerare attendibili le asserzioni di Mozilla. Il servizio di Mozilla verifica la proprietà dell'account degli utenti utilizzando i metodi convenzionali di invio di un'email con un link di conferma.
  14. I fornitori di servizi possono, ovviamente, offrire questo protocollo come opzione in aggiunta a qualsiasi altro metodo di autenticazione che desiderano offrire.
  15. Un grande vantaggio per l'interfaccia utente che si cerca qui è il "selettore di identità". Quando un utente visita un sito e sceglie di autenticarsi, il browser visualizza una selezione di indirizzi e-mail ("personale", "lavoro", "attivismo politico", ecc.) Che possono utilizzare per identificarsi al sito.
  16. Un altro grande vantaggio di interfaccia utente che viene richiesto come parte di questo sforzo è aiutare il browser a saperne di più sulla sessione dell'utente  - a chi hanno eseguito l'accesso come al momento, in primo luogo - in modo che possa visualizzarlo nel browser chrome.
  17. A causa della natura distribuita di questo sistema, evita il lock-in su siti importanti come Facebook, Twitter, Google, ecc. Ogni individuo può possedere il proprio dominio e quindi agire come il proprio provider di identità.

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


146



Ho pensato di condividere questa soluzione che ho trovato funzionante.

Lo chiamo il Campo fittizio  (anche se non l'ho inventato così non mi credito).

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

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

Il trucco è ingannare un bot nel pensare di dover inserire i dati in un campo obbligatorio, ecco perché ho chiamato l'input "email". Se hai già un campo chiamato email che stai usando dovresti provare a nominare il campo fittizio qualcos'altro come "company", "phone" o "emailaddress". Scegli qualcosa che sai di non aver bisogno e che suoni come qualcosa che le persone normalmente trovano logico da compilare in un modulo web. Ora nascondi il input campo utilizzando CSS o JavaScript / jQuery - tutto ciò che si adatta meglio - giusto non  imposta l'input type a hidden altrimenti il ​​bot non cadrà per questo.

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

Esempio:

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

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

Ho usato questo metodo su un libro degli ospiti in combinazione con CAPTCHA e da allora non vedo più un singolo messaggio spam. Avevo già usato una soluzione solo per CAPTCHA, ma alla fine ci sono stati circa cinque messaggi spam ogni ora. L'aggiunta del campo fittizio nel modulo ha interrotto (almeno fino ad ora) tutto lo spam dall'apparire.

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

avvertimento : Ovviamente questo metodo non è al 100% infallibile. I robot possono essere programmati per ignorare i campi di input con lo stile display:none applicato ad esso. Devi anche pensare alle persone che usano una qualche forma di completamento automatico (come la maggior parte dei browser hanno incorporato!) Per riempire automaticamente tutti i campi del modulo per loro. Potrebbero anche prendere un campo fittizio.

Puoi anche variare un po 'questo lasciando il campo fittizio visibile ma fuori dai confini dello schermo, ma questo dipende totalmente da te.

Essere creativo!


120



Non credo che la risposta 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 off".

Le mie modifiche / risposte suggerite sono

  • Il problema risiede più nell'impostazione dell'account che nel controllo della password.
  • L'uso di due fattori di authenitication è molto più sicuro rispetto a metodi più intelligenti di crittografia della password
  • NON cercare di implementare il proprio modulo di accesso o la memorizzazione del database delle password, a meno che i dati memorizzati sono privi di valore alla creazione dell'account e autogenerati (ovvero, lo stile Web 2.0 come Facebook, Flickr , eccetera.)

    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.

Ciò evita qualsiasi necessità di avere "sessioni" o cookie, in quanto il browser stesso crittograferà nuovamente la comunicazione ogni volta. È l'approccio di sviluppo più "leggero".

Tuttavia, non lo consiglio, ad eccezione dei servizi pubblici a basso valore. Questo è un problema con alcune delle altre risposte sopra - non provare a reimplementare i meccanismi di autenticazione lato server - questo problema è stato risolto ed è supportato dalla maggior parte dei browser principali. Non usare i cookie. Non conservare nulla nel tuo database personalizzato. Basta chiedere, per richiesta, se la richiesta è autenticata. Tutto il resto dovrebbe essere supportato dalla configurazione e dal software fidato di terze parti.

Così ...

Innanzitutto, stiamo confondendo la creazione iniziale di un account (con una password) con il ricontrollare la 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 account della rete intranet / extranet dell'ospedale, il valore risiede in tutte le cartelle cliniche, e così io fare  cura dell'identità (*) del creatore dell'account.

Questa è la parte molto difficile. Il solo  la 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 cancelli tutti con la chiave privata. Quindi visiti l'ospedale e l'amministratore di sistema guarda il tuo passaporto, vede se la foto ti corrisponde e poi la hash della pagina web / foto con la chiave privata dell'ospedale. D'ora in poi possiamo scambiare in modo sicuro chiavi e gettoni. Come può chiunque si fida dell'ospedale (c'è la salsa segreta BTW). L'amministratore di sistema può anche darti un RSA  dongle o altra autenticazione a due fattori.

Ma questo è un lotto  di seccature, 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 - Single Sign-On sui meccanismi con una terza parte fidata - fondamentalmente l'utente verifica contro una terza parte fidata. (NB questo non è in alcun modo il non essere attendibile OAuth )

  2. SRP  - Una sorta di autenticazione intelligente della password senza una terza parte affidabile. Ma qui stiamo entrando nel regno di "è più sicuro usare l'autenticazione a due fattori, anche se è più costoso"

  3. SSL  lato client - fornisce ai clienti un certificato di chiave pubblica (supporto in tutti i principali browser) ma solleva domande sulla sicurezza dei computer client).

Alla fine è un compromesso: qual è il costo di una violazione della sicurezza rispetto al costo di implementare approcci più sicuri. Un giorno, potremmo vedere un vero e proprio PKI  ampiamente accettato e quindi non più propri moduli e database di autenticazione laminati. Un giorno...


71



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

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


48



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

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


46