Quale sarà l'effetto del GDPR sui dump delle password? [chiuso]

GDPR si riferisce in particolare a informazioni di identificazione personale, ovvero informazioni che potrebbero essere ragionevolmente utilizzate per identificare una persona, come indirizzo, indirizzo email, nomi utente, indirizzo IP.

Se il dump della password contiene solo una password e nessun nome utente, dettagli dell'account o indirizzo IP, è probabile che non vengano considerati PII ai fini di GDPR.

Tuttavia, ricorda che se hai la password in testo semplice e qualcuno ha usato qualcosa di personale come password, forse firstname_lastname_dob , che potrebbe essere interpretato come identificativo personale.

Avvertenza standard: questo non è un parere legale, non sono un avvocato, ma sono basato nell'UE e sto lavorando a un team che rispetta la conformità GDPR per un'azienda che elabora dati sensibili.

Anche se questa è in realtà una questione principalmente legale, per quanto riguarda le funzionalità della sicurezza:

• La memorizzazione di account + password sarebbe un'informazione relativa a una persona identificabile, quindi decisamente personale sotto GDPR.

• È necessario memorizzare solo hash di password per rilevare le collisioni. Questo non cambia se i dati sono personali sotto GDPR, ma li trasforma in dati pseudonimi.

• Il modo più pratico per archiviare le password che vedo a questo scopo è una tabella a due righe con l'hash della password e il numero di volte in cui è stata trovata. Dovrebbero essere incluse solo le password in cui tale numero è > 1, in modo da garantire che non possano identificarne univocamente nessuno.

Implementazione specifica:

1. Il server seleziona e modifica saltuariamente periodicamente salt1
2. Il server ha hash il suo dizionario di hash password errati come badphash1 + salt1- > badphash2
3. salt1 ha inviato server- > client
4. L'utente inserisce la password nel suo client (browser)
5. Il client hash la password, quindi hash hash1 + salt1 = > hash2
6. hash2 ha inviato client- > server
7. Il server richiede una nuova password (passaggio 4) se hash2 è IN badphash2
8. Altrimenti il server crea salt2 specifico per utente, invia client server- > client
9. Il client hash password + salt2 = > hash3
10. hash3 ha inviato client- > server
11. salt2 + hash3 memorizzati sul server
12. All'accesso, hash (password + salt2) viene controllato contro hash3.

In questo modo, il sale non è lo stesso per tutte le password. Questo segue la migliore conservazione e le migliori pratiche di trasmissione.

IOW: Non ci sono motivi di sicurezza per archiviare le password in chiaro, nemmeno per verificare la presenza di duplicati. Anche questo può essere fatto sugli hash senza compromettere nulla.