Quali sono tutti i problemi con l'archiviazione di una password in chiaro?

So che questo non risponde direttamente alla tua domanda, ma un altro approccio sarebbe quello di fare in modo che l'applicazione si autentichi al servizio per impostare un canale fidato tra i due. L'app potrebbe quindi passare solo asserzioni di identità per conto dell'utente e non sarebbe necessaria alcuna password per utente.

L'assunto qui è che il servizio è felice di fidarsi dell'applicazione.

Mi sto occupando di questo:

If the password in question is randomly generated and only used by the server to authenticate on behalf of the user to a service (an attempt at "single sign-on"), [the risk of disclosing a password that the user might be using for other accounts] is negated

Questo è solo parzialmente vero. Se si sta semplicemente memorizzando una password generata CASUALMENTE che viene utilizzata solo dal proprio sistema, si riduce solo il rischio. Il motivo per cui non viene negato è perché se mai rivelassi questa password generata casualmente al tuo utente, loro POTREBBE finiscono per usare questo per i loro account reali (questo accade più spesso di quanto tu possa pensare)

Come per quanto segue:

An attacker can now login as the user to your site (although couldn't they just change the hash in the database to be a new password at that point?)

Usa un sale. È anche possibile memorizzare il sale nel DB e manipolarlo in modo programmatico all'interno del codice quando si calcola l'hash (È possibile memorizzare salt X , ma in realtà si utilizza una manipolazione di X quando si calcola l'hash). In questo modo, anche se qualcuno può modificare i valori memorizzati nel tuo database, non sarebbe in grado di accedere a meno che non sapessero come hai usato il sale che hai memorizzato + password per calcolare il tuo hash. Dal momento che questo è single sign on, pensa a quanto sarebbe male se qualcuno potesse accedere con un account privilegiato al tuo servizio? Quali porte potrebbero aprire?

C'è anche un caso in cui l'autore dell'attacco può leggere solo il tuo database. Se hai una vulnerabilità in una query selezionata, penso che l'unica cosa che l'attaccante può fare è leggere i dati dal tuo database, e quindi è ovviamente molto meglio se le password sono sottoposte a hash.

Per rispondere alla tua domanda, qui ci sono tutte le cose brutte sulle password in chiaro che posso pensare in cima alla mia testa:

1. Password facilmente rubate da dipendenti non autorizzati
2. Facilmente (e involontariamente) a spalla e memorizzati.
3. Potrebbe finire per apparire in chiaro nei core dump, nei log o in altri luoghi non intenzionali.
4. Le password possono essere facilmente ottenute dagli hacker se sono in grado di ottenere una copia del database. Questo non significa sempre che il server del database deve essere compromesso, a proposito (cioè potrebbero rubare un backup o un laptop di sviluppo di qualcuno).
5. Può rivelare ulteriori informazioni riservate (ad esempio se un utente utilizza una variante del suo compleanno come password)
6. Perdita di reputazione immediata se si verifica un incidente o la tua architettura è mai resa pubblica.
7. Elimina la maggior parte dei livelli di conformità per HIPAA, PCI-DSS, ecc. Anche se è solo per parlare con Jabber, poiché presumibilmente una squadra criminale sarebbe in grado di impersonare un utente finale e utilizzare un attacco di ingegneria sociale.
8. A seconda della tua giurisdizione, puoi risarcire gli hacker contro determinati addebiti legali, ad es. potrebbe essere illegale decifrare la password ma non leggerne una in chiaro.
9. Gli altri programmatori rideranno di te.
10. La sicurezza informatica è strong quanto il suo link più debole.

Per rispondere alla tua domanda reale , lo schema tipico per questo genere di cose sarebbe il seguente:

1. L'utente finale si autentica con il tuo sito web
2. L'utente finale indica il desiderio di utilizzare Jabber (ad esempio, fa clic su un collegamento)
3. Il tuo server comunica con Jabber utilizzando le credenziali che sono state generate casualmente per questo specifico utente
4. Jabber autentica il tuo server tramite elenco IP bianco, certificati client o altri mezzi comuni.
5. Jabber autentica le credenziali e crea una sessione per l'utente finale.
6. Jabber restituisce la chiave di sessione al tuo server.
7. Il tuo server restituisce la chiave di sessione al browser dell'utente
8. Ora il browser è in grado di utilizzare Jabber.

In questo schema, le credenziali menzionate nel passaggio 3 non sono hash, poiché devono essere recuperabili. Questo è inevitabile e non raro; in situazioni in cui è implicata la conformità (ad es. HIPAA nel tuo caso), invece, le credenziali possono essere crittografate, utilizzando un master secret (AES128 è la scelta predefinita) conservato in una parte sicura del tuo sistema (ad esempio, l'archivio di certificati di Windows o la API Crypto ). L'accesso ai segreti può essere applicato tramite le autorizzazioni dell'account di servizio; solo il microservizio specifico che comunica con Jabber dovrebbe essere in grado di accedervi, e dovrebbe solo esporre gli ID di sessione che è stato creato, mai le stesse credenziali.

Si noti inoltre che si dovrebbe pensare a schemi per la rotazione del materiale crittografico ogni pochi mesi circa, o immediatamente su richiesta se il sistema è mai compromesso.

Ci sono due rischi principali con l'archiviazione della password in chiaro.

1. Molte persone riutilizzano le loro password e le stai mettendo a rischio, se c'è una violazione della sicurezza del tuo sito.

2. Gli amministratori di sistema, gli operatori di backup e altri possono ora avere accesso alle password degli utenti. Questa è una cattiva pratica.

Sì, hai ragione che se un utente malintenzionato compromette il tuo sistema e ottiene pieno accesso al tuo database, allora potrebbe modificare la password con hash anche se hai le password hash. L'hashing non impedisce la modifica. In linea di principio, se un utente malintenzionato riesce ad ottenere un accesso di sola lettura al tuo database (ad esempio, un backup viene rubato dal bagagliaio della tua auto), l'hashing è più sicuro: se memorizzi le password in chiaro, il ladro ha tutte le tue password, mentre con l'hashing, il ladro non ottiene immediatamente tutte le tue password.

Suggerisco anche di leggere le altre domande nel tag password .

Stavo per fare un commento, ma quando sono andato a scriverlo, ho pensato che fosse più una risposta. Chiaramente questa funzione di servizio Jabber dovrebbe essere al 100% separata dalle informazioni sulla salute. Devi seguire le TUTTE leggi sull'archiviazione delle informazioni sulla salute.

Il che mi porta al seguente pensiero: Jabber non supporta OAuth? L'utente in questione deve conoscere a un certo punto il nome utente e la password per l'autenticazione con il server Jabber di terze parti.

Quindi ci sono due modi per gestire l'accesso all'account "jabber". Se non desideri che l'utente fornisca i dettagli di autenticazione, in realtà hai solo un'opzione, crea l'account per l'utente e gestisci l'autenticazione da solo.

Puoi farlo creando il nome utente e la password per l'utente. Potresti utilizzare un sistema di autenticazione come OAuth dove il client e il server scambiano informazioni. OAuth consente all'utente di richiedere il token, quindi il server concede il token e questo consente al client di accedere ai contenuti. Questa approvazione può essere portata via senza problemi in qualsiasi momento.

Questo richiede all'utente di essere "utente" e fornire le informazioni al server in modo che il client possa approvare l'accesso del client al contenuto. Quindi l'altra soluzione richiederebbe all'utente di fornire le informazioni una volta e utilizzando una meccanica simile, ottenendo l'approvazione fino alla revoca dell'approvazione.

Onestamente non capisco la preoccupazione. L'accesso al servizio Jabber, se separato dalle informazioni sanitarie, non comporterebbe una fuga di informazioni personali e infettive.