Autentica hash salata utente senza nome utente

-1

Ho una pagina con un sistema di login in cui digiti nome utente e password, l'hash salato viene estratto dal database a seconda del nome utente ...

SELECT hash FROM db WHERE username = ?
bind theSubmittedUsername

La potenziale password viene quindi eseguita attraverso un metodo per verificare se è quella giusta o meno.

È plausibilmente possibile sbarazzarsi della casella di immissione del nome utente in modo che sia richiesta solo una password per autenticare l'utente.

SELECT hash FROM db WHERE .... 

Pensavo che forse 2 lettere da ciascuna password potevano essere memorizzate nel database in testo semplice, quindi avrei potuto fare qualcosa sulla falsariga di ...

SELECT hash, username FROM db WHERE 2letters = ?
bind the2LettersOfPass

quindi esegui qualsiasi hash restituito dal database tramite la funzione di confronto, esiste un modo migliore che sia più sicuro?

    
posta Crizly 10.09.2014 - 23:26
fonte

3 risposte

9

Questa è davvero un'idea pessima . Prendi in considerazione due persone che utilizzano una password simile in cui le due lettere corrispondono. Come sarai in grado di distinguere tra loro entrambi? Non.

Usiamo username e password per identificare qualcuno. Se hai solo bisogno di proteggere l'applicazione, potresti anche condividere una password, dal momento che non ti interessa la responsabilità.

    
risposta data 10.09.2014 - 23:34
fonte
8

No, questo non è possibile.

  • Un salino ti protegge dalle collisioni nella password con hash, non dalle collisioni nella password in testo semplice. Se due utenti hanno la stessa password, allora avrai due combinazioni password / salt / hash che passeranno la tua convalida e non sarai in grado di distinguere tra gli utenti.

  • I problemi che si presentano con il modo di guardare gli utenti sono perché non hai una chiave primaria. Non è possibile utilizzare una password come chiave primaria a meno che non si rifiutino attivamente le password duplicate (e nel qual caso hai appena comunicato a un utente malintenzionato la password di qualcuno).

  • Un nome utente può essere una fonte di entropia. "Trova qualsiasi utente con una password di test" è più probabile che restituisca un risultato di "find me user abc with password test". Un utente malintenzionato opportunista potrebbe probabilmente trovare un account provando password comuni.

Utilizza un cookie di accesso persistente per raggiungere invece il tuo obiettivo.

    
risposta data 11.09.2014 - 00:07
fonte
1

Il modo tradizionale per evitare che l'utente debba digitare un nome utente è includere la funzionalità "ricordami" in cui il nome utente è persistente in un modo associato al browser, ad es. un cookie crittografato o un cookie contenente un token durevole (ad esempio, 30 giorni) che il server può utilizzare per dedurre il nome utente.

Alcune delle risposte qui sosterranno che il nome utente fornisce un'entropia aggiuntiva. Potresti affrontare questa obiezione richiedendo una password lunga il doppio. Ovviamente questo tipo di cancellazione annulla i vantaggi di una digitazione ridotta, poiché ora l'utente deve digitare tutto il materiale, con la difficoltà aggiunta di mascherare l'input.

Se insisti ad andare con un design senza username, ci sono una serie di caratteristiche comuni che dipendono dal nome utente che dovrai capire come affrontare in altri modi:

  1. Blocco autenticazione. Se l'utente non ha fornito un nome utente o una password corretta, dove memorizzi il contatore di blocco?

  2. Ripristino password. Cosa digita l'utente nel flusso di lavoro "Password dimenticata" che gli consente di identificarsi? (Immagino che questo problema non sia più difficile da risolvere rispetto a una funzione "nome utente dimenticato").

  3. Identificazione collisione ID utente. Quale messaggio visualizzerai invece di "Quel nome utente è già in uso da un altro utente" ?? Sto pensando a un messaggio del tipo "congratulazioni per aver indovinato la password di qualcun altro!" non passerebbe la revisione della sicurezza.

  4. Auditabilità e assistenza clienti. Quale stringa viene emessa dall'applicazione nei registri di controllo, nei registri di debug o in altre tabelle o file, che possono essere riconosciuti da uno sviluppatore o un tecnico di supporto che supporta il cliente? Sicuramente non la password. Inoltre, che cosa fornisce il cliente al telefono quando chiede assistenza, se non il nome utente?

Avrai anche problemi se stai cercando di raggiungere la conformità PCI-DSS (ad esempio se devi accettare carte di credito), conformità FDIC (se lavori con banche) o conformità ISO (se lavori con agenzie governative) .

    
risposta data 27.06.2015 - 02:10
fonte

Leggi altre domande sui tag