Domanda:
Come impedire la corrispondenza tra nome utente e password quando si modifica un nome utente?
PwdRsch
2016-03-08 01:36:43 UTC
view on stackexchange narkive permalink

Diciamo che ho un sistema in cui uno dei requisiti di sicurezza è impedire agli utenti di scegliere una password che corrisponda al loro nome utente. I nomi utente non fanno distinzione tra maiuscole e minuscole, ma lo sono le password. Le password vengono memorizzate dal server utilizzando una funzione di hashing sicura che non può essere annullata.

Quando l'account viene creato, sia il nome utente che la password sono inizialmente disponibili in chiaro al server per il confronto. Possiamo confrontarli in memoria (ignorando le maiuscole e minuscole) per vedere se corrispondono e istruire l'utente a scegliere una password diversa se lo fanno. Una volta soddisfatto questo controllo, la password viene sottoposta a hashing in modo sicuro per l'archiviazione mentre il nome utente viene archiviato in testo normale. Nessun problema a soddisfare il requisito qui.

Quando l'utente vuole cambiare la propria password, o viene cambiata per lui, il server può recuperare il proprio nome utente e confrontarlo con il valore della password appena scelta (ignorando di nuovo case) per vedere se corrisponde. Nessun problema a soddisfare i requisiti anche qui.

Tuttavia, il sistema consente anche modifiche al nome utente. Durante questo processo di modifica dell'ID, l'utente non ha necessariamente fornito la propria password in chiaro al server. Potrebbero averlo fatto quando si sono autenticati, ma il server non manterrà la password archiviata in testo normale nel caso in cui decidessero di cambiare il loro nome utente. Quindi la password in testo normale non è disponibile per verificare una corrispondenza con il valore del nome utente appena scelto.

Nel tentativo di soddisfare i nostri requisiti, il server può utilizzare la stessa funzione di hashing sicuro per eseguire l'hash del nuovo nome utente e confrontarlo con la password con hash registrata. Se corrispondono, il server può chiedere all'utente di scegliere un nome utente diverso. Tuttavia, poiché il nome utente non fa distinzione tra maiuscole e minuscole, questo controllo potrebbe non riuscire quando è verosimilmente vero. Se invio "PwdRsch1" come nuova scelta di nome utente e la mia password è "pwdrsch1", il sistema lo consentirà poiché gli hash non corrispondono. Io, o peggio, un utente malintenzionato, potrei successivamente autenticarmi con successo con un nome utente e una password corrispondenti di "pwdrsch1".

Potremmo forzare il nome utente in minuscolo prima di eseguire l'hashing e confrontarlo con la password, ma allora è possibile lo scenario inverso. Il nome utente verrebbe verificato come "pwdrsch1" rispetto a una password di "PwdRsch1" e consentito poiché non corrispondono. Ma in seguito posso autenticarmi con successo con un nome utente e una password corrispondenti di "PwdRsch1".

Quali opzioni ragionevoli ho per ridurre questo rischio che una password corrisponda a un nome utente che non distingue tra maiuscole e minuscole?

