Mantenere gli utenti anonimi - Opzione Secure DB Only - Pensieri generali?

Question

Sto lavorando a un'app Web in cui si stava considerando come mantenere anonime le identità dell'utente.

Comunque io sono giunto alla conclusione , non c'è troppo che posso fare - tranne concentrato sulla protezione del database venga violato.

È questo il consenso generale qui su StackOverflow o ci sono dei metodi che potrei aver perso?

Così ho pensato di:

• Un hash bcrypt dritto e sale tuttavia questo poi porta a contattare l'utente per vari motivi.
• Reimposta password. Potrei salvare domanda/risposta di recupero ma ovviamente le risposte dovrebbero essere leggibili in modo da sconfiggere le cose.
• Un altro punto era dire che avevano dimenticato quelle domande di sicurezza o un nome utente che avevo generato alla registrazione. Non c'è modo di collegarli a un account.
• Anche quello che mi è venuto in mente (supponendo di aver conquistato quanto sopra) limitando gli utenti duplicati. Se eseguissi la ricerca hash/salted sarebbe abbastanza "pesante" sull'elaborazione? Potrei semplicemente tenere una lunga lista di e-mail usate, ma poi il problema si collega di nuovo a un account esistente?

Interessato a sentire i vostri pensieri.

Grazie.

Answer 1

Penso che uno scenario che descrivi possa essere possibile. Puoi fornire all'utente un token di decrittografia quando effettuano l'accesso. Il token potrebbe essere assegnato a una variabile nell'app sul front-end, quindi se lasciano il sito o la pagina, il token verrebbe perso e dovevano effettuare nuovamente il login.

Utilizzando il token, l'app può decodificare i dati crittografati provenienti dal server. Quindi, tutti i dati potrebbero essere crittografati usando il token. Quindi, se sono necessarie modifiche alla password, è possibile generare un nuovo token quando si genera una nuova password e il server dovrebbe decrittografarlo e quindi crittografare nuovamente tutti i dati utilizzando il nuovo token. In questo modo, è possibile crittografare tutti i file server, il codice e i database durante l'utilizzo di SSL, in modo che tutti i dati siano anonimi fino a quando non raggiungono l'utente per la visualizzazione. L'accesso dell'utente sarà l'unico modo per ottenere il token per decrittografare tutti i dati provenienti dal server. Ciò ridurrebbe considerevolmente le prestazioni del server.

Questa tecnica è utilizzata da Atmel nei loro microchip per avere il 100% di crittografia dal dispositivo al cloud. Il che ha senso per un chip perché un utente non deve interagire visivamente con esso. Nel caso di una webapp, ci deve essere un modo per decodificare i dati per la visualizzazione. Che limita le possibilità.

Qui ci sono un paio di link che potrebbero essere utili nel fare questo: https://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services https://www.fourmilab.ch/javascrypt/javascrypt.html

Questo è il link per il chip Atmel che utilizza il metodo di sicurezza di cui sopra. http://www.atmel.com/products/security-ics/cryptoauthentication/

Answer 2

Innanzitutto, l'unico modo per essere completamente anonimi è di non andare mai online. Niente, e non intendo nulla, è completamente sicuro. Qualsiasi hash, crittografia, DB, ecc. Possono essere violati. Se un "hacker" malevolo vuole davvero le informazioni, troverà un modo per ottenerlo, non importa quanto tu ci provi.

Detto questo, ciò che descrivi è possibile, ad esempio guarda Tor, proxy, VPN, ecc. Se crittografa completamente ogni bit di informazione che viene prelevata dall'utente, allora sei in qualcosa. Questo può tuttavia diventare un problema se qualcosa va storto, ad esempio dire triplo hash e multi-sale di tutti gli hash e trovare un problema in cui è necessario decrittografare le informazioni degli utenti (per motivi di discussione, l'FBI lo richiede) a hash salato singolo con una crittografia MD5 può richiedere da 2 a 5 ore per decifrare/crackare. Hai crittografato tutte le informazioni tra cui IP, nome utente, password, email, nome, ecc. Ora stai guardando potenzialmente più di un giorno per decodificare un singolo utente.

Tuttavia, si potrebbe fare qualcosa sulla falsariga di fare un tunnel crittografato nel browser che l'utente DEVE accedere per eseguire il browser (un po 'come una VPN), quindi da lì lanciare proxy nell'URL del browser per favorire l'anomalia. In questo modo l'utente si trova in un tunnel crittografato con un IP diverso e utilizza un IP diverso da quello fornito attraverso il tunnel. Potresti persino andare a fare hopping ogni tanto e cambiare i proxy.

Ora cerchiamo di rendere sicuro il database, suggerirei hash multi salting, assicurandoli con una passphrase, ed eliminando la passphrase dal computer su cui si trova il database. Questo può anche rivelarsi problematico se è necessario accedere agli hash per la decrittazione.

Io dico di andare avanti, il peggio che accadrà è che avrete una leggera traccia dell'utente. Ma ricorda, se lo crei con successo, le persone malintenzionate proveranno a sfruttarlo, solo per vedere se possono.