Stavo pensando a nomi utente e password e mi stavo chiedendo quanto sarebbe stato sicuro che al posto del server avessero un elenco di nomi utente e hash delle password, basta avere un elenco di password e nome utente concatenati e poi hash, o qualcosa del genere.
Se qualcuno potrebbe spiegare perché questo non funzionerebbe sarebbe bello.
Il problema di trasmettere in modo sicuro un nome utente e una password è un problema risolto, HTTPS è elegante e funziona bene.
In termini di questa proposta è significativamente meno sicuro di HTTPS, perché questo sistema proposto è vulnerabile a un attacco di riproduzione. A chi importa cosa siano effettivamente il nome utente e la password, se accedi solo con hash(user+password) , allora questo è l'unico valore che l'attaccante deve sapere.
Le risposte di sicurezza basate su hash sicuro solitamente innovano un nesso di causalità in cui il server fornisce al client un nonce e quindi viene utilizzato hash(nonce+hash(password)) . Il nonce può mai essere riutilizzato, NTML di Microsoft ha avuto questo problema "risolto" più di una volta.
Dopo aver effettuato l'accesso con nome utente e password, devi ancora proteggere l'ID di sessione, che è il token di autenticazione citato dal browser per mantenere lo stato autenticato, quindi HTTPS è una buona soluzione anche per questo.
La tua idea sembra derivare dal fatto che la stessa password attraversa una funzione di hashing e stampa lo stesso valore di hash.
Invece di concatenare la password con il nome utente, la pratica preferita qui è di concatenare la password con un salt casuale unico (solo un grosso blob di testo casuale) che viene generato sul server quando un utente si iscrive. Questo sale, come il nome utente, non ha davvero bisogno di essere tenuto segreto. Il vantaggio rispetto all'utilizzo di un blob generato casualmente rispetto al nome utente è un'entropia aggiuntiva.
Stai pensando a questo nel modo giusto però. Aggiungendo qualcosa alla password prima di renderla più sicura. Dovrebbe idealmente essere qualcosa di un po 'più lungo e più casuale del nome utente, però.
Nel database, solo la password è a scopo di autenticazione e deve essere protetta in quanto tale, il login è a scopo di identificazione. Come amministratore, potrebbe essere necessario accedere all'elenco degli utenti, bloccare o eliminare un account utente o reimpostare una password: impossibile farlo se tutti gli accessi sono sottoposti a hash. Ti perdi anche flessibilità per molti usi (ad esempio, immagina qualche messaggistica privata tra gli utenti, molto difficile da implementare quando nessuno ha visibilità sui nomi utente).
Ecco perché in qualsiasi database di utenti, gli accessi (o qualsiasi altro tipo di dati di identificazione) di solito appaiono in forma chiara e solo i dati di autenticazione sono protetti utilizzando un metodo non reversibile (come gli algoritmi di hash).
Alcuni problemi che devi superare con questo, la maggior parte dei quali vedo sono la modifica delle password, la reimpostazione della password, l'amministrazione degli utenti, le home directory (se applicabile).
Se hai hash username e password insieme, probabilmente avrai bisogno di riferirti agli utenti con un numero ID o qualcosa del genere per admin (riferirsi ad esso con hash sarebbe piuttosto insicuro, e come faresti a sapere chi era chi?). Il sistema non sarebbe nemmeno in grado di verificare che un nome utente fosse corretto senza la password.
A mio parere, sarebbe più efficace implementare un'altra misura di sicurezza aggiuntiva, come 2FA.