A seconda dell'hash, la forza bruta potrebbe essere fattibile: dato un nome utente con lettere "N" (esclusi i numeri), lo spazio di ricerca è solo "2 ^ N".
Consentire agli utenti di cambiare il proprio nome utente crea chiaramente problemi per la gestione delle password e con la maggior parte dei sistemi con cui lavoro causerebbe altre complicazioni. È davvero così importante? IME la migliore sicurezza viene dalla semplicità.
I nomi di visualizzazione e login separati sono OK.
Quando il nome utente viene modificato, forza un ripristino della password.
@DeerHunter Ci ho pensato anche io, ma non l'ho fatto ma in una risposta, perché potrebbe anche non essere desiderato (il nome è cambiato per un motivo dopo tutto). Ad esempio, una persona divorziata potrebbe non voler digitare il cognome del suo ex ogni volta che accede. Quindi, se fai qualcosa del genere, sarebbe meglio avere ID di accesso privi di significato (ma probabilmente anche non desiderati, poiché sono più difficili da ricorda).
Perché non visualizzi semplicemente del testo in rosso che dice "Se la tua password è basata sul tuo nome utente, c'è una buona probabilità che qualcuno possa indovinarla e rubare le tue informazioni"? Sospetto che questo risolverà quasi tutti i casi. La complessità della password imposta a livello di codice senza tentativi di istruire gli utenti è questa strana tradizione non produttiva. È uno dei tanti motivi per cui nessuno comprende le tecniche di base per mantenere i propri dati al sicuro e perché tutti questi requisiti e controlli esistono in primo luogo.
@DeerHunter: è vero, ma semmai lo rende più difficile. Se l'account ha una visualizzazione e un nome di accesso separati e stai implementando questo tipo di misura, assicurati che la password non corrisponda a nessuno dei due. Quindi, anche se il nome di accesso non può cambiare, il fatto che il nome visualizzato possa cambiare significa che abbiamo ancora questo problema da risolvere (o fallire / rifiutare di risolvere, a seconda dei casi).
I commenti non sono per discussioni estese; questa conversazione è stata [spostata nella chat] (http://chat.stackexchange.com/rooms/36752/discussion-on-question-by-pwdrsch-how-to-prevent-username-and-password-matches-w) .
@user19474 in questo modo potresti rendere il tuo sistema di hashing della password molto più debole in quanto un utente malintenzionato che si impossessa degli hash può attaccare prima la versione minuscola (spazio di ricerca molto più piccolo) e poi prendere i loro successi da quello e applicarli alle versioni complete degli hash .
@PeterGreen, Non capisco la tua critica. Se qualcuno cambia il proprio ID da jsmith a jjones, e sono costretti a selezionare una nuova password, in che modo sono rilevanti le lettere minuscole / maiuscole?
Se consideri che un token di accesso è una combinazione di nome utente + password. Quindi qualsiasi modifica nel nome utente o nella password è una modifica nel token di accesso. E richiede la verifica di IE tramite un token di accesso completato -> nome utente + password. Ho difficoltà a immaginare un mondo in cui nomi utente e password sono entità disgiunte, sono semplicemente un token pubblico e privato che insieme formano le tue credenziali.
Otto risposte:
tim
2016-03-08 01:45:53 UTC
view on stackexchange narkive permalink

L'unico modo sensato per ottenere ciò che desideri è chiedere la password quando un utente cambia il proprio nome utente. In questo modo il server ha sempre le informazioni necessarie per condurre un confronto accurato tra il nome utente e la password durante una modifica e prevenire le corrispondenze.

Poiché le operazioni sensibili, come la modifica delle password o nel tuo caso i nomi utente, dovrebbero richiede comunque una password (per limitare il danno di XSS), questo non dovrebbe essere un problema.

La tua unica altra alternativa è provare ogni possibile combinazione di casi, hash e confrontarla con l'hash memorizzato quando un utente cambia il proprio nome utente.

Sono d'accordo che la richiesta della password sembra essere la soluzione più sensata di fronte a modifiche del nome utente gestito dall'utente. Tuttavia, alcuni sistemi (ad es. Microsoft Active Directory) consentono agli amministratori di modificare i nomi utente senza il coinvolgimento dell'utente. In queste situazioni il requisito per un utente di fornire la propria password non è realmente compatibile. Sospetto che il tuo altro suggerimento di hashing tutte le variazioni possa essere l'unica opzione praticabile per soddisfare il requisito. In caso contrario, potremmo essere disposti a consentire il rischio che un nome utente modificato dall'amministratore corrisponda a una password.
@PwdRsch perché un amministratore dovrebbe voler cambiare i nomi utente senza il coinvolgimento dell'utente? Non riesco a immaginare un caso d'uso legittimo.
Non sono sicuro che sia una buona idea @emory. Avremmo bisogno di qualcuno che capisca davvero la crittografia dietro gli hash delle password che esamini questa idea e determini che l'archiviazione di più hash di password simili non aiuta un utente malintenzionato se riesce a rubare entrambi gli hash. La mia opinione generale è che l'archiviazione delle password è complessa e di solito è meglio attenersi a ciò che è provato e vero.
Non intendo dire che l'utente non sarebbe a conoscenza della modifica del nome utente, ma solo che non eseguirà la modifica da soli. Ciò accade in situazioni in cui qualcuno si sposa e cambia il proprio cognome, quindi il nome utente viene modificato in modo che corrisponda al personale dell'azienda.
@PwdRsch - Forse puoi fare il controllo uname / password su ogni accesso? O al primo accesso dopo un cambio di nome utente? Detto questo, che ne dici se non riesci a soddisfare i requisiti in quei casi limite? Sembra che non valga la pena preoccuparsi.
@NeilSmithline Sospetto che ignorare questi casi sia ciò che la maggior parte degli sviluppatori di sistemi ha scelto di fare, ma ero interessato ad ascoltare altre idee.
@emory solleva un buon punto. Se l'amministratore cambia il nome utente, cosa fai se la tua politica viene violata? Basta non cambiare il nome? Utilizzare un nome diverso - errato -? Non ha senso. (quando l'utente la modifica da solo, potresti richiedere una modifica della password, ma lasciare che l'amministratore cambi la password non sembra desiderabile; se lo fosse, potresti semplicemente rendere obbligatoria una modifica della password e non avere problemi)
@emory Sì, è possibile aggiungere requisiti / restrizioni per i caratteri per garantire che un nome utente non possa mai essere un valore di password valido o viceversa. Sentiti libero di espandere questo argomento come un'altra risposta a questa domanda.
@tim Penso che probabilmente vorrai forzare una modifica della password da parte dell'amministratore in quella situazione. Oppure forza il blocco dell'account se ciò non consente all'utente di accedere con il nome utente / password ora corrispondenti fino a quando non completa un processo di convalida e modifica la password. Sicuramente non è l'ideale dal punto di vista dell'utente, ma raramente lo sono le modifiche forzate della password.
@NeilSmithline Prenderei in considerazione la possibilità di scrivere le tue opzioni di controllo delle corrispondenze durante il login o solo gli accessi a seguito di una modifica del nome utente come risposta poiché sembra ragionevole e non voglio che sia solo seppellito nei commenti.
Se l'amministratore cambia il nome utente, è possibile impostare un flag che indica che la password deve essere modificata. Un collegamento viene inviato all'utente, notificando la modifica. La prossima volta che l'utente accede, la password deve essere modificata. Nel mio caso, cerco sempre di forzare l'uso di parafrasi che sono molto più lunghe dei nomi utente. Ancora meglio, elimina la password e usa invece le chiavi.
@lepe in tal caso, se il database è trapelato, si potrebbe semplicemente cercare l'esistenza di un tale flag e probabilmente la password è in chiaro nel campo del nome utente
@emory un amministratore potrebbe voler cambiare un nome utente per qualcuno se il suo nome cambia. L'esempio più semplice è dove il nome utente è composto, ad esempio, dal cognome e dalla prima iniziale. Questo potrebbe cambiare quando una persona si sposa e quindi deve essere modificata in un sistema. Un utente normale potrebbe quindi non essere in grado di modificare la propria password. Allo stesso modo, gli amministratori potrebbero avere un mucchio di richieste da gestire, quindi potrebbe non essere pratico averli lì per inserire la password al momento della modifica del nome utente.
Pienamente d'accordo con @tim e emory: non esiste un caso legittimo e - in realtà - sano di mente per "non-utente-se stesso" cambia nome utente e password dell'account. Se si verifica una modifica della password * legittima *, è possibile richiedere il vecchio e il nuovo passaggio. Se si desidera modificare anche un nome utente, OK, richiederne uno nuovo, lo stesso modulo di richiesta del pass, solo una riga in più.
@gabe3886: Più precisamente, non c'è motivo per cui l'amministratore debba conoscere la password dell'utente. Basta fare in modo che il sistema controlli ad ogni tentativo di accesso se il nome utente e la password corrispondono e, se lo fanno, impostano la scadenza della password molto presto (avvisare l'utente che sarà necessario scegliere una nuova password è probabilmente meglio che mettere sul posto).
@Dezza sì, ma di solito tale flag impedisce agli utenti di accedere, indipendentemente dalla password
@Dezza Capisco il tuo punto. Perché pensi che sia di "alta" possibilità? Penso che ci sia una probabilità "bassa" che il nuovo nome utente corrisponda alla password precedente. Che ne dici di questo: quando il nome utente viene modificato, la password viene impostata su una password casuale (temporanea) che verrà modificata dall'utente al clic sul collegamento. Oltre alle molte alternative per verificare il collegamento dell'utente, è possibile includere il - vecchio hash della password - hash come parametro nel collegamento. In questo modo, puoi chiedere la vecchia password per impostare quella nuova senza lasciare il vecchio hash nel database. Come ha detto kw4nta, l'utente non può accedere quando la bandiera è attiva.
Jason
2016-03-08 20:06:21 UTC
view on stackexchange narkive permalink

