Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2 Mi Piace
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 Mi Piace
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1 Mi Piace
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2 Mi Piace
Questo non ha senso per me (da qui il bump del thread): una volta che si sa che una password è stata violata (o trovata in testo chiaro), diventa significativamente meno sicura. Questo rappresenta una enorme diminuzione dell’entropia, anche con ipotesi molto indulgenti:
- una password casuale di 10 caratteri, anche con un set di caratteri molto limitato (esempio fittizio di sole lettere minuscole: Pr = 1/26^10 = 1/1,4e14)
- una password che si sa essere presente nell’elenco HIBP (Pr = 1/5e8)
nel momento esatto in cui qualcun altro l’ha usata ed è stata anche violata e/o decodificata – differenza cruciale.
Qual è il problema pratico nel bloccare una password che è apparsa in un solo elenco? Come utente, è sicuramente qualcosa che vorrei sapere per evitare di riutilizzare quella password. Come amministratore di un sito, non voglio che i miei utenti utilizzino password compromesse. Sembra che ne valga la pena in termini di compromesso con l’usabilità.
No, non è una differenza cruciale perché statisticamente tutte le password verranno violate col passare del tempo.
Ricorda che già blocchiamo da anni le prime milione password più comuni, quindi sei già protetto nei modi che contano.
3 Mi Piace
Statisticamente, tutti gli algoritmi di crittografia e hashing verranno violati col tempo. Quando appare il primo segnale che un algoritmo è vicino alla violazione smettiamo di usarlo.
Perché le password dovrebbero essere diverse? Tutta la sicurezza è una scommessa sul fatto che l’entropia utilizzata sia sufficiente per il compito dato, e c’è sempre un’ipotesi riguardo alla lunghezza o all’intensità dell’attacco che può essere sopportata.
Considerando che si perde almeno 6 ordini di grandezza di entropia la prima volta che una password appare in una lista (in realtà probabilmente diversi ordini in più), questa sembra una decisione facile.
Sì, questa è una situazione molto migliore rispetto a quella di molti altri pacchetti software disponibili oggi. HIBP rappresenta comunque un buon miglioramento per i siti che vogliono ulteriori garanzie oltre a questo.
Sembra un’ottima opportunità per un pulsante “Genera passphrase” tramite plugin, se tecnicamente fattibile…
Escluderebbe qualsiasi elemento presente nell’elenco dei dati compromessi e l’utente potrebbe scegliere di crearne una propria, che include già l’elenco di esclusione “base” da 1 milione di voci. Il metodo del pulsante permette di evitare di dover spiegare all’utente gli elenchi di dati compromessi e l’entropia, argomenti per cui generalmente non hanno tempo.
Tuttavia, secondo me, Discourse lo gestisce già abbastanza bene.
Perché generare la password sul server?
Assumendo che l’utente debba salvarla, non avrebbe più senso lasciare all’utente la responsabilità della generazione della password? Il suo gestore di credenziali preferito lo fa probabilmente già.
2 Mi Piace
Perché potrebbe essere meglio continuare a dire loro che “apple”, “apple1”, “apple 123”, “apple 12345” non sono accettabili secondo la lista dei 1 milione di password vietate. Personalmente non mi aspetterei questa funzionalità su Discourse, ma se riesce a gestire in modo abbastanza elegante il problema delle password compromesse (pwned) e lascia all’utente la responsabilità di cosa fare in caso di errori, allora potrebbe valere la pena prenderla in considerazione.
E stai suggerendo che i gestori di password lato client genereranno password come questa?
Consigliare ai tuoi utenti di utilizzare un gestore di password sarà molto più efficace che imporre una password da un singolo sito. Quest’ultima porterà semplicemente a utilizzarla ovunque e ad accelerarne il compromesso.
Riparare la stupidità è più difficile che riparare ciò che è stato compromesso; offrire una soluzione simile a https://www.useapassphrase.com/ è, a mio avviso, un modo per dare qualcosa anche a chi non è interessato agli aspetti accademici della questione.
Ho creato sistemi utilizzati da decine di milioni di persone e abbiamo sperimentato diversi approcci legati alle password, inclusi quei terribili requisiti che imponevano di contenere x e y.
A meno che non si istruiscano gli utenti sulla gestione delle password, si aumenta solo la probabilità di affaticamento legato alle password, riutilizzo e il temuto “post-it sotto la tastiera”.
Generare password lato server crea inoltre un nuovo vettore di attacco e una superficie di rischio che devono essere protetti. Personalmente, potrei fare a meno di TUTTO quanto sopra.
3 Mi Piace
Avrei pensato che JS generasse una passphrase in modo casuale lato client, poi la hashesse e la confrontasse con un elenco. La parte educativa può essere un segnaposto sopra “Crea una password”. Onestamente, non credo che Discourse debba preoccuparsi di tutto questo, ma finché le persone attribuiscono erroneamente la rabbia per il proprio comportamento al brand, potrebbe valere la pena prenderlo in considerazione.
Penso che la tua migliore opzione, quindi, sia sviluppare o commissionare un plugin che faccia ciò che suggerisci.
1 Mi Piace
È esattamente per questo che serve questo plugin.
Ci ho riflettuto un po’ da quando ho scritto questo plugin e sono arrivato a concordare con Jeff.
“Violato” significa che c’è stato qualcuno, da qualche parte, che ha pensato a quella frase e l’ha inserita in “una lista”. Immagina se qualcuno creasse uno strumento che:
- Rende pubblica una lista di stringhe.
- Genera sistematicamente e aggiunge stringhe uniche alla lista.
L’argomento di Jeff è che questo significa che, alla fine, tutte le stringhe saranno “insicure” perché appariranno in qualche lista pubblica da qualche parte; e prima o poi, anche la tua “super sicura” passphrase apparirà in questa lista in continua espansione.
L’intera idea delle password si basa solo su una “improbabilità statistica” che qualcuno non riesca a indovinare la password del tuo account. Tecnicamente, un attaccante non ha bisogno di conoscere la password; deve solo fare un davvero buon tentativo. Può favorire le proprie possibilità definendo cosa significa fare un “buon tentativo”:
- Se hanno una violazione, provano la stessa password per lo stesso account.
- Se hanno una lista di violazioni, provano le password che molti utenti usano.
Abbiamo già discusso di come Discourse sia bravo nel punto #2 sopra. Penso che tu stia cercando di colpire il punto #1, ma sarebbe piuttosto inutile e un incubo per l’usabilità avere qualcosa del genere nel core (assumendo che nessuna password, non legata al nome utente, debba essere utilizzata)… Ma se vuoi ciò che descrivi per il tuo sito, questo è il plugin che fa per te.
4 Mi Piace
Sì. Francamente, questo è un argomento terribile perché è completamente scollegato da qualsiasi nozione di probabilità, che è l’unico modo corretto per ragionare su questo.
Fortunatamente stiamo parlando di un caso limite che si presenta dopo aver eliminato le password più comunemente usate, il che è già di per sé una strategia piuttosto valida.
1 Mi Piace