Memorizza la password di un utente in modo recuperabile

Question

Memorizza la password di un utente in modo recuperabile

#1 da (4 voti)
#2 da (0 voti)

4

Attualmente memorizzo le password dei miei utenti come hash PBKDF2, per la parte di autenticazione della mia applicazione web.

Ogni utente ha anche la propria chiave privata e la propria chiave pubblica (anch'essa memorizzata nel proprio profilo utente nel database). La chiave privata viene crittografata con la password in testo semplice al momento della registrazione.

Ora, sono giunto alla parte in cui ho bisogno di recuperare la chiave privata dell'utente, per decifrare altri dati - quindi il problema è; quale sarebbe il modo migliore per permettermi di accedere alla chiave privata dell'utente?

Ho in mente un paio di idee:

I could (upon login) decrypt the private key, then encrypt it with DPAPI and store it in persistent memory (server side).

I could encrypt the user's password with an OTP, and then store the encrypted password in a cookie (on each request I could generate a new OTP, re-encrypt the password, and put back in the cookie) The OTP would have to be stored in server-side persistent memory (probably encrypted with DPAPI).

I could store the store the OTP and the encrypted password in persistent memory (server side).

I could store half of the password (encrypted) in a cookie and half in persistent memory (server side).

Quale di queste opzioni sarebbe la più sicura? C'è un altro metodo a cui non ho pensato?

So che rotolare il tuo è una cosa baaad, ma questa applicazione non ha bisogno di essere super sicura a livello di governo, ma mi piacerebbe che fosse il più sicuro possibile.

encryption passwords password-management

posta binks 06.09.2014 - 16:57

fonte

2 risposte

Leggi altre domande sui tag encryption passwords password-management

Alimentando la creazione del verificatore da PBKDF2 a SRP Socket.IO Client Security

score 4 · Answer 1

Sembra che tu voglia un backdoor e che non ti interessi la privacy o il diritto conseguenze.

Due storie recenti per fornire un contesto

2013: Lavabit intenzionalmente non ha avuto accesso ai contenuti dei suoi utenti in modo che non potesse essere accessibili da un ordine del tribunale. Quando l'NSA ha capito che potevano ottenerlo richiedendo la chiave privata SSL del server e leggendo il traffico tutto (anziché quello dell'utente in questione, Edward Snowden ), Lavabit ha deciso di chiudere piuttosto che rischiare di compromettere la sicurezza di ogni singolo utente.

2016: Debacle Apple vs FBI è una storia simile, che si gioca proprio ora, sulla follia delle porte posteriori. Ho scelto di collegare un riassunto della spiegazione del comico John Oliver del problema perché è piuttosto ben composto. Questo link include anche la funzione HBO di 18 minuti di Oliver su questo tema, che puoi guardare direttamente su Ultima settimana stasera con John Oliver - Crittografia

Se vuoi ancora farlo

PGP supporta più destinatari , che consiglierei su in realtà salvando la password. Ciò consentirà di crittografare i dati su una chiave del server oltre a una chiave specifica dell'utente. Tieni presente che sarebbe altamente irresponsabile non fare pubblicità che stai facendo questo ai tuoi utenti. Potrebbe anche essere illegale.

L'implementazione di questo è semplice come specificare più di un destinatario in GPG o qualsiasi implementazione utilizzata. Ad esempio:

gpg --encrypt --recipient [email protected] \
              --recipient [email protected] message.eml

A seconda dell'uso previsto, probabilmente è necessario memorizzare la chiave PGP privata del server senza password, il che è di per sé un problema. Se possibile, cerca di utilizzare un sistema basato su hardware come una scheda OpenPGP o almeno richiedere un essere umano per sbloccare la chiave a ogni avvio (con failover al tuo codice che accettano che la chiave privata del server potrebbe non essere sempre caricata).

Anche in questo caso questa è una back door e non è consigliata poiché è ancora soggetta a citazioni e hacker (anche se una scheda OpenGPG o una chiave hardware simile dovrebbe impedire attacchi remoti).

Sarebbe molto preferibile trovare qualche altra soluzione al problema. Dal momento che non hai specificato cosa stai effettivamente cercando di fare, questa community non sarà in grado di aiutarti in questo senso.

score 0 · Answer 2

Se il server sta eseguendo la crittografia e la decrittografia, hai creato un " prometti di non sbirciare " . Una volta che la tua domanda è stata compromessa, anche se con mezzi legali o tecnici, allora questa promessa è nulla. Tutte le soluzioni suggerite nel post precedente rientrano in questa categoria.

Affinché i segreti degli utenti rimangano segreti, i segreti devono esistere solo sulla macchina del cliente. Il end-to-end di Google sta cercando di farlo nel browser utilizzando un componente aggiuntivo JavaScript. Questo sistema funziona come previsto, in quanto Google è solo un "promettente di non sbirciare". Google controlla tutti gli aggiornamenti, quindi è consentito backdoor Chrome o End-to-End per compromettere i segreti sul client.