perché non tutti i siti generano password per gli utenti? [duplicare]

Security at the expense of usability comes at the expense of security

Il problema è che c'è solo così tanto che un'applicazione web può fare per forzare buone pratiche di sicurezza sugli utenti. In questo caso particolare, posso dirvi cosa accadrà nella stragrande maggioranza dei casi: la gente scriverà la propria password "sicura" in un posto bello e insicuro. Di conseguenza, ciò non renderà necessariamente nulla più sicuro: rimarrà semplicemente in giro dove vive la vulnerabilità. In sostanza, questo sistema manca dell'architettura di supporto necessaria per rendere l'esperienza dell'utente molto semplice e quindi molto sicura. Di conseguenza ci sono fondamentalmente tre tipi di persone con tre risultati diversi:

1. Le persone a cui non interessa / capiscono la sicurezza della password. Stanno andando a scrivere quella password irrefrenabile in un luogo che è super-accessibile e, di conseguenza, super-insicuro. Queste sono le stesse persone che riutilizzano le stesse password deboli su ogni sito. Di conseguenza, passano da una soluzione di sicurezza non valida a un'altra soluzione di sicurezza non valida. Questi sono anche la maggior parte degli utenti del Web, quindi per la maggior parte di Internet la tua soluzione non ha alcun beneficio reale.
2. Le persone che utilizzano gestori di password e altri helper password, i loro sistemi di password non possono integrarsi con il tuo sito web. Queste persone andranno peggio, poiché improvvisamente il loro sistema normalmente sicuro non può più essere usato. Di conseguenza, probabilmente finiranno per scriverlo, forse non in modo sicuro, e stare peggio di prima. Per essere chiari, questo avverrà sicuramente: il tuo "mostra la password in un modulo in modo che il gestore della password possa registrarlo" la soluzione non funzionerà assolutamente con alcuni gestori di password. Posso quasi garantirlo.
3. Le persone che utilizzano i gestori di password e quei gestori di password si integrano correttamente con il tuo sistema. Stavano già memorizzando le cose in sicurezza e lo sono ancora, ma ora con un altro punto di errore: il tuo generatore di numeri casuali. Nel complesso, tuttavia, la sicurezza non diminuirà né aumenterà sostanzialmente.

Nel complesso, quindi, direi che non vedo alcun beneficio reale per questo sistema.

Devo dire questo a voce alta perché è fondamentale in tutti gli altri contesti: non si vuole mai usare SHA256 alle password hash. In questo caso, probabilmente puoi scappare con un hash veloce perché la tua password è troppo lunga perché una forza bruta sia comunque fattibile.

Modifica per aggiungere la risposta ovvia

Penso che il problema più grande con questa soluzione è che non è abbastanza lontano per risolvere il problema sottostante. Il problema di fondo è che le persone succhiano le password: o selezioniamo quelle povere, le riutilizziamo o non le immagazziniamo in modo sicuro. La soluzione non è quella di creare un nuovo sistema di password: la soluzione è quella di eliminare le password tutte insieme. Molte aziende stanno iniziando a introdurre il login senza password. Questa è la risposta che vuoi davvero.

La tua soluzione sta costringendo le persone a utilizzare un gestore di password. Le persone possono salvare le loro password in un browser, ma questo non è sempre crittografato e spesso viene memorizzato solo localmente, quindi ora non possono accedere al servizio da più di un computer. Tieni presente che la maggior parte le persone non sapranno nemmeno cos'è un gestore di password.

Inoltre, anche se hanno un gestore di password, hanno accesso ad esso su tutti i loro dispositivi? Se qualcuno deve digitare una password casuale di 32 caratteri anche solo una volta, inizierà a odiare il tuo sito per quello.

Due cose che mi vengono in mente:

1. Gli utenti odiano non essere in grado di scegliere la propria password perché, a meno che non abbiano già un gestore di password o un qualche tipo di sistema, è una cosa extra da ricordare o scrivere o tenere traccia di qualche parte.

2. Se il sito web si assume la responsabilità di generare password "casuali", i metodi che genera una password potrebbero rivelarsi dei difetti in futuro, il che metterebbe a repentaglio la sicurezza di tutte le password esistenti contemporaneamente. Penso che di recente ci sia stato qualche chip hardware che ha generato password BitLocker in computer il cui difetto è stato scoperto e ora tutte le password BitLocker possono essere incrinate con circa $ 40.000 in AWS - un sacco di soldi per un individuo, ma per un'azienda o un governo, non molto.

