La guida definitiva all'autenticazione dei siti Web basata su moduli [chiuso]

StackOverflow https://stackoverflow.com/questions/549

Domanda

Autenticazione basata su moduli per i siti Web

Riteniamo che Stack Overflow non debba essere solo una risorsa per domande tecniche molto specifiche, ma anche per linee guida generali su come risolvere le variazioni sui problemi comuni.L'"autenticazione basata su moduli per i siti web" dovrebbe essere un ottimo 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 memorizzare le password
  • Utilizzando domande segrete
  • Funzionalità nome utente/password dimenticata
  • Utilizzo di nonce impedire falsificazioni di richieste tra siti (CSRF)
  • OpenID
  • Casella di controllo "Ricordami".
  • Completamento automatico del browser di nomi utente e password
  • URL segreti (pubblici URL protetto dal digest)
  • Verifica della robustezza della password
  • Convalida della posta elettronica
  • e molto altro ancora autenticazione basata su modulo...

Non dovrebbe includere cose come:

  • Ruoli e autorizzazioni
  • Autenticazione di base HTTP

Per favore aiutaci:

  1. Suggerire sottoargomenti
  2. Invio di buoni articoli su questo argomento
  3. Modifica della risposta ufficiale
È stato utile?

Soluzione

PARTE I:Come accedere

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

Su HTTPS o non su HTTPS?

A meno che la connessione non sia già sicura (ovvero, tunneling tramite HTTPS utilizzando SSL/TLS), i valori del modulo di accesso verranno inviati in chiaro, il che consente a chiunque origlia la linea tra browser e server web di poter leggere gli accessi mentre passano Attraverso.Questo tipo di intercettazioni viene effettuato abitualmente dai governi, ma in generale non ci occuperemo dei cavi "di proprietà" se non per dire questo:Se stai proteggendo qualcosa di importante, usa HTTPS.

In sostanza, l'unico pratico Un modo per proteggersi dalle intercettazioni/sniffing di pacchetti durante l'accesso è utilizzare HTTPS o un altro schema di crittografia basato su certificato (ad esempio, TLS) o uno schema di risposta-prova comprovato e testato (ad esempio, il Diffie-HellmanSRP basato su SRP). Qualsiasi altro metodo può essere facilmente aggirato da un aggressore che ha ascoltato di nascosto.

Naturalmente, se sei disposto a diventare un po' poco pratico, potresti anche utilizzare una qualche forma di schema di autenticazione a due fattori (ad es.l'app Google Authenticator, un codebook fisico in "stile guerra fredda" o un dongle per il 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 farlo) Crittografia/hashing JavaScript personalizzato

Dato il costo diverso da zero e la difficoltà tecnica percepita nell'impostare un certificato SSL sul tuo sito web, alcuni sviluppatori sono tentati di implementare i propri schemi di hashing o crittografia interni al browser per evitare di passare accessi in chiaro su un cavo non protetto.

Sebbene questo sia un pensiero nobile, è essenzialmente inutile (e può essere a falla di sicurezza) a meno che non sia combinato con uno dei precedenti, ovvero proteggere la linea con una crittografia avanzata o utilizzare un meccanismo di sfida-risposta collaudato (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 nel campo della sicurezza digitale).

