Memorizzazione dei dati senza sapere nulla sull'utente

-1

Vorrei iniziare affermando che questa è davvero la mia prima incursione nella crittografia.

Ho scritto un nome utente / sistema di password, e così, e ho familiarità con le password di salatura e hashing ... ma non ho mai fatto nulla con la crittografia.

Ho un'idea per un sistema che voglio costruire ... e ho (quello che credo sia) una soluzione intelligente per archiviare i dati dell'utente senza sapere nulla su di loro ... ma non sono sicuro se Sto aprendo la porta a una sorta di "promessa di non sbirciare".

La mia idea è questa: voglio poter memorizzare informazioni crittografate senza sapere nulla sull'utente.

Il design nella mia testa è questo: l'utente imposta un account (nome utente e password). Un blob crittografato, digitato con la password, viene creato lato client (crittografia a chiave segreta tramite libsodium in JavaScript). Il nome utente è hash (lato client ... forse salato con la password?). Questo hash e il blob crittografato vengono inviati al server, dove sono collegati insieme nel database. Quando l'utente effettua il login, l'hash viene inviato al server e il blob crittografato viene rinviato al browser, dove la password viene utilizzata per decrittografare il blob. Tutto questo, ovviamente, accade su HTTPS.

C'è un difetto qui? Sto trascurando qualcosa?

Voglio essere in grado di rispondere, anche a un mandato di un governo, con "Non lo so. E non riesco a scoprirlo".

Ovviamente, il malware sul lato client sarebbe un problema ... ma non sono stato in grado di pensare ad altro modo ... e non è questo il problema che sto cercando di affrontare in questo momento . Voglio solo trovare un modo per archiviare le informazioni sui clienti senza sapere nulla, sui miei clienti.

    
posta Nathan Pinkerton 20.12.2015 - 01:49
fonte

1 risposta

0

Per motivi di coerenza chiamerò l'operatore di infrastruttura (tu) Bob , il client Alice e il governo personalizzato Mallory . Questa risposta descrive solo un attacco molto semplice per lo scenario governativo, ignorando altri aspetti del tuo servizio.

L'impostazione è quella che descrivi: Bob gestisce l'infrastruttura su cui Alice ha memorizzato un blob crittografato. L'accesso di Alice avviene tramite un'applicazione fornita da Bob tramite HTTPS.

Mallory ha le risorse per costringere Bob a collaborare in qualsiasi modo e desidera ottenere l'accesso al contenuto del BLOB crittografato memorizzato sul server di Bob.

Per fare ciò, Mallory cambia l'applicazione che Bob fornisce tramite HTTPS in un modo che espone le chiavi di crittografia (a seconda delle risorse di Mallory in un modo che non è facilmente rilevabile - alcuni mesi dovrebbero essere sufficienti). Ricorda, Mallory è in possesso delle credenziali di Bob, e quindi può servirle correttamente. Mallory riceverà la chiave la prossima volta che Alice utilizzerà il servizio di Bob. Usando la chiave, Mallory ora decifra il blob e fa la danza felice.

Lo scenario è non improbabile , se Mallory vuole davvero i dati di Alice.

    
risposta data 20.12.2015 - 02:26
fonte