what are the drawbacks of that approach?

Per cominciare, è un passo in più che gli altri metodi di autenticazione hanno ridotto significativamente. È uno sforzo extra per i tuoi utenti. Le password sono ... facili da dimenticare e questo può diventare un problema che sconfigge il loro vero scopo. Soprattutto, regole per le password sicure che non sono in contatto con la realtà sono un'insicurezza.

Puoi osservare questo attraverso le persone che provano la loro password più comune su qualche forum, solo per scoprire che hanno sbagliato a causa di qualche oscura, anormale regola di cui si sono dimenticati, e così continuano a pappagare sempre username e la combinazione di password che hanno mai utilizzato nei campi di accesso. Qual è il punto delle password se hai intenzione di condividerle con estranei casuali del genere?

Ogni volta che noto siti che eseguono questa operazione, sospetto che possano cercare in modo subdolo di cercare password per altri siti. Per quanto mi riguarda, a meno che tu non sia un'agenzia bancaria al giorno d'oggi, dovresti probabilmente evitare di memorizzare le password se vuoi essere visto come legittimo. Esistono metodi migliori che sono più affidabili e più sicuri.

Per elaborare: a meno che i tuoi utenti non abbiano qualcosa da proteggere, permetti loro di usare qualunque cosa vogliano come password. Cioè, se decidi di usare una password, anche le password vuote dovrebbero essere accettabili.

Is there a good reason all sites don't use that approach?

Eseguo ciò che alcuni considerano comunemente "siti" a cui concedo l'accesso ad altri a volte, e non memorizzo password o impone requisiti della password ; Uso i certificati per l'autenticazione (come qualsiasi tecnologia moderna dovrebbe) e le persone possono (se lo desiderano) proteggere questi certificati con una alla loro estremità.

I miei siti sono server, e c'è un ottimo motivo non voglio memorizzare password di altre persone. Se uno dei miei utenti riesce a ottenere l'accesso amministrativo ai miei server, potrebbe ottenere altri hash delle password.

Allo stesso modo, puoi osservare questo sito, che probabilmente non dovevi inserire una password perché eri già connesso alla rete StackExchange ... e la rete StackExchange ti permette di accedere usando Facebook o Google, quindi c'è anche quello.

L'autenticazione del certificato non è una novità; è usato da anni in PAM, non richiede l'autenticazione tramite password ed è sicuramente ancora più potente da utilizzare per le istituzioni bancarie oltre alla semplice password.

generate a long (32+ char), random (with good randomness) password

Puoi farlo, ma quando dimentica o disorganizza le tue password, finirai per fornire password per alcuni servizi ad altri servizi. Se sei soddisfatto, così sia. Il mondo non smetterà di girare se il tuo conto in banca viene aperto a crepapelle.

Ci scusiamo, ma non troverete nessuno che sostenga che la generazione di una password lunga e casuale sia più sicura di quella di generare un certificato privato lungo e casuale che viene utilizzato per firmare alcune sale nonce e mai memorizzato direttamente sul lato server.

show it to the user once

Tu non dovresti mostrare all'utente (a meno che la password non sia per qualcosa di non importante , come i tuoi forum su Internet), ma il tuo generatore di chiavi SSH dovrebbe chiedere all'utente di ripetere la passphrase al momento della generazione della chiave. Questo ha lo stesso effetto della verifica visiva (forse anche più strong), tranne per il fatto che non stai mostrando la tua "password" in testo normale per chiunque guardi oltre la tua spalla per vedere ...

hash it with SHA256

Si potrebbe anche arrivare a suggerire che un sale sia usato. Il problema è che stai ancora memorizzando un digest e gli utenti potrebbero ancora pappaggere password per altri servizi. La soluzione al problema "hai dimenticato la password" non è quella di provare ogni password che hai mai usato , indebolendo così in modo significativo la tua sicurezza, ma a eliminare le password (dal tuo server ).

resetting the password generates another long, random password

Anche i più forti schemi di autenticazione basati su password hanno difetti duraturi a causa di qualche altra tecnologia , come e-mail o telefoni cellulari; quando uno di questi diventa il link più debole, troverai l'opzione password completamente compressa.

La soluzione per la privacy e la sicurezza è utilizzare le chiavi crittografiche per autenticare, piuttosto che e-mail, numeri di telefono, password e codici PIN.