Andando un po 'controcorrente: non interessa se il nome utente viene modificato in una stringa "sostanzialmente simile" come password. Avvisa gli utenti del pericolo di selezionare la stessa password e verifica la corrispondenza identica .

Indipendentemente dal numero di regole che metti in atto, se l'utente è determinato troverà un modo per aggirarli. Se è necessario, richiedere la password al cambio del nome utente in modo da poterli forzare a utilizzare lo stesso case, oppure lasciarlo passare e controllare la prossima volta che accedono e quindi forzare un cambio utente / pass.

L ' unica volta che tutto ciò è importante è se i tuoi utenti sono soggetti a un attacco mirato. Se uno script kiddie casuale (o qualche altro opportunista) ottiene l'elenco degli utenti, hanno strumenti molto più sofisticati per infrangere quelle password rispetto al tentativo di abbinare il nome utente. Lo stesso fa l'attaccante mirato, del resto, ma può iniziare con cose semplici che possono digitare nella tastiera da soli. E se è una persona intelligente che cerca di infrangere la password "PwdRsch1", sarai davvero al sicuro controllando le differenze tra maiuscole e minuscole? Che ne dici di "pwdr5ch1"? "PwdRsch2"? "1hcsRdwP"? Puoi scrivere regole per ognuno di questi scenari a cui puoi pensare, ma o ce ne sarà uno che hai dimenticato o renderai così difficile selezionare una combinazione nome utente / password che finiranno semplicemente usando "P4ssw0rd!" e finiscila.

