La password di un canale protetto da password deve essere hash?

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it.

Allora, perché preoccuparsi di memorizzare la password, fai entrare chiunque! ;)

Se stai memorizzando un segreto, è perché questo segreto identifica un sottoinsieme dei tuoi utenti totali. Non tutti i tuoi potenziali utenti lo sanno. Ora, probabilmente ti è stato detto che le password devono essere archiviate con hash e salate. Questa è una password con cui hai a che fare. Ti lascio trarre la conclusione logica.

Forse lo stesso gruppo lo usa per accedere a un SharePoint che occasionalmente contiene informazioni riservate. Forse lo usano per il loro calendario di gruppo che rivela quando il loro ufficio è vuoto o quando viaggiano lontano da casa. Forse la persona che ha creato un account era così fuori di testa che ha usato una password altrimenti preziosa per i suoi beni personali. Forse loro proprio non possono gestire la quantità di credenziali che devono gestire e questo solo spiega il riutilizzo.

Non essere la persona responsabile di causare danni agli altri per pura negligenza. Hash (con un algoritmo di hashing della password lenta). Saltarli (con un unico sale per password).

Dipende dalla tua situazione è buona abitudine hash le tue password encase il database viene compromesso o la rete del vostro cliente consentendo così l'attaccante di accedere a qualsiasi password lui / lei è riuscito a guadagnare.

Vantaggi dell'hash della tua password:

• L'attaccante avrà molto di più da eseguire per ottenere l'accesso ai gruppi di chat privati in quanto dovrà craccare la password. (Forza bruta, tavoli arcobaleno) o set hash che lui / lei conosce.
• Se è anche sottoposto a hashing tramite client, un utente malintenzionato che usa la tecnica MITM riceverà solo il tuo hash della tua password. Quindi, se usi la stessa password su altri siti, dovresti essere più sicuro dell'attaccante che cattura la tua password in testo semplice.

Svantaggi dell'hash della tua password:

• Non sarai in grado di mostrare la password originale senza avere già la password.

Quindi immaginiamo di aver trovato la mia password con hash via attacco MITM: $ 2a $ 10 $ / VcSYK yD0T.vXencRFWv6O.8PZtsTMG7ZxZXNRSMXKu9.JTD5RNCS Prova a trovare la password? Chi sa che potrebbe essere la password del mio account StackOverflow. ;)

Il mio punto è che è molto più sicuro usare l'hashing poiché l'hacker ha molto più da fare. Dovrai applicare la forza bruta o usare la tabella arcobaleno per ottenere il valore originale prima che venisse eseguito l'hash.

Una password condivisa è un design scarso per la gestione dell'accesso a un canale di comunicazione privato. Ad esempio, non puoi cacciare un utente senza chiudere il canale: non puoi far sì che dimentichino la password. Non è possibile impedire a un utente di condividere la password con altri utenti (volontariamente o involontariamente) - se la password di un utente è esposta, è possibile invalidarla, ma se la password condivisa è esposta, disturba chiunque stia usando quella password. / p>

Un design migliore separerebbe autenticazione dall'autorizzazione . Per prima cosa autentifica l'utente, ad esempio richiedendo una password ("Reclami che sei Bob? Provalo!"). Una volta che un utente è stato autenticato, determina quali canali a cui l'utente ha accesso osservandolo in un database ("Vediamo se Bob dovrebbe avere accesso al pazzo canale di loop di mancini.").

Questa separazione delle preoccupazioni ha molti vantaggi, ma ha una conseguenza che potrebbe interessarti o meno: il modo semplice per farlo dipende da un'autorità centrale per determinare chi ha accesso al canale. L'approccio alla password condivisa elimina questa autorità centrale, ma al costo di avere una politica di controllo degli accessi piuttosto rigida (qualsiasi utente può consentire a qualsiasi altro utente di aderire, e solo il consenso completo può tenere un utente fuori).

Se il canale deve davvero essere protetto da password, perché quella politica di controllo degli accessi è quella che vuoi veramente, allora devi rispondere a due domande:

1. Come verrà comunicata la password ai nuovi partecipanti?
2. Ti aspetti che gli utenti possano ridigitare la password ogni volta che si uniscono?

Se la risposta alla (1) è che qualcuno deve conoscere la password per darla, allora qualcuno deve memorizzare la password in una forma recuperabile, quindi l'hashing è fuori per chi fornisce la password. Se la risposta a (2) è che gli utenti memorizzano la password in qualche gestore di password, l'hashing delle password sul server di autenticazione fornisce solo una minima quantità di protezione, ma è comunque una buona idea.

Domanda successiva: quanto è grande il problema se la password è recuperabile sul server? L'hashing della password si rivolge solo a una minaccia specifica: se l'avversario ottiene l'accesso di sola lettura al database. Se ciò consente all'avversario di recuperare le password, allora:

1. Accedono al servizio.
2. Hanno accesso ad altri servizi in cui lo stesso utente ha utilizzato la stessa password.

Per una password condivisa, (2) non si applica, solo (1). Quindi è meno di un grosso problema che con le password per gli account utente. C'è un vantaggio nel memorizzare la password in un formato hash, ma non decisivo.

Per farla breve, una password condivisa non è un buon modello. Se sei bloccato, ci sono buone probabilità che tu debba memorizzare la password in una forma recuperabile, e non è il tuo problema più grande. Se possibile, prendi la password, ma se non puoi, non perdere il sonno.

Si noti che se gli utenti possono creare il proprio canale protetto, non dovrebbero essere autorizzati a selezionare la password. Nella mia esperienza, queste password condivise sono invariabilmente difficili da digitare, ma password facili da usare come quelle di CraZyStraWs!!!1 . Genera automaticamente una password casuale sensibile (come 10 lettere minuscole selezionate in modo casuale in modo casuale) e costringi gli utenti a usarlo.

Ma, davvero, non usare una password condivisa. Utilizza un database di accesso utente / canale.

La tua logica non è corretta.

"La password non deve essere sottoposta a hash perché molte persone avranno bisogno della password."

La seconda parte della tua affermazione è vera e hai deciso che ciò impone che la prima affermazione sia vera. In realtà non sono correlati. Le persone che hanno bisogno della password devono farlo dal tuo server? Sembra che dovrebbero ottenerlo da altri utenti.

Ecco come vorrei affrontarlo:

"La password deve essere sottoposta a hash perché non ci sarà mai il requisito per il server di vendere la password agli utenti."

o

"La password non deve essere sottoposta a hash perché ci sarà un obbligo per il server di vendere la password agli utenti e ci sono controlli che impediscono l'accesso non autorizzato alle password nel database."