Ci stiamo concentrando troppo sulla complessità delle password?

Qui ci sono due importanti categorie di rischio:

1. Attacchi sul sistema live (ad esempio, indovinando la password di un utente)
2. Attacca gli hash delle password offline (ad esempio da un dump del database)

Il primo tipo di attacco può essere suddiviso in varie sottocategorie:

• Un attacco a forza bruta sulla password di un utente.
• Indovina le prime 1000 password più utilizzate sull'account di un utente.
• Indovina le prime 3 password più utilizzate su 1000 account utente.

I requisiti di complessità della password risolvono in gran parte le ultime due categorie e rendono molto più difficile gli attacchi di tipo forza bruta. Se combinate con una corretta limitazione della velocità, tutte e tre le categorie possono essere rese effettivamente irrealizzabili. Tradizionalmente, gli attacchi "live system" erano il driver principale per requisiti di password più complessi.

Il secondo tipo di attacco di solito si verifica dopo il tuo server è compromesso. Nonostante le migliori intenzioni e gli sforzi di tutti, i siti e i server vengono violati. Non puoi proteggerti da ogni possibile vettore di attacco, e questo è un dato nel mondo della sicurezza. Ad un certo punto ti verrà compromesso.

Ci sono tre problemi principali con il furto di un dump del database:

• I dati degli utenti privati sono trapelati, spesso costituiti da informazioni personali.
• Le password degli utenti sono trapelate, sia come testo semplice (se non stai facendo il tuo lavoro!) o come hash.
• Gli utenti riutilizzano le password su diversi servizi.

Non puoi impedire che i dati degli utenti privati vengano trapelati. Il tentativo di crittografare o offuscare in modo reversibile i dati nel database porta solo a un livello di astrazione complicata nel codice e fornisce un vantaggio di sicurezza minimo o nullo. La cosa migliore che puoi fare è eseguire test rigorosi di garanzia della qualità e test di sicurezza sui tuoi prodotti, servizi e infrastrutture, al fine di ridurre al minimo il rischio di furto di dati.

Tuttavia, puoi proteggere le password degli utenti. Mediante l'hashing delle password con una funzione crittografica unidirezionale, possiamo rendere difficile per un utente malintenzionato scoprire la password originale in testo semplice.

Le tecniche standard che utilizzano MD5 o SHA1 sono state scoperte come difettose, dal momento che i database di grandi dimensioni (chiamati tabelle arcobaleno) potrebbero essere precalcolati in anticipo, consentendo a un utente malintenzionato di cercare un valore di hash in una tabella e trovare la corrispondente -text password. Questa tecnica è stata combattuta usando i sali, che mirano a rendere ogni hash univoco per l'utente introducendo un valore casuale unico per utente, che ha reso le tabelle arcobaleno non fattibili. Successivamente, gli hacker hanno scoperto che le funzioni di hash potevano essere calcolate in modo molto parallelo dalle GPU, usando tecnologie come OpenCL e CUDA. Invece di pochi milioni di hash al secondo sulla CPU, gli hacker potevano ora calcolare miliardi di hash al secondo su una GPU, o centinaia di miliardi al secondo su un cluster GPU, il tutto utilizzando nient'altro che l'hardware di consumo e liberamente software disponibile. Ciò significa che un puro tipo di hash sha256(pass+salt) non è più sicuro. L'alternativa è un algoritmo di derivazione chiave progettato per essere lento, come PBKDF2 o bcrypt. Questi sono più difficili da calcolare su dispositivi paralleli come GPU e riducono il numero di calcoli al secondo fino a un livello che rende impossibile una forza bruta completa. Tuttavia, gli attacchi di dizionario saranno ancora ragionevolmente fattibili, specialmente se vengono usate password comuni.

Quindi, in conclusione: no , non penso che stiamo attribuendo troppo peso ai requisiti di complessità delle password. I vettori di attacco coinvolti sono complicati e la potenza di calcolo disponibile per le persone oggi è abbastanza elevata da rendere pericolose le password comuni, indipendentemente da quanto sia lenta e computazionalmente costosa la funzione di derivazione della chiave. Gli utenti riutilizzano le password, quindi dobbiamo proteggere quelle password nel miglior modo possibile.

Ricorda che uno dei motivi per cui richiediamo anche password complesse è che quando un database viene compromesso, le password non possono essere facilmente applicate. (password meno complesse consentiranno solo questo)

Mentre gli utenti non dovrebbero mai riutilizzare le loro password, è qualcosa che sfortunatamente accade ancora.

Ritardare o tentare il contatore impedirà un attacco diretto di forza bruta, ma cosa succederebbe se l'hacker rubasse l'intero database? Quindi può forzare le password per tutto il tempo che vuole. E con questo l'autenticazione a due fattori è già rotta al 50%. La tua seconda fase di autenticazione può essere interrotta con l'ingegneria sociale / un virus informatico o qualsiasi altra tecnica necessaria.

No, a mio parere, non stiamo decisamente concentrando troppo sulla complessità della password, non su questo punto. Quando tutto il resto sul server è compromesso, i tuoi hash forti (probabilmente) non lo saranno.

La preoccupazione principale con i requisiti di complessità è di rendere difficile fare un attacco offline contro una tabella hash trapelata. Non riutilizzare le password è molto più importante della complessità della password e qualsiasi password non banale andrebbe bene da un punto di vista della sicurezza su un sistema live se il DB non fosse compromesso e la corretta prevenzione della forza bruta fosse a posto.

Tuttavia, poiché le password vengono spesso riutilizzate e non è necessario sapere se una tabella hash è stata compromessa, è necessaria la complessità per proteggere altri account o una compromissione di hash non realizzata da consentire a un utente malintenzionato di determinare la password.

Personalmente, tenderei ad essere d'accordo sul fatto che alcuni punti (non la maggior parte, ma alcuni) stanno iniziando a raggiungere l'altra parte pericolosa, il che sta rendendo così complessi i requisiti di complessità che diminuisce l'usabilità e provoca una frustrazione dell'utente troppo severa per il livello di sicurezza necessario per il sito in questione. Questo è particolarmente vero per i siti che sono stati compromessi in passato e stanno cercando di fare un "bello spettacolo" di fare le cose "meglio". (Sony, sto guardando nella tua direzione.)

Un compromesso per complessità è la lunghezza della password. In altre parole, una password più lunga alfabetica, più facile da ricordare e più facile da digitare è matematicamente strong quanto una password casuale più breve che contiene tutti i tipi di caratteri.

Le password più lunghe ti impediscono anche di usare parole del dizionario, parole in elenchi di parole d'ordine comuni e hash che esistono nelle tabelle arcobaleno.