L'istruzione è l'unico modo per convincere i tuoi utenti a utilizzare password veramente sicure e ci saranno sempre quelle che non sono conformi.

Sono d'accordo sul fatto che un determinato utente possa scegliere una password più debole di quella che potrebbe desiderare, nonostante le regole dei criteri o altri controlli che utilizziamo per prevenire scelte sbagliate. Tuttavia, non credo che questo requisito (come affermato) stia spingendo troppo oltre. Associa il controllo tecnico all'istruzione come suggerisci e speriamo di ottenere i vantaggi in termini di sicurezza di entrambi. Tuttavia, solo perché la maggior parte degli aggressori farà supposizioni oltre a una password corrispondente al nome utente, non significa che non dovremmo tentare di applicare questa regola. Dobbiamo ancora eliminare i frutti pendenti bassi.
@PwdRsch Non sono in disaccordo, il mio punto, suppongo, è che non è necessario * nascondere * quello che stai facendo all'utente - richiedendo esplicitamente loro di inserire la propria password quando si effettua un cambio di nome o lo si esegue controlla la prossima volta che accedono dopo che un amministratore ha cambiato il loro nome, migliora effettivamente l'istruzione perché dà loro un motivo per prestare attenzione. Detto questo, se un amministratore è in grado, essenzialmente, * accidentalmente * di indovinare la password di un utente quando seleziona il suo nome utente, allora questo è un motivo per scaricare l'istruzione sull'utente * comunque * perché era una password scelta orribilmente.
PyRulez
2016-03-08 10:09:02 UTC
view on stackexchange narkive permalink

