Va bene salvare le password come stringhe base64 senza altro hashing o crittografia?

Question

Va bene salvare le password come stringhe base64 senza altro hashing o crittografia?

#1 da (1 voti)

-1

Ho appena ereditato un progetto in cui tutte le password sul lato server sono semplicemente convertite in base64 e inserite nel database. Niente sale, niente hash, niente. Solo un semplice tipo di processo db.Add(password.ToBase64) .

Sicuramente chiunque riesca a mettere le mani su quei dati può facilmente decodificarlo? Da qui il solito approccio sale / hash.

Ho messo in dubbio la decisione di utilizzare le stringhe base64 e mi è stato detto:

Regarding password - If someone is already on your server, you are already under threat irrespective or the encryption you choose. Its same even with someone penetrates your SSL layer itself.

Questo sembra ignorare il fatto che l'hacking in un server non è l'unico modo per accedere a un database. Potrebbe essere facile come passare attraverso il computer non presidiato di qualcuno, inciampare in un backup del database e vedere le stringhe base64 chiaramente ovvie , quindi convertirle gioiosamente tutte in password non elaborate.

So che questa domanda è probabilmente un po 'troppo aperta per il formato usuale di StackExchange, ma il problema non sembra essere trattato molto bene qui con la formulazione della domanda che ho usato. È un argomento molto importante, quindi ho pensato di buttarlo.

Per me è assolutamente ovvio che password shouldn ' essere memorizzati usando solo la conversione di base64 , ma sono ancora relativamente nuovo a tutto questo quindi forse mi sono perso qualcosa.

Grazie.

passwords account-security

posta Stuart Aitken 28.09.2018 - 09:50

fonte

1 risposta

Leggi altre domande sui tag passwords account-security

Dove devo cercare le informazioni una volta che c'è un incidente di sicurezza riportato nelle ultime notizie? [chiuso] Quali sono i pro e i contro del server VPN dietro o davanti al firewall? [chiuso]

score 1 · Answer 1

TLDR: non memorizzare mai le password come base64, quindi hai ragione nel dire che è una pessima pratica.

Surely anyone who gets their hands on that data can extremely easily decrypt it?

Bene, non c'è nulla da decifrare. Base64 non è una crittografia, è una codifica. Il suo ruolo è quello di assicurarsi che la password possa essere memorizzata nel database e che i caratteri speciali non siano un problema. Non fa nulla per proteggere la password. Dal punto di vista della sicurezza, è esattamente come archiviarlo senza alcuna codifica.

This seems to ignore the fact that hacking into a server is not the only way to access a database.

Quella citazione sembra ignorare un sacco di cose. Ci sono diversi motivi per le password hash e non hanno nulla a che fare con la prevenzione del compromesso iniziale del tuo server. Come accennato, l'hashing non fa nulla per impedirlo. Ecco alcuni motivi per le password hash:

Se il tuo sistema è temporaneamente compromesso, ti permette di recuperare. Una cosa su questo scenario. Il tuo server è compromesso e il tuo database rubato. Sì, tutti i dati personali relativi ai tuoi clienti sono trapelati, nulla da fare al riguardo. Ma se le password sono state sottoposte a hash, è sufficiente inviare una e-mail a tutti i clienti invitandoli a cambiare la password una volta che il compromesso è stato risolto. Hai un certo livello di certezza, che l'utente che conosce la password e ha accesso alla posta elettronica è l'utente corretto, in quanto l'utente malintenzionato non ha le password.
Se il tuo sistema è compromesso, protegge il tuo cliente nel caso in cui utilizzi la stessa password su più servizi. La prima cosa che un utente malintenzionato potrebbe probabilmente provare a fare con un DB trapelato di password in chiaro è provare la combinazione di password e-mail su siti popolari come Facebook.
Qualcuno con accesso legittimo al server può utilizzare la password di qualcun altro per mascherare le sue tracce. Immagina uno scenario in cui un amministratore ha accesso completo al server, ma tutto ciò che fa viene registrato. Se cerca di fare qualcosa di nefasto, sarebbe facile capire che è stato lui. Ma se ha appena estratto una password da un altro utente, potrebbe non essere facile o addirittura impossibile capirlo.
Limita un compromesso. Un utente malintenzionato che ha ottenuto l'accesso al DB potrebbe non avere pieno accesso al server. Tuttavia, se è in grado di estrarre la password degli amministratori dal database e registrare come detto amministratore o anche solo altri utenti, potrebbe ottenere l'accesso che non sarebbe in grado di ottenere altrimenti.