memorizzando le informazioni dell'utente senza essere in grado di accedervi

Naviga le tue risposte
2

Per un mio progetto universitario sto facendo un gestore di password online e voglio poter memorizzare le password degli utenti sul mio server senza potermi accedere da solo. Ecco cosa intendo fare:

  • crittografare le password degli utenti con la crittografia RSA
  • memorizza le chiavi utilizzate per la crittografia, crittografate con un hash lungo generato sul lato client utilizzando master password
  • Se l'utente digita master password ogni volta che vengono utilizzate alcune chiavi

Ma in questo processo c'è un enorme problema . Non riesco a recuperare / generare una nuova password utente. Cosa succede se hanno dimenticato la password.

In base a ciò che ho trovato ci sono due opzioni:

  1. Non dare agli utenti la possibilità di cambiare la loro password - bene questo sembra come uccidere il prodotto prima del lancio

  2. Modifica la password dell'utente mantenendo una copia della chiave crittografata con qualche altra domanda di sicurezza simile a hash: questa non sembra un'opzione in quanto le domande di sicurezza sono obsolete sulla maggior parte dei siti Web moderni a causa dei rischi per la sicurezza.

Ho qualche altra opzione ad eccezione di questa? Credo di aver bisogno di un'architettura "Trust No One" (TNO) o "Zero Trust", ma ci sono alcuni buchi nel mio design.

    
posta melanholly 26.09.2016 - 15:40
fonte

2 risposte

4

Il ripristino o il ripristino sono intrinsecamente una backdoor. Avere quella capacità significa che ce n'è uno.

Ciò che abbiamo fatto con 1Password Teams e 1Password Families è dato a quella capacità agli amministratori di Team / Famiglia ma non a noi stessi. (A questi vengono assegnate indirettamente le chiavi di tutti i depositi, ma a questi non vengono dati i dati del vault effettivo).

Non è una soluzione perfetta, ma pensiamo che sia una buona soluzione. Purtroppo non è disponibile per i singoli account. E così le persone che dimenticano le loro password principali portano a una perdita di dati catastrofici per quelle persone. Questo non è qualcosa che prendiamo alla leggera, ma noi (e speriamo che i nostri clienti) preferiscano il rischio di perdita di dati per la minaccia inerente a noi (o qualcuno che ci compromette) che ha la capacità di decifrare i dati dei clienti.

Ad ogni modo, puoi leggere il nostro approccio al recupero (sebbene sia abbozzato nella bozza attuale) al link

    
risposta data 27.09.2016 - 04:07
fonte
1

Ogni set di dati viene crittografato con una chiave dati, quindi la chiave dei dati viene crittografata con la password dell'utente (o hash della password come indicato). La soluzione al tuo problema è che ciascuna delle chiavi dei dati dovrebbe anche essere memorizzata da qualche parte, dal fornitore se gli utenti sono disposti a fidarsi del provider con i loro dati, o dagli stessi utenti come "backup nel caso in cui dimentichi il tuo password".

Per un gestore di password, suppongo che alcuni utenti non vogliano che la loro chiave sia archiviata in una posizione centralizzata, quindi potresti prendere in considerazione l'idea di offrire loro un'opzione per archiviare il loro file di ripristino sul server o fornirglielo per l'archiviazione in un posto sicuro per conto proprio. Se scelgono di salvarlo da sé e perdere sia esso che la password, sarà un brutto giorno per loro. (Essere sia paranoico che smemorato ha un prezzo.)

    
risposta data 26.09.2016 - 18:40
fonte

Leggi altre domande sui tag

Modifica la variabile Javascript con l'exploit dell'URL Cosa sono OID nel contesto di questo comando keytool?