Supponiamo che il nome utente contenga 10 lettere. Sono 1024 diverse combinazioni di lettere maiuscole e minuscole. Controllali tutti.

Non memorizzare l'hash della password in minuscolo. Quel 1024 può sembrare scomodo per te, ma è la differenza tra un giorno e tre anni per un utente malintenzionato.

A seconda dell'hashing e dell'hardware, potrebbe essere necessario circa un minuto. Se un amministratore cambia il nome utente che potrebbe andare bene (se è chiaramente mostrato che si tratta di un processo lento), se un utente lo modifica, un minuto potrebbe non essere accettabile. Può causare problemi, ad esempio, gli utenti inviano nuovamente i moduli e quindi non sanno con quale nome utente sono finiti, o gli utenti chiudono la finestra prima di ricevere il messaggio che il loro nuovo nome utente non è accettabile.
@tim Deve essere lento. Altrimenti, un malintenzionato che prende il controllo del server o ha una replica del server potrebbe semplicemente continuare a provare a cambiare il nome utente fino a quando non scopre la password (in pratica potrebbe fare qualcosa di molto meglio del server). Puoi scambiare la velocità con lo spazio: https://en.wikipedia.org/wiki/Scrypt
Se * tu * (presumibilmente un cracker di password non esperto) puoi forzarlo, un utente malintenzionato può fare lo stesso molto, molto più velocemente. Se * sei * un esperto di password cracker, allora conosci già la futilità di ciò che stai facendo.
@Jason non è necessario conoscere la password, assicurati solo che il nome utente non sia la password.
emory
2016-03-08 02:50:56 UTC
view on stackexchange narkive permalink

Dovresti forzare userid e password a provenire da set diversi. Nei commenti sembra che l'ID utente debba seguire dal nome legale dell'utente in modo stereotipato "John Smith" -> "jsmith" e "Jane Doe" -> "jdoe". Quindi se Jane sposa John e prende il suo nome, il suo ID utente deve cambiare in qualcosa come "jsmith2"

Quindi potresti stabilire che il primo carattere in una password deve essere un simbolo o che la password deve contenere un simbolo.

Se gli userid sono troncati a 8 caratteri potresti richiedere che le password contengano almeno 9 caratteri.

Potresti prendere il prodotto cartesiano di una lista di cognomi e una lista di nomi dati e utilizzarli come lista nera per le password. Se un dipendente ha un nome che non era nella tua lista, aggiungilo e man mano che le persone cambiano le password, il problema si risolverà da solo.

Brenda Utthead avrebbe un'obiezione a colori alla tua politica proposta, soprattutto se i nomi utente vengono utilizzati nella comunicazione pubblica.
@DamianYerrick Per essere chiari, ho capito che l'OP ha un requisito rigoroso che gli ID utente siano derivati ​​in modo formulato da nomi legali e non corrispondano alle password. Penso che gli utenti dovrebbero essere in grado di scegliere il proprio userid che non deve necessariamente assomigliare al loro nome legale. L'obiezione di Brenda ha più a che fare con i requisiti di OP che con la mia politica.
@DamianYerrick nei commenti, l'OP ha detto che se Brenda Smith (userid bsmith, password butthead) avesse sposato Rick Utthead (userid rutthead) e avesse preso il nome di Utthead, allora l'amministratore avrebbe dovuto cambiare lo userid di Brenda in butthead, ma questo sarebbe un problema perché ora lei userid e password sono gli stessi.
@DamianYerrick ma se credi che l'ID utente che corrisponde alla password non sia il grosso problema nello scenario di Brenda, allora devo essere d'accordo.
@DamianYerrick Cisco Systems lo ha fatto davvero e sembrava straordinariamente sfortunato con i nomi dei loro dipendenti, sulla falsariga di Chris Rapherty, Simon Hitchin e così via. Credo che abbiano anche troncato i loro nomi utente a 8 lettere. Ne seguì molto divertimento (al di fuori di Cisco).
Dewi Morgan
2016-03-08 23:14:19 UTC
view on stackexchange narkive permalink

