La conoscenza è potere. In altre parole, se l'utente deve essere in grado di eseguire qualche azione e nessun altro dovrebbe essere in grado di fare la stessa azione, allora deve esserci un valore (una "chiave" ") che solo l'utente conosce e nessun altro.
Inoltre, l'uso di un valore significa necessariamente avere quel valore a portata di mano; quando decifri con una chiave, allora hai quella chiave, almeno fino a quando decifri. Se la chiave deve essere nota solo all'utente, mai, allora questo implica che la decrittografia deve avvenire solo su un sistema che è sotto il controllo esclusivo dell'utente. Per semplificare le cose, la decifrazione dovrà avvenire sulla macchina dell'utente (sistema desktop, laptop, tablet ...) e non su nessun sistema che non dovrebbe mai vedere la chiave (ad esempio il tuo server).
Hai quindi due problemi da risolvere:
- Come memorizzare la chiave in modo che l'utente possa accedervi, ma solo tale utente può accedervi.
- Come fare in modo che la decifrazione avvenga sul sistema client in un modo che non si può eludere facilmente.
Il primo problema può essere risolto usando un file locale o un'area di memoria. In una certa misura, puoi aiutare il client con una certa archiviazione lato server e crittografia basata su password: se hai alcuni dati D , puoi archiviarli sul server E p ( D ), che è la crittografia di D con una password p che il server NON lo sa. La crittografia basata su password è difficile in generale; inizia leggendo questa risposta . In quel modello, la conoscenza veramente specifica dell'utente è la password p , che l'utente trasporta nella sua testa.
Il secondo problema è più problematico. Non lo risolverai in puro JavaScript (in un contesto Web) perché qualunque sia il codice JavaScript che viene eseguito dal client verrà inviato dal tuo server, in modo che il tuo server abbia sempre la capacità concettuale di inviare, una volta , un codice JavaScript malevolo che cattura la password / chiave / qualsiasi altra cosa e te la rispedisce. Suppongo che il tuo problema qui non sia solo quello di dare la possibilità di decifrare i dati all'utente solo, ma anche di farlo in modo convincente , cioè di essere in grado di dimostrare a terze parti a cui realmente non puoi accedere i dati. Nel migliore dei casi, questo è difficile; una possibile strategia è far sì che il client usi un codice applicativo locale in grado di gestire la decodifica, e è firmato da te, e è suscettibile di reverse engineering (C # / .NET e Java vengono in mente qui). Se esiste un'applicazione client di questo tipo, puoi affermare che non puoi saccheggiare in modo discreto i dati dell'utente perché ciò comporterebbe il push di un'applicazione dannosa sul loro sistema, che potrebbe in seguito essere decodificata, la firma che ti incrimina.
In puro Web senza un'applicazione locale, dimenticala. Il modello Java applet avrebbe potuto essere applicabile, ma sarà difficile da fare in pratica perché non molte persone supportano le applet Java al giorno d'oggi ( e .NET + SilverLight è ancora meno diffuso).