Anche se è vero che l'hashing della password può essere efficace contro divulgazione della password, è vulnerabile agli attacchi di replay, agli attacchi/dirottamenti Man-In-The-Middle (se un utente malintenzionato può inserire alcuni byte nella tua pagina HTML non protetta prima che raggiunga il tuo browser, può semplicemente commentare l'hashing nel JavaScript), o attacchi di forza bruta (poiché stai consegnando all'aggressore sia il nome utente, il sale e la password con hash).

CAPTCHA contro l'umanità

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

Tieni presente che le implementazioni CAPTCHA non sono create allo stesso modo;spesso non sono risolvibili dall'uomo, la maggior parte di essi sono in realtà inefficaci contro i robot, tutti sono inefficaci contro la manodopera a basso costo del terzo mondo (secondo OWASP, l'attuale tasso di sfruttamento è di 12 dollari per 500 test) e alcune implementazioni potrebbero essere tecnicamente illegali in alcuni paesi (vedi Foglio informativo sull'autenticazione OWASP).Se devi utilizzare un CAPTCHA, utilizza quello di Google reCAPTCHA, poiché è difficile per l'OCR per definizione (poiché utilizza scansioni di libri già classificate erroneamente dall'OCR) e si sforza di essere facile da usare.

Personalmente, tendo a trovare fastidiosi i CAPTCHAS e a usarli solo come ultima risorsa quando un utente non è riuscito ad accedere più volte e i ritardi di limitazione sono esauriti.Ciò accadrà abbastanza raramente da essere accettabile e rafforzerà il sistema nel suo insieme.

Memorizzazione delle password/Verifica degli accessi

Questo potrebbe finalmente essere di dominio pubblico dopo tutti gli hack altamente pubblicizzati e le fughe di dati degli utenti che abbiamo visto negli ultimi anni, ma va detto:Non memorizzare le password in chiaro nel database.I database degli utenti vengono regolarmente violati, trapelati o raccolti tramite SQL injection e, se si archiviano password grezze e in chiaro, la partita è finita immediatamente per la sicurezza dell'accesso.

Quindi, se non riesci a memorizzare la password, come controlli che la combinazione login+password INSERITA dal modulo di login sia corretta?La risposta è l'hashing utilizzando a funzione di derivazione chiave.Ogni volta che viene creato un nuovo utente o viene modificata una password, prendi la password e la esegui tramite 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, esegui la stessa funzione hash sulla password inserita, questa volta passando il salt e confronta la stringa hash risultante con il valore memorizzato nel tuo 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 utilizzato un salt è che l'hashing di per sé non è sufficiente: ti consigliamo di aggiungere un cosiddetto "sal" per proteggere l'hash da tavoli arcobaleno.Un salt impedisce efficacemente che due password che corrispondono esattamente vengano archiviate come lo stesso valore hash, impedendo che l'intero database venga scansionato in un'unica esecuzione se un utente malintenzionato sta eseguendo un attacco che indovina la password.

Un hash crittografico non deve essere utilizzato per l'archiviazione delle password perché le password selezionate dall'utente non sono abbastanza forti (ad es.di solito non contengono 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 in modo efficace "tira la chiave", il che significa che ogni password indovinata da un utente malintenzionato causa più ripetizioni dell'algoritmo hash, ad esempio 10.000 volte, il che fa sì che l'utente malintenzionato indovini la password 10.000 volte più lentamente.

Dati della sessione - "Sei loggato come Spiderman69"

Una volta che il server ha verificato il login e la password rispetto al database degli utenti e ha trovato una corrispondenza, il sistema ha bisogno di un modo per ricordare che il browser è stato autenticato.Questo fatto dovrebbe essere memorizzato solo lato server nei dati della sessione.

Se non hai 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 di sessione, archiviati sul server.Se stai utilizzando un framework MVC, questo è senza dubbio già gestito.

Se possibile, assicurati che il cookie di sessione abbia i flag sicuro e Solo HTTP impostati quando viene inviato al browser.Il flag HttpOnly fornisce una certa protezione contro la lettura del cookie tramite un attacco XSS.Il flag 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.Laddove venga presentato un cookie che fa riferimento a una sessione inesistente, il suo valore dovrebbe essere sostituito immediatamente per prevenirlo fissazione della sessione.

SECONDA PARTE:Come rimanere connesso: la famigerata casella di controllo "Ricordami".

I cookie di accesso persistenti (funzionalità "Ricordami") sono una zona pericolosa;da un lato sono del tutto sicuri quanto i login convenzionali quando gli utenti capiscono come gestirli;e, d'altro canto, rappresentano un enorme rischio per la sicurezza nelle mani di utenti disattenti, che potrebbero utilizzarli su computer pubblici e dimenticare di disconnettersi e che potrebbero non sapere cosa 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 sicurezza.Se sei sicuro che i tuoi utenti sappiano la stessa cosa, puoi utilizzare accessi persistenti con la coscienza pulita.In caso contrario, beh, allora potresti aderire alla filosofia secondo cui gli utenti che sono negligenti con le proprie credenziali di accesso se la prendono se vengono hackerati.Non è nemmeno che andiamo a casa dei nostri utenti e strappiamo tutti quei post-it con le password che inducono facepalm che hanno allineati sul bordo dei loro monitor.

Naturalmente, alcuni sistemi non possono permetterselo Qualunque account violati;per tali sistemi, non è possibile giustificare in alcun modo l'avere accessi persistenti.

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

  1. Per prima cosa, prenditi del tempo per leggere Articolo di Paragon Initiative a questo proposito.Avrai bisogno di comprendere correttamente un sacco di elementi e l'articolo fa un ottimo lavoro nel spiegarli.

  2. E giusto per ribadire una delle trappole più comuni, NON CONSERVARE IL COOKIE DI LOGIN PERSISTENTE (TOKEN) NEL TUO DATABASE, SOLO UN HASH! Il token di accesso è equivalente alla password, quindi se un utente malintenzionato mettesse 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, utilizzare l'hashing (secondo https://security.stackexchange.com/a/63438/5002 un hash debole andrà benissimo per questo scopo) quando si memorizzano token di accesso persistenti.

PARTE III:Utilizzando domande segrete

Non implementare "domande segrete".La funzione "domande segrete" è un anti-pattern di sicurezza.Leggi il documento dal collegamento numero 4 dall'elenco DA LEGGERE.Puoi chiederlo a Sarah Palin, dopo il suo Yahoo!L'account e-mail è stato violato durante una precedente campagna presidenziale perché la risposta alla sua domanda di sicurezza era..."Liceo Wasilla"!

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

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

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

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

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

Il vero motivo per cui le domande di sicurezza esistono anche in natura è che consentono di risparmiare convenientemente sul costo di alcune chiamate di supporto da parte di utenti che non possono accedere alla propria posta elettronica per ottenere un codice di riattivazione.Questo a scapito della sicurezza e della reputazione di Sarah Palin.Ne vale la pena?Probabilmente no.

PARTE IV:Funzionalità password dimenticata

Ho già detto perché dovresti non utilizzare mai domande di sicurezza per la gestione delle password utente dimenticate/perse;è inoltre ovvio che non dovresti mai inviare tramite e-mail agli utenti le loro password effettive.Ci sono almeno altre due trappole fin troppo comuni da evitare in questo campo:

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

  2. Hashing sempre il codice/token della password smarrita nel database. ANCORA, questo codice è un altro esempio di password equivalente, quindi DEVE essere sottoposto ad hashing nel caso in cui un utente malintenzionato abbia messo le mani sul tuo database.Quando viene richiesto un codice per la password smarrita, invia il codice in testo normale all'indirizzo email dell'utente, quindi esegui l'hashing, salva l'hash nel tuo database e buttare via l'originale.Proprio come una password o un token di accesso persistente.

Una nota finale:assicurati sempre che la tua interfaccia per inserire il "codice password smarrita" sia sicura almeno quanto il tuo modulo di accesso stesso, altrimenti un utente malintenzionato la utilizzerà semplicemente per ottenere l'accesso.Assicurarsi di generare "codici password perdute" molto lunghi (ad esempio, 16 caratteri alfanumerici con distinzione tra maiuscole e minuscole) è un buon inizio, ma considera l'aggiunta dello stesso schema di limitazione utilizzato per il modulo di accesso stesso.

PARTE V:Verifica della robustezza della password

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

Ok, quindi forse l'elenco non è il canonico elenco delle password più comuni su Qualunque sistema ovunque e mai, ma è un buon indicatore di quanto le persone sceglieranno male la propria password quando non esiste una politica applicata.Inoltre, l’elenco sembra spaventosamente vicino a noi se lo confrontiamo con le analisi disponibili pubblicamente sulle password rubate di recente.

COSÌ:Senza requisiti minimi di sicurezza della password, il 2% degli utenti utilizza una delle 20 password più comuni.Senso:se un utente malintenzionato ottiene solo 20 tentativi, 1 account su 50 sul tuo sito web sarà violabile.

Per contrastare ciò è necessario calcolare l’entropia di una password e quindi applicare una soglia.L'Istituto Nazionale di Standard e Tecnologia (NIST) Pubblicazione speciale 800-63 ha una serie di ottimi suggerimenti.Questo, se combinato con un dizionario e un'analisi del layout della tastiera (ad esempio, "qwertyuiop" è una password errata), può rifiuta il 99% di tutte le password scarsamente selezionate ad 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, molti utenti molto probabilmente lo ignoreranno.

E per un approccio rinfrescante alla facilità d'uso delle password ad alta entropia, Randall Munroe Forza della password xkcd è altamente raccomandato.

Utilizza Troy Hunt Sono stato Pwned API per verificare le password degli utenti rispetto alle password compromesse in violazioni di dati pubblici.

PARTE VI:Molto altro - Oppure:Prevenire tentativi di accesso rapidi

Per prima cosa, dai un'occhiata ai numeri: Velocità di recupero password: quanto tempo durerà la tua password

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

  1. Prende praticamente senza tempo per decifrare una password debole, anche se la stai decifrando con un abaco

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

  3. Prende praticamente senza tempo per decifrare una password complessa, composta da simboli, lettere e numeri, maiuscole e minuscole, se è meno di 8 caratteri (un PC desktop può eseguire la ricerca nell'intero spazio delle chiavi fino a 7 caratteri nel giro di giorni o addirittura ore)

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

Allora cosa possiamo imparare da questi numeri?Bene, molti, ma possiamo concentrarci sulla parte più importante:il fatto che impedire un gran numero di tentativi di accesso successivi e rapidi (ad es.IL forza bruta attack) non è poi così difficile.Ma prevenendolo Giusto non è così facile come sembra.

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

  • Presentare a CAPTCHA dopo N tentativi falliti (fastidiosissimo e spesso inefficace -- ma qui mi ripeto)

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

  • E infine, limitazione dell'accesso:ovvero, impostando un ritardo 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 portare a termine).

Migliore pratica n. 1: Un breve ritardo che aumenta con il numero di tentativi falliti, come:

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

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

Chiarire:Il ritardo è non un ritardo prima di restituire la risposta al browser.È più simile a un timeout o un periodo refrattario durante il quale i tentativi di accesso a un account specifico o da un indirizzo IP specifico non verranno accettati o valutati affatto.Ciò significa che le credenziali corrette non verranno restituite in caso di accesso riuscito e le credenziali errate non attiveranno un aumento del ritardo.

Migliore pratica 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

Un attacco DoS a questo schema sarebbe poco pratico, ma certamente fattibile.Inoltre, potrebbe essere rilevante notare che un ritardo così lungo può essere molto fastidioso per un utente legittimo.Gli utenti smemorati non ti piaceranno.

Migliore pratica n. 3: Combinando i due approcci: un breve ritardo fisso che entra in vigore dopo N tentativi falliti, come:

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

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

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

Questo schema finale è stato preso dai suggerimenti delle migliori pratiche OWASP (link 1 dall'elenco DA LEGGERE) e dovrebbe essere considerato la migliore pratica, anche se è certamente restrittivo.

Come regola generale, però, direi:più forte è la tua politica sulla password, meno dovrai infastidire gli utenti con ritardi.Se richiedi password complesse (alfanumerici con distinzione tra maiuscole e minuscole + numeri e simboli richiesti) di oltre 9 caratteri, puoi concedere agli utenti 2-4 tentativi di password non ritardati prima di attivare la limitazione.

Un attacco DoS a questo schema di limitazione dell'accesso finale lo sarebbe molto poco pratico.E come tocco finale, consenti sempre il passaggio degli accessi persistenti (cookie) (e/o un modulo di accesso verificato tramite CAPTCHA), in modo che gli utenti legittimi non subiscano nemmeno ritardi mentre l'attacco è in corso.In questo modo, l'attacco DoS, molto poco pratico, diventa un attacco DoS estremamente attacco impraticabile.

Inoltre, ha senso applicare una limitazione più aggressiva agli account amministratore, poiché questi sono i punti di ingresso più interessanti

PARTE VII:Attacchi di forza bruta distribuiti

Per inciso, gli aggressori più avanzati cercheranno di aggirare la limitazione dell'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 (cosa che non possono fare a causa delle nostre limitazioni), sceglieranno LA password più comune e la proveranno invece contro 50.000 utenti.In questo modo, non solo riescono ad aggirare le misure relative al numero massimo di tentativi come i CAPTCHA e la limitazione dell'accesso, ma aumentano anche le loro possibilità di successo, poiché la password numero 1 più comune è molto più probabile della numero 49.995.

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

Qui, la migliore pratica sarebbe registrando il numero di accessi non riusciti, a livello di sistema, e utilizzando una media corrente della frequenza di accessi errati del tuo sito come base per un limite massimo da imporre a tutti gli utenti.

Troppo astratto?Lasciatemi riformulare:

Supponiamo che il tuo sito abbia avuto una media di 120 accessi errati al giorno negli ultimi 3 mesi.Usando quello (media corrente), il tuo sistema potrebbe impostare il limite globale su 3 volte quello, ad es.360 tentativi falliti in un periodo di 24 ore.Quindi, se il numero totale di tentativi falliti su tutti gli account supera quel numero entro un giorno (o, meglio ancora, monitora 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 (ancora, ad eccezione degli accessi tramite cookie e/o accessi CAPTCHA di backup).

Ho anche postato una domanda con maggiori dettagli e un'ottima discussione su come evitare trappole complicate nel respingere attacchi di forza bruta distribuiti

PARTE VIII:Autenticazione a due fattori e provider di autenticazione

Le credenziali possono essere compromesse da exploit, password annotate e perse, furto di laptop con chiavi o accesso da parte di utenti 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 fornitori 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 fidata.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. Cose da fare e da non fare durante l'autenticazione del client sul Web (documento di ricerca del MIT molto leggibile)
  3. Wikipedia:Biscotto HTTP
  4. Domande di conoscenza personale per l'autenticazione di fallback:Domande di sicurezza nell'era di Facebook (documento di ricerca di Berkeley molto leggibile)

Altri suggerimenti

Articolo definitivo

Invio credenziali

L'unico modo pratico per inviare credenziali in modo sicuro al 100% è utilizzare SSL.Usare JavaScript per eseguire l'hashing della password non è sicuro.Insidie ​​​​comuni per l'hashing della password lato client:

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

C'è un altro metodo sicuro chiamato Prezzo consigliato, ma è brevettato (sebbene lo sia concesso in licenza liberamente) e ci sono poche 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 riutilizzino la password del proprio conto bancario online.Quindi, memorizza la password con hash e butta via l'originale.E assicurati che la password non venga visualizzata nei registri di accesso o nei registri delle applicazioni.OWASP raccomanda l'uso di Argon2 come prima scelta per le nuove applicazioni.Se questo non è disponibile, è necessario utilizzare PBKDF2 o scrypt.E infine, se nessuno dei precedenti è disponibile, usa bcrypt.

Anche gli hash di per sé non sono sicuri.Ad esempio, password identiche significano hash identici: questo rende le tabelle di ricerca hash un modo efficace per decifrare molte password contemporaneamente.Conserva invece il file salato hash.Un salt è una stringa aggiunta alla password prima dell'hashing: utilizza un salt diverso (casuale) per utente.Il sale è un valore pubblico, quindi puoi memorizzarlo con l'hash nel database.Vedere Qui per saperne 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 a meno che tu non abbia autenticato l'utente (gli utenti devono dimostrare di essere in grado di leggere le email inviate all'indirizzo email memorizzato (e convalidato).)

Domande di sicurezza

Le domande di sicurezza non sono sicure: evita di utilizzarle.Perché?Qualunque cosa faccia una domanda di sicurezza, una password fa meglio.Leggere PARTE III:Utilizzando domande segrete In @Jens Roland risponde qui in questa 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 quanto il resto della macchina del cliente e le altre comunicazioni.Possono essere letti dal disco, intercettati nel traffico di rete, rilevati da un attacco di scripting cross-site, sottoposti a phishing da un DNS avvelenato in modo che il client invii i cookie ai server sbagliati.Non inviare cookie persistenti.I cookie dovrebbero scadere alla fine della sessione del client (chiusura del browser o abbandono del dominio).

Se desideri accedere automaticamente ai tuoi utenti, puoi impostare un cookie persistente, ma dovrebbe essere distinto da un cookie di sessione completa.È possibile impostare un contrassegno aggiuntivo che indica che l'utente ha effettuato l'accesso automatico e che deve accedere realmente per operazioni sensibili.Questo è popolare tra i siti di shopping che desiderano offrirti un'esperienza di acquisto personalizzata e senza interruzioni, proteggendo comunque i tuoi dati finanziari.Ad esempio, quando torni a visitare Amazon, ti mostrano una pagina in cui 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, invece, contengono solo dati sensibili e non dovrebbero consentire l’accesso automatico o modalità a bassa sicurezza.

Elenco delle risorse esterne

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

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

Lo riassumerò 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 moduli presenta un grosso svantaggio, che rappresenta un rischio maggiore phishing.Agli utenti viene chiesto di inserire informazioni sensibili in un'area controllata da un'entità remota, piuttosto che in un'area controllata dal proprio User Agent (browser).
  4. Poiché i browser sono implicitamente affidabili (l'idea stessa di un agente utente è quella di agire per conto dell'utente), possono aiutare a migliorare questa situazione.
  5. La forza principale che frena il progresso qui è situazione di stallo nella distribuzione.Le soluzioni devono essere scomposte in fasi che da sole forniscano qualche beneficio incrementale.
  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à, ciascun dominio gestisce il proprio set di account.
  8. Il modulo “conto@domain” è conciso e supportato da un'ampia 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 principali fornitori di identità online.Gli attuali flussi di reimpostazione della password di solito ti consentono di assumere il controllo di un account se puoi dimostrare di controllare l'indirizzo email associato a tale account.
  10. Il protocollo di posta elettronica verificata è 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 Verified Email Protocol (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 terze parti di agire come intermediario fidato, affermando di aver verificato la proprietà di un account da parte di un utente.Non è auspicabile avere un gran numero di tali terze parti;questa funzionalità è intesa solo per consentire un percorso di aggiornamento ed è preferibile che i servizi di posta elettronica forniscano essi stessi queste asserzioni.
  13. Mozilla offre il proprio servizio per agire come una terza parte fidata.I fornitori di servizi (ovvero, le parti che fanno affidamento) che implementano il protocollo di posta elettronica verificata 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 di invio di un'e-mail con un collegamento di conferma.
  14. I fornitori di servizi possono, ovviamente, offrire questo protocollo come opzione in aggiunta a qualsiasi altro metodo 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 una selezione di indirizzi email (“personale”, “lavoro”, “attivismo politico”, ecc.) che può utilizzare per identificarsi nel sito.
  16. Un altro grande vantaggio dell'interfaccia utente ricercato come parte di questo sforzo è aiutare il browser a saperne di più sulla sessione dell'utente – con chi hanno effettuato l'accesso attualmente, principalmente – quindi potrebbe visualizzarlo nel browser Chrome.
  17. A causa della natura distribuita di questo sistema, evita il vincolo ai siti principali come Facebook, Twitter, Google, ecc.Qualsiasi individuo può possedere il proprio dominio e quindi agire come fornitore di identità.

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

Ho solo pensato di condividere questa soluzione che ho scoperto funzionare perfettamente.

Lo chiamo il Campo fittizio (anche se non l'ho inventato io, quindi non darmi credito).

In breve:devi solo inserirlo nel tuo <form> e controlla che sia vuoto al momento della convalida:

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

Il trucco è ingannare un bot facendogli credere di dover inserire dati in un campo obbligatorio, ecco perché ho chiamato l'input "email".Se hai già un campo chiamato email che stai utilizzando, dovresti provare a nominare il campo fittizio qualcos'altro come "azienda", "telefono" o "indirizzo email".Scegli semplicemente qualcosa che sai di non aver bisogno e che suona come qualcosa che le persone normalmente troverebbero logico compilare in un modulo web.Ora nascondi il input utilizzando CSS o JavaScript/jQuery, qualunque sia la soluzione migliore per te, semplicemente non impostare l'ingresso type A hidden altrimenti il ​​bot non ci cascherà.

Quando convalidi il modulo (lato client o lato server), controlla 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 "email") e non tenterà di compilarlo.Quindi il valore del campo fittizio dovrebbe essere ancora vuoto una volta inviato il modulo.

In caso di bot: Il bot vedrà un campo il cui tipo è text e un nome email (o come lo hai chiamato) e tenterà logicamente di riempirlo con i dati appropriati.Non importa se hai stilizzato il modulo di input con alcuni CSS fantasiosi, gli sviluppatori web lo fanno sempre.Qualunque sia il valore nel campo fittizio, non ci interessa purché sia ​​maggiore di 0 caratteri.

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

Credo che questo possa essere utilizzato perfettamente anche con un modulo di accesso/autenticazione.

Avvertimento:Naturalmente questo metodo non è infallibile al 100%.I bot possono essere programmati per ignorare i campi di input con lo stile display:none applicato ad esso.Devi anche pensare alle persone che utilizzano una qualche forma di completamento automatico (come la maggior parte dei browser è integrata!) per compilare automaticamente tutti i campi del modulo.Potrebbero anche scegliere un campo fittizio.

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

Essere creativo!

Non penso che la risposta di cui sopra sia "sbagliata" ma ci sono ampie aree di autenticazione che non vengono toccate (o meglio 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ù nella configurazione dell'account che nel controllo della password.
  • L'uso dell'autenticazione a due fattori è molto più sicuro rispetto ai mezzi più intelligenti di crittografia della password

  • Non provare ad implementare il proprio modulo di accesso o archiviazione di database di password, a meno che i dati da archiviare non sono preziosi nella creazione di account e autogenerati (cioè in stile Web 2.0 come Facebook, Flickr, eccetera.)

    1. L'autenticazione del digest è un approccio basato su standard supportato in tutti i principali browser e server, che non invierà una password nemmeno su un canale sicuro.

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

Tuttavia non lo consiglio, tranne che per i servizi pubblici di 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 utilizzare i cookie.Non archiviare nulla nel tuo database creato manualmente.Basta chiedere, per richiesta, se la richiesta è autenticata.Tutto il resto dovrebbe essere supportato dalla configurazione e da software attendibile di terze parti.

COSÌ ...

Innanzitutto confondiamo la creazione iniziale di un account (con password) con il successivo controllo della password.Se sono Flickr e creo il tuo sito per la prima volta, il nuovo utente ha accesso al valore zero (spazio web vuoto).Davvero non mi interessa se la persona che crea l'account mente sul proprio nome.Se sto creando un account della intranet/extranet dell'ospedale, il valore sta in tutta la cartella clinica, e quindi io Fare preoccuparsi dell'identità (*) del creatore dell'account.

Questa è la parte davvero molto difficile.IL soltanto una soluzione decente è una rete di fiducia.Ad esempio, entri in ospedale come medico.Crei una pagina web ospitata da qualche parte con la tua foto, il numero del tuo 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, vede se la foto corrisponde a te e quindi esegue l'hash della pagina web/foto con la chiave privata dell'ospedale.D'ora in poi possiamo scambiare chiavi e token in modo sicuro.Come può chiunque si fidi dell'ospedale (c'è la salsa segreta tra l'altro).L'amministratore di sistema può anche darti un file RSA dongle o altra autenticazione a due fattori.

Ma questo è un quantità una seccatura e non proprio web 2.0.Tuttavia, è l'unico modo sicuro per creare nuovi account che abbiano accesso a informazioni preziose che non sono state create autonomamente.

  1. Kerberos e SPNEGO - meccanismi di accesso singolo con una terza parte fidata - fondamentalmente l'utente verifica rispetto a una terza parte fidata.(NB: questo non è in alcun modo di cui non fidarsi OAuth)

  2. Prezzo consigliato - sorta di autenticazione intelligente della password senza una terza parte fidata.Ma qui stiamo entrando nel campo del "è più sicuro usare l'autenticazione a due fattori, anche se è più costoso"

  3. SSL lato client: fornisce ai client un certificato a chiave pubblica (supporto in tutti i principali browser, ma solleva dubbi sulla sicurezza della macchina client).

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

Durante 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 puoi creare hash, più velocemente può funzionare qualsiasi controllo della forza bruta.Gli hash più lenti rallenteranno quindi la forzatura bruta.Un algoritmo di hash lento renderà impraticabile la forzatura bruta per password più lunghe (8 cifre +)

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

Blog tecnico Dropbox » Archivio blog » zxcvbn:stima realistica della forza della password

La mia regola preferita per quanto riguarda i sistemi di autenticazione:utilizzare passphrase, non password.Facile da ricordare, difficile da decifrare.Ulteriori informazioni: Orrore in codifica:Password controPassa frasi

Vorrei aggiungere un suggerimento che ho utilizzato, basato sulla difesa in profondità.Non è necessario disporre dello stesso sistema di autenticazione per gli amministratori e per gli utenti normali.È possibile avere un modulo di accesso separato su un URL separato che esegue codice separato per le richieste che garantiranno privilegi elevati.Questo può fare scelte che sarebbero una vera seccatura per gli utenti abituali.Uno di questi che ho utilizzato è quello di codificare effettivamente l'URL di accesso per l'accesso come amministratore e inviare tramite e-mail all'amministratore il nuovo URL.Blocca immediatamente qualsiasi attacco di forza bruta poiché il tuo nuovo URL può essere arbitrariamente difficile (stringa casuale molto lunga) ma l'unico inconveniente dell'utente amministratore è seguire un collegamento nella sua email.L'attaccante non sa più nemmeno dove effettuare il POST.

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

Per quanto riguarda il poing PARTE IV:Funzionalità password dimenticata nella prima risposta, vorrei sottolineare i Timing Attack.

Nel Ricorda la tua password moduli, un utente malintenzionato potrebbe potenzialmente controllare un elenco completo di e-mail e rilevare quali sono registrati nel sistema (vedere il collegamento seguente).

Per quanto riguarda il modulo per la password dimenticata, aggiungerei che è una buona idea equiparare i tempi tra le query riuscite e quelle 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- net setting", la maggior parte se non tutto quanto sopra potrebbe non essere applicabile!

Molte aziende distribuiscono siti Web "solo per uso interno" che sono, di fatto, "applicazioni aziendali" 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 tramite VPN.)

Quando un utente è regolarmente connesso alla suddetta rete, la sua identità ("autenticazione") è [già...] "definitivamente noto", così come lo è il loro permesso ("autorizzazione") fare certe cose...ad esempio ..."per accedere a questo sito web."

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

Dal tuo punto di vista, sai semplicemente questo:Quello chiunque che finisce legittimamente sul tuo sito web dovere Sii accompagnato da [un ambiente variabile magicamente contenente ...] un "token". (cioè. L'assenza di tale contrassegno deve costituire una motivazione immediata 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ò "chiedere [in modo autorevole] a qualcuno che ne sa (LDAP...ecc.)" su qualsiasi e ogni (!) domanda che potresti avere.In altre parole, lo fai non avvalerti di Qualunque "Logica coltivata in casa." Invece, chiedi all'autorità e ti fidi implicitamente del suo verdetto.

Uh Huh ...suo abbastanza un passaggio mentale da "Internet selvaggio e lanoso".

Utilizzo OpenID Connetti O Accesso gestito dall'utente.

Poiché nulla è più efficace che non farlo affatto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top