Perché non dovrei memorizzare le password in testo normale? [chiuso]

Per semplificare, se le password sono in chiaro, la sicurezza sarebbe compromessa da chiunque ne abbia uno sguardo.

Ora, è necessario ricordare che il log-in del sito Web non è l'unico accesso a un database. Un utente malintenzionato potrebbe essere in grado di ottenere alcune informazioni dal database in vari modi.

Per prima cosa devi sapere che succede. E un hacker di solito non lascerà una nota dicendo "hey, sono stato qui, grazie per i dati!". Quindi, a meno che tu non lo sappia, non puoi cambiare la tua password.

Ora diciamo che ci sono più utenti sul tuo sistema / sito web. Se vieni a saperlo, devi informare tutti gli altri. Quanto tempo durerà tra una violazione e l'altra, l'informazione degli utenti, la copertura del buco e la modifica delle password da parte di tutti?

E se il tuo sistema è aperto al pubblico, non puoi fare affidamento sugli utenti che non riutilizzano le stesse password. Quindi non solo la tua mancanza di sicurezza ha compromesso il loro account sul tuo sistema, potrebbero compromettere i loro altri account altrove.

Inoltre, avere password salvate in testo normale significa che tu le conosci. E come utente, non vedo alcun motivo per cui dovresti sapere qual è la mia password.

Why should I don't store passwords in plaintext?

Ci sono 2 ragioni principali:

1. Se si ottiene un dump del database, gli hacker possono semplicemente accedere con la password in testo semplice nel dump. Se le password sono state sottoposte a hash, la password dovrebbe prima essere forzata bruta.

2. Molti utenti riutilizzano le password, per quanto cattive siano le loro idee, quindi il tuo errore di sicurezza potrebbe compromettere anche altri sistemi.

If I'm a hacker and having access to database, it's unimportant, if the password is secure or not, because a password can be changed

Questo è solo se si accede in scrittura al database. Se hai ottenuto l'accesso in sola lettura o acquisito un backup del database, potresti accedere con la password esistente, ma non modificare il database live. Se la password fosse correttamente sottoposta a hash e salata, dovresti prima eseguire la brute-force, che se fosse unica e ben protetta sarebbe irrealizzabile.

The same in my REST example: If I have the possibility, to grap the network traffic, it should be unimportant, of the Authorization token is placed inside the URL or the POST/PUT header.

Non è la trasmissione il problema, è la memoria di testo inavvertita a costituire il problema (non diversamente dalla memorizzazione di una password in testo semplice). Gli URL sono comunemente registrati in vari file di registro. Questi file di registro non sono sempre ben protetti e, nel migliore dei casi, ciò aumenta i luoghi in cui un utente malintenzionato può ottenere il token. Meno posti memorizzano un segreto, meglio è.

C'è un altro aspetto di questa discussione al di là della tecnica: se è il tuo design a non proteggere le password, allora tu, come gestore del servizio, sei responsabile e responsabile per loro. Le password sono misure di sicurezza per le persone . Non sono di proprietà del servizio. Se le password sono correttamente protette (hash, ecc.), L'operatore del servizio ha fatto la dovuta diligenza ed è responsabile solo della protezione dell'accesso agli hash.

Ad esempio, se si accede a un account di qualcuno senza autorizzazione, l'utente può semplicemente incolpare il fornitore di servizi perché il provider conosciuto conosce tutte le credenziali. E sì, questo dipende dal fatto che si noti questo fatto, che dovrebbe essere assunto (la sicurezza non dovrebbe mai dipendere dall'ignoranza del design).

Ci sono un sacco di motivi per cui non si dovrebbero memorizzare le password degli archivi in chiaro. Ne esaminerò alcuni (dal momento che in realtà dovresti avere solo un motivo per non farlo - non è difficile)

1. viaggio - ad un certo punto la tua password deve essere letta dal database e ciò richiede che VAI da qualche parte, avendo le password non in chiaro concede un altro livello di privacy, supponiamo che tu provi lo stesso modo riguardo alla crittografia come fai tu la memorizzazione delle password e le comunicazioni interne dei tuoi siti non sono criptate: le password di archiviazione in chiaro forniscono all'utente malintenzionato ... beh ... le password !!

2. Dici che "Se io sono un hacker e ho accesso al database, non è importante, se la password è sicura o meno, perché una password può essere cambiata" che non è vero, l'accesso non lo fa t significa necessariamente write accesso, cioè se si fa un dump allora si può solo leggere e una password memorizzata in chiaro può essere leggere abbastanza facilmente.

3. un sistema a bandiera rossa: se il tuo ipotetico hacker può modificare le password come dici tu il tuo utente non sarebbe in grado di accedere e segnalarlo a te, quindi dai loro una reimpostazione della password, diciamo la tua l'hacker fa ancora la sua cattiveria e il tuo utente lo segnala di nuovo - sai che hai un problema. Non è l'ideale, ma cosa ti offre l'archiviazione delle password in testo semplice?

4. Gli utenti finali sono famosi per la sicurezza, probabilmente usano quella password su altri siti / applicazioni. Perché dovresti voler compromettere TUTTE le loro piattaforme?

5. Probabilmente la ragione più basilare - NON È VOSTRA DA VEDERE