Come conservare i dati privati in modo sicuro e accessibile al pubblico?

Question

Come conservare i dati privati in modo sicuro e accessibile al pubblico?

#1 da (2 voti)
#2 da (1 voti)

11

L'attività potrebbe non essere risolvibile in una formulazione così ampia come nel titolo, ma questo è il mio scenario (che è in qualche modo simile ad esempio per iscrizioni alla newsletter e quindi sicuramente è già stato pensato)

Voglio implementare un database su un server web in cui sono archiviati dati privati sugli utenti. Gli utenti non dovrebbero avere un nome di accesso di fantasia, invece devono essere "validati via email", cioè, l'accesso a una casella di posta dovrebbe essere sufficiente per l'autenticazione.

Gli utenti dovrebbero essere in grado di creare, aggiornare, eliminare solo i propri dati. L'amministrazione centrale dovrebbe essere in grado di esportare i dati dal server Web a un host protetto.

Lo scenario di attacco è che il server Web insieme a tutti i dati su di esso (compresi gli script di pagine Web e il database) viene compromesso. Il requisito è che i dati privati memorizzati lì prima il compromesso rimangano protetti (supponendo che non venga tentato nessun altro accesso utente).

Ecco le mie idee finora: per l'autenticazione ho solo gli utenti email .

Un nuovo inserisce il suo email in un modulo, che causa hash(email) + publicencrypt(email) + random nonce + timestamp da memorizzare che rappresenta l'utente e all'utente viene inviata una mail contenente un URL con parametri random nonce e email . (Dato che c'è solo (protetto) email e non (non protetto) username più (protetto) password , cose come il sale non possono essere usate e devo ricorrere a hash(email) , no?).
Lo stesso accade con un utente esistente, in cui solo hash(email) sarà uguale a qualsiasi tentativo precedente. publicencrypt(email) , random nonce e timestamp differiranno.
Chiunque acceda a un URL con i parametri email e nonce come generato sopra può eseguire operazioni sul record del database corrispondente dopo aver controllato: Esiste un record con hash(email) corrispondente e nonce corrispondente e non troppo vecchio% codice%? Se sì, l'utente può procedere. Nota che durante la sessione web di questo utente, è disponibile il testo trasparente timestamp .
L'esportazione nell'host di amministrazione centrale protetta avviene esportando i dati crittografati così come sono. La decifratura avviene con la chiave privata che corrisponde alla chiave pubblica utilizzata per crittografare (quest'ultima è considerata pubblica perché risiede sul server compromissibile).

L'aggiunta di una nuova voce è completata a questo punto, aggiungendo un flag email al record. Cancellare il record è ovviamente facile. La visualizzazione di dati non riservati (ad esempio, quando è stata creata o modificata la voce) è anche un'attività banale.

Il mio problema è: come gestire in modo sicuro ulteriori dati privati? Potrei semplicemente archiviarlo in forma crittografata (come l'e-mail), ma in quel caso il contenuto non può nemmeno essere mostrato all'utente autenticato. Potrebbe cambiarlo, ma non può decifrarlo in una sessione web successiva. Questo è ovviamente sub-ottimale. La mia unica idea è di crittografare i dati aggiuntivi con una chiave diversa: invece della chiave pubblica di una coppia di chiavi asimmetriche usa una chiave simmetrica che è riproducibile prodotta da isValid , cioè memorizza dati aggiuntivi come %codice%. Poiché il testo in chiaro email è disponibile all'utente stesso durante la sua sessione Web, nonché nell'esportazione decrittografata sull'host protetto, symmetricencrypt(data,key_generated_from(email)) può essere ricostruito.

Vedo i seguenti problemi:

Dato il formato limitato degli indirizzi email (ad esempio, alcuni domini possono verificarsi molto spesso), una chiave generata dall'e-mail come descritto sopra potrebbe essere sufficientemente sicura?
In realtà, dato il formato limitato degli indirizzi e-mail, è il email che ho usato nel concetto di base che protegge solo l'e-mail abbastanza bene? (C'è abbastanza entropia negli indirizzi email, per così dire?)
C'è un approccio migliore?

encryption privacy

posta Hagen von Eitzen 14.12.2015 - 20:48

fonte

2 risposte

Leggi altre domande sui tag encryption privacy

L'esecuzione casuale di "docker pull" significa essenzialmente che sto dando accesso root a qualcuno? Perché non possiamo ignorare DNSSEC

score 2 · Answer 1

A new enters his emailinto a form, which causes hash(email) + publicencrypt(email) + random nonce + timestamp to be stored representing the user and the user is sent a mail containing an URL with parameters random nonce and email. (As there is only (protected) email and not (unprotected) username plus (protected) password, things like salt cannot be used and I have to resort to hash(email), don't I?).

È possibile aggiungere una colonna in più con dati casuali aggiuntivi (generati in abbonamento) che vengono utilizzati solo come sale per il calcolo dell'hash (un sale casuale per l'utente). Questo ti darebbe lo stesso effetto dell'uso del nome utente (non esistente). Il sale può essere memorizzato in chiaro nella stessa riga dell'e-mail, nessun problema con questo. Basta usare un solo sale per utente e renderlo casuale e stai bene.

Given the restricted format of email addresses (e.g., some domains may occur very often), could a key generated from the email as described above be secure enough at all?

Usa PBKDF2 per ulteriore sicurezza. Questo ti darebbe la massima sicurezza possibile quando l'unico "segreto" che l'utente può fornire è il suo indirizzo email.

Actually, given the restricted format of email addresses, is the hash(email) I used in the basic concept that secures only the email good enough at all? (Is there enough entropy in email addresses, so to speak?)

Già prima, usa un valore salt memorizzato nel database.

Is there a better approach?

Probabilmente solo non ti fidi di avere l'indirizzo email come password. Ma se questo è davvero un requisito, non puoi fare molto meglio. Potresti avere ulteriori informazioni sul server da utilizzare sulla derivazione della chiave (derivare la chiave da email + informazioni sul server), ma ciò non migliorerebbe la sicurezza nello scenario di attacco che l'utente ottiene offline tutti i dati. Ovviamente è possibile utilizzare un hardware di crittografia (HSM) e utilizzare la chiave derivata come PIN per la chiave nell'HSM. In questo modo, l'utente malintenzionato non deve solo scaricare i dati dal server e identificare l'e-mail associata a ciascun account, ma anche controllare il server per utilizzare l'HSM per decrittografare i dati.

score 1 · Answer 2

Penso che potresti essere alla ricerca di un sistema di autenticazione basato su token. Invia un indirizzo email, il server produce un token e lo invia a loro, facendo clic sul link che deve inviare il token al tuo sito web in qualche modo. Il token è casuale e valido solo per un periodo di tempo limitato (ad esempio 15 minuti - pensa memcache ^. ^) E può essere aggiornato in base all'azione dell'utente. Per quanto riguarda la crittografia, è possibile ricavare qualcosa dall'hash dell'email come chiave e non mantenere mai la versione normale dell'indirizzo e-mail. E rifiuta di riutilizzare gli hash nella nuova fase utente.

Come nota a margine, suona molto spaventoso usando solo l'e-mail per accedere. Tenete presente che la maggior parte delle app non viene utilizzata dagli utenti al giorno d'oggi e la prima cosa che vedranno sono i contatti. Quindi c'è una possibilità molto alta che qualcuno abbia già un elenco di utenti e accesso.