Come ottenere in modo sicuro una seconda password specifica per un utente

Question

Come ottenere in modo sicuro una seconda password specifica per un utente

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

4

Dò a ciascuno dei miei utenti un portafoglio Blocktrail unico protetto da due chiavi API (che il server conosce) e una passphrase (unica per ciascun portafoglio).

Voglio che la passphrase del wallet non sia disponibile a nessuno tranne all'utente loggato (persistente per la sessione), in modo che nessuno, nemmeno gli amministratori del server, possano guardare la password del wallet e effettuare transazioni dal portafoglio.

Sto già crittografando le password degli account utente con bcrypt.

Questo è quello che vorrei implementare in modo ideale:

Una passphrase a cui solo un utente che ha effettuato l'accesso "ha accesso". (Non direttamente, ma attraverso la loro sessione).
Che la passphrase sia disponibile per quando l'utente decide di fare un transazione dall'interfaccia utente del client (la passphrase è necessaria in per effettuare transazioni), ma che l'utente non è tenuto a digitare in una seconda password o digita ogni volta la password del proprio account.
Che nessuno è in grado di sapere qual è la passphrase per nessuno specifico utente, non amministratori del server che guardano database / sessioni server, non violazione degli hacker nel server e scrivendo script che perdono la passphrase, no me stesso.

Questo è possibile? La mia ipotesi è che dovrei in qualche modo ricavare un hash, forse, della password dell'utente prima di crittografarla con bcrypt, usarla come passphrase e memorizzarla nella sessione, o probabilmente in un cookie (con ulteriore sicurezza?). Ma poi, di nuovo, gli amministratori che arrivano di nascosto, il server può guardare tutto ciò che è memorizzato in ogni sessione, recuperare la passphrase e rubare i bitcoin, giusto? Inoltre, penso che archiviare una parte client con password hash non sarebbe una buona idea.

Sono davvero nuovo per la sicurezza, quindi non ho idea di quale sarebbe l'approccio migliore per questo. O forse sono troppo paranoico e dovrei usare la password briptata o una stringa casuale (memorizzata in un database) come passphrase del portafoglio? (Considerare anche due chiavi API).

Sto solo cercando un suggerimento nella giusta direzione, dal momento che non so nemmeno se quello che voglio è persino realizzabile. Grazie.

encryption passwords bitcoin

posta Tarman 29.06.2015 - 02:20

fonte

2 risposte

Leggi altre domande sui tag encryption passwords bitcoin

Schema di memorizzazione delle password decisamente più sicuro? Conky per PenTesters

score 1 · Answer 1

I want the wallet's passphrase to be unavailable to anyone but the logged-in user (session persistent), so that nobody, even server administrators, can look at the wallet's password and make transactions from the wallet.

That nobody is able to know what the passphrase is for any specific user, not server admins looking at databases/server sessions, not hackers breaking into the server and writing scripts that leak the passphrase, not myself.

Sebbene sia possibile proteggerlo dall'archiviazione, un amministratore può inserire ulteriori registrazioni per acquisire queste informazioni . Non c'è nulla che tu possa fare al riguardo, tranne memorizzare il segreto sul Cliente come @ Ethan suggerito . (che potrebbe essere migliore o peggiore per la sicurezza a seconda di chi sono i tuoi clienti)

Ho intenzione di rispondere con il presupposto che tu abbia deciso che il server ha bisogno di accedere direttamente al segreto . (nel qual caso anche la memorizzazione sul client sarebbe inutile)

Puoi impedire l'archiviazione semplice lato server , supponendo che non sia stata installata alcuna registrazione dannosa.

I'm already encrypting user account passwords with bcrypt.

La crittografia è reversibile con la chiave. Gli hash sono a senso unico. BCrypt è un hash, non una crittografia. (ed è una buona cosa)

Assicurati di avere un strong fattore di lavoro. Dovrebbe richiedere almeno 100ms (con la protezione DoS appropriata) per calcolare l'hash di BCrypt. Nota che l'hardware dell'attaccante (se l'hash viene rubato) probabilmente calcola questi hash molto più velocemente quando provano a usare la forza bruta.

A passphrase that only a logged in user "has access" to. (Not directly, but through their session).

Quando l'utente esegue l'accesso, il server avrà le informazioni necessarie per decrittografare il segreto.

isn't required to type in a second password or type in their account's password every time.

Ci sarà una password che decrittografa il segreto inizialmente. Questa può essere la prima password che usano per accedere o una password "speciale" se preferisci. Successivamente, il segreto sarà continuamente disponibile come parte della sessione di accesso.

Is this possible at all?

Buona domanda. La risposta è Sì, ho delineato come ciò può essere fatto nella domanda seguente. Fondamentalmente è sufficiente ricavare le chiavi di crittografia dalla password dell'utente e quindi dal token di sessione. Entrambi devono essere sottoposti a hash (non solo alla password) in modo che l'utente malintenzionato non possa accedere al testo originale da cui è stata derivata la chiave di crittografia. Il token di sessione dovrebbe avere abbastanza entropia in modo da poter utilizzare un hash veloce.

Una volta elaborata la gestione della chiave di crittografia, puoi semplicemente memorizzare il segreto crittografato sul server.

Come possiamo servire dati sensibili crittografati senza memorizzare la chiave? Devo utilizzare password definite dall'utente per le chiavi?

Tranne che, nel tuo caso, invece di servire i dati crittografati, lo utilizzerai solo internamente sul server.

Leggi questo e pubblica una nuova domanda o commento se non capisci come può applicarsi alla tua situazione.

E, naturalmente, assicurati che la tua applicazione sia protetta dagli attaccanti (non amministratori) per cominciare. Questa è la cosa più importante.

score -4 · Answer 2

Spero di capire la domanda correttamente, ma perché non ho cancellato la passphrase con SHA-256 e memorizzato il risultato in un db. Non esiste una chiave di crittografia in modo da non poterla invertire e se qualcuno vi arriva con le mani sull'hash e lo invia sarà nuovamente sottoposto a hash e reso non valido.