In fact perhaps the approach could even be enhanced if instead of showing the password to the user, the site simply displayed a form with the password field filled in so the browser and/or passwords managers could memorize it. The user would just submit the form and would never have to see it.

La soluzione è di memorizzare la password da qualche parte in memoria, in modo che le persone debbano solo accedere a quella posizione di memoria per trovarla? A me sembra quasi una soluzione. Usa qualcosa di fisico, come una chiave GPG protetta da passphrase su una pen drive USB.

Non è un avvocato, tuttavia una ragione significativa che posso pensare per le aziende che non vogliono assumersi la responsabilità delle password lontano dall'utente è che apre la società alla responsabilità nel caso si verificasse una violazione dei dati perché qualcuno ha ottenuto una password e lo ha fatto qualcosa. È vero, ciò che accade una volta generata la password è responsabilità dell'utente, ma sarebbe costoso stabilire in tribunale se qualcuno (o peggio, una classe di qualcuno, in un caso come Yahoo o Adobe) decidesse di tenere l'azienda l'unico responsabile.

A livello più pratico, le persone hanno opzioni, e solo fanatici della sicurezza duri stanno per andare con qualcosa che scarta pratica comune e convenienza in nome di un grado di maggiore sicurezza che non sono nemmeno sicuri su come quantificare. Anche se decidono di andare avanti con la prova del servizio, con la terza o quarta reimpostazione della password perché l'hanno dimenticato, digitano un carattere errato (che non potevano vedere, a causa delle restrizioni del campo password), non potevano incollarlo, ecc. ., penseranno seriamente al tuo concorrente che non li metta attraverso questi cerchi solo per verificare come sta facendo oggi la sua squadra di football fantasy.

Non sei l'unico a suggerire questo, come ho visto molti documenti studiano schemi simili. Tuttavia, di solito le password generate dal sistema sono significativamente peggiori nell'usabilità rispetto alle password generate dagli utenti.

In Una password generata dal sistema e un approccio mnemonico , il ricercatore Sanjaykumar Ranganayakulu ha concluso :

In general, this research found that people tend to remember passwords and mnemonics they generated better than assigned ones. Even though the system-generated mnemonics were meaningful sentences, the participants could not relate as well to them as to passwords or mnemonics created themselves.

Un precedente studio navale degli Stati Uniti del 1990 di Moshe Zviran e William J. Haga ha confrontato diversi schemi di password. Ricordare le password dopo diversi mesi ha mostrato che le password pronunciabili generate dal sistema hanno ottenuto i migliori risultati, password e passphrase generate dall'utente e le password generate dal sistema alfanumerico erano le peggiori nel richiamo, con ogni utente che scriveva la password piuttosto che memorizzarla. Nonostante le sorprendenti prestazioni delle password pronunciabili, gli utenti preferiscono ancora scegliere le proprie password:

no one was able to recall their random-character, system-generated password from memory...

When asked to rank the various methods as to how easy they were to remember, the respondents clearly chose user-generated passwords as the one that they thought was easiest...

When user ability to recall the different types of passwords is examined, [system-generated] pronounceable passwords... proved to be much better than passphrases, random system-generated passwords, or even user-selected passwords

Alla fine della giornata, l'usabilità della password generata dal sistema varia notevolmente sullo schema. Il tuo sistema, con 32 caratteri alfanumerici casuali, non sembra affatto progettato per essere di facile utilizzo. Tuttavia, alcuni schemi di generazione del sistema hanno una sicurezza decente e un'usabilità ragionevolmente alta, come lo schema "scegli quattro parole casuali" di xkcd. Altri schemi generati dal sistema user-friendly includono la generazione di password pronunciabili e alfanumerici generati casualmente con un utile mnemonico generato dal sistema. Questi tipi di schemi, dove studiati, reggono molto meglio di sistemi come quello che stai suggerendo.

Esistono altri problemi tecnici che vanno al di là dei soli problemi di usabilità ricercati, ma altre risposte hanno già coperto tali preoccupazioni.

Quindi schemi come il tuo sono stati valutati più volte nella ricerca e non sono ben accolti dagli utenti. In generale, le password generate dal sistema non vengono ricevute bene dagli utenti e, a meno che non siano implementate con cura, sono difficili da ricordare. Le alternative sono in genere molto più appropriate, come misuratori di forza della password, notifiche di comportamenti sospetti, autenticazione a due fattori, requisiti di lunghezza della password, non consentire password comuni e protezione dagli attacchi di forza bruta e perdite di hash delle password.