Questa non è una risposta, la sto solo menzionando in modo che le persone non lo facciano .

Potresti decidere che avrebbe senso memorizzare, in Oltre al normale hash della loro password che distingue tra maiuscole e minuscole, un hash della loro password convertita in lettere minuscole.

Questo risolverebbe sicuramente il tuo problema: basta scrivere in minuscolo il nome utente che stai cambiando e confrontalo con questo hash memorizzato della password in minuscolo.

L'ovvio svantaggio è che questo in parte vanifica lo scopo di una password con hash in primo luogo: rendere gli attacchi all'elenco delle password molto più difficili. Un utente malintenzionato che ottiene l'accesso agli elenchi di password con hash sarebbe in grado di attaccare l'hash minuscolo molto più debole (2 ^ n volte più debole) invece dell'hash case sensitive.

Quindi le altre opzioni menzionate (chiedendo la password al momento della modifica; provare tutte le permutazioni tra maiuscole e minuscole se un amministratore la modifica, idealmente nell'ordine più probabile per primo) sembrano una scommessa molto migliore.

Questa è stata una delle prime risposte offerte come un'opzione apparentemente buona che il poster ha poi cancellato una volta che le persone hanno risposto con gli avvisi che hai elencato. ;) Sono d'accordo che i compromessi in materia di sicurezza non ne valgono la pena.
@PwdRsch Oh, grazie, non me ne rendevo conto. Questa risposta, per una volta, starei benissimo nel vedere ottenere voti negativi non commentati :)
@DewiMorgan Potresti farlo in CW ... in questo modo non perderai reputazione per i voti negativi.
Ooh, grazie, @wizzwizz4, Non lo sapevo. Fatto! Sembra un po '... cattivo e sfruttatore, però :(
YLearn
2016-03-09 04:35:40 UTC
view on stackexchange narkive permalink

Già alcune ottime risposte, ma ecco un modo alternativo per affrontare questo problema. Invece di provare a confrontare il nuovo nome utente con la password esistente, potresti semplicemente forzare una modifica della password ogni volta che un utente cambia il proprio nome utente.

Naturalmente, dovresti avvertire gli utenti che la modifica del nome utente richiederà la modifica del password, ma puoi utilizzare facilmente qualsiasi processo già esistente per controllare le nuove password rispetto ai nomi utente.

Omar Kooheji
2016-03-10 00:22:36 UTC
view on stackexchange narkive permalink

Anche se la soluzione più sensata è stata già menzionata e accettata, vale a dire chiedere la password al cambio del nome utente perché dovresti farlo comunque. Un'alternativa è memorizzare anche l'hash della password minuscola (con un salt diverso?) E confrontare il nome utente tutto minuscolo con quello.

NH.
2017-10-24 00:56:17 UTC
view on stackexchange narkive permalink

L'unico modo per impedire agli utenti di scegliere password stupide è forzare i criteri di generazione della password (in contrasto con i criteri di formato password tristemente comuni).

Ora, se non hai molta autorità sui tuoi utenti (la maggior parte dei siti web no), dovresti almeno dire loro di generare le loro password con un gestore di password (e generare la loro password principale con dice) e potresti essere in grado di rendere difficile disobbedire a questa politica:

Un modo per farlo è fare in modo che il campo della password non accetti input da tastiera, ma invece solo dati o macchina incollati dati tipizzati (consiglio di controllare la velocità con cui vengono inseriti i caratteri). Quindi puoi fare in modo che il riquadro che spiega la politica delle password sia delineato in rosso o qualcosa che attiri la loro attenzione su di esso.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...