Pratiche per la memorizzazione di nome utente / password nelle applicazioni Web

Il server deve essere in grado di accedere ad alcune risorse R. Se un utente malintenzionato ha il controllo completo del server, l'utente malintenzionato può, per definizione, accedere a qualsiasi risorsa a cui il server può accedere. Non c'è assolutamente nulla che tu possa fare a riguardo, tranne proteggere il server.

Se l'attaccante non ha il pieno controllo del server ma ha accesso al file system del server, la domanda è se il server deve avviarsi autonomamente (senza alcun aiuto esterno). Se il server ha bisogno di avviarsi autonomamente, tutti i dati necessari per accedere alla risorsa R devono risiedere da qualche parte nel file system del server e sono quindi disponibili per l'autore dell'attacco. Il meglio che puoi fare è provare a nascondere la password, buona fortuna.

Se il server può utilizzare la guida esterna per l'avvio, l'opzione migliore sarebbe quella di richiedere all'amministratore di inserire la password durante l'avvio (e di mantenere la password memorizzata nella RAM). Se questa non è un'opzione pratica (di solito non lo è), è possibile proteggere la password utilizzando un token USB (ad esempio, memorizzare una password crittografata e utilizzare il token USB per decrittografarlo).

TL; DR: Supponendo che non si possa inserire manualmente la password ogni volta che si avvia il server, non c'è molto che si possa fare se non proteggere il server stesso.

Le risposte sulla crittografia non sono sbagliate, ma l'approccio è sbagliato. Non dovresti crittografare. Dovresti usare una funzione di hash unidirezionale. Ciò significa che esegui un'operazione matematica non reversibile sulla password e memorizza il risultato.

Quando qualcuno vuole accedere, si esegue nuovamente l'operazione con la password che fornisce e la si confronta con il risultato registrato.

CARICA più dettagli qui.

link