Hash / Digest of string; più client e ricerca inversa devono essere impossibili

Non puoi conoscere l'ID ma DEVI identificarlo univocamente? Allora perché non installare un altro sistema per fornire un'identità sicura (coppia pubkey) per un dato ID? Quel sistema sarà il DB di ricerca in caso di manomissione, ma anche il punto debole nella privacy del tuo sistema. Se non hai bisogno di quel meccanismo di recupero, non creare il DB di ricerca in primo luogo.

Oppure, se non ti interessa davvero quale cliente utilizza il tuo servizio ma solo che è QUALCUNO di un cliente valido, dai un'occhiata all'autenticazione anonima usando prove a conoscenza zero. Una soluzione semplice potrebbe anche essere quella di utilizzare le firme cieche capovolte: il server distribuisce firme valide al cliente durante la registrazione e il cliente le randomizza prima dell'autenticazione. Con questo approccio il cliente può creare nuovi alias randomizzando una firma che gli hai dato, ma puoi sempre assicurarti che la firma sia quella che hai generato ad un certo punto.

Qualche implementazione della crittografia a chiave pubblica suona come la via da percorrere. Ogni client ha accesso alla "pubblica" chiave (crittografia), mentre solo tu hai accesso alla chiave privata (decrittografia) corrispondente. Criptare sulla chiave pubblica e (assumendo una lunghezza della chiave adeguata e senza errori nell'implementazione) solo usando la chiave privata la stringa può essere decodificata. Non sono coinvolte terze parti e è richiesto un coordinamento minimo.

Puoi criptare un hash o (probabilmente più pratico in questo caso, a meno che le stringhe non siano lunghe il che non sembra essere il caso) l'intera stringa.

Se si tratta di un'API pubblica, puoi pubblicare la tua chiave pubblica insieme alle specifiche API. Ancora una volta, se usi chiavi sufficientemente lunghe e l'implementazione stessa è valida, il rischio per la sicurezza di esporre la tua chiave pubblica sarà trascurabile.

Il link è probabilmente un buon punto di partenza per imparare tutto questo.

Dichiarazione del problema. Ecco la mia comprensione del problema che desideri risolvere. Ogni cliente ha un ID cliente di 10 cifre, che è sensibile alla privacy e che non si desidera archiviare o trasmettere al server: ma si desidera essere in grado di identificare in modo univoco il cliente. Capito.

Soluzione 1. Ecco una soluzione abbastanza semplice. Genera un identificatore occultato estraendo iterativamente l'ID cliente a 10 cifre molte volte, diciamo un milione di volte. Il numero di volte in cui si hash iterativamente è un parametro che è possibile scegliere. Ti suggerisco di scegliere il parametro in modo che l'intero processo di hashing iterativo impieghi circa un secondo circa. Stiamo cercando di rendere costoso il recupero dell'ID cliente a 10 cifre originale dall'identificatore occultato.

Quando si registra un nuovo cliente, si genera il proprio identificatore occultato e si memorizza l'identificatore occultato nel database dell'app del server. Quando un cliente installa un'app client, l'app client ottiene l'accesso all'ID cliente a 10 cifre e hash iterativamente un milione di volte per costruire l'identificatore ammantato. Questo processo richiede circa un secondo, ma l'app client non ha mai bisogno di farlo di nuovo: può memorizzare l'identificatore occultato in modo permanente.

Quando l'app client vuole parlare con l'app del server, deve connettersi all'app del server su SSL / TLS e trasmettere l'identificatore occultato tramite la connessione SSL / TLS. Il server può verificare la validità dell'identificatore occultato e utilizzarlo per identificare il cliente. L'app del tuo server dovrebbe utilizzare un certificato SSL / TLS standard e l'app client dovrebbe verificare questo certificato.

Analisi della sicurezza della soluzione n. 1. La soluzione n. 1 è un po 'più sicura rispetto all'archiviazione degli identificativi cliente a 10 cifre sul server, anche se per favore comprendi che non è perfetto. Supponiamo che tu abbia N clienti e quindi N identificativi occultati memorizzati sul server. Un utente malintenzionato che ruba una copia del database del server può recuperare tutti gli ID cliente originali creando una mappatura tra numeri a 10 cifre e i loro hash di milioni di volte. Ci vorranno le operazioni di hash dell'attaccante 10 ¹⁰ × 1,000,000 = 10 ¹⁶ ≈ 2 ⁵³ per costruire l'intera mappatura. Questo calcolo è fattibile, ma non banale: non è qualcosa che puoi fare durante il fine settimana sul tuo computer di casa (è più simile a centinaia di anni CPU di calcolo, quindi è realizzabile con un cluster grande e probabilmente realizzabile per migliaia o decine di migliaia di dollari, ma non super facile). Una volta che l'attaccante crea la mappatura, può facilmente recuperare tutti gli ID cliente N.

Questo potrebbe essere abbastanza buono per i tuoi scopi. Se non lo è, ecco un leggero miglioramento:

Soluzione # 2. Non memorizzare l'identificatore ammantato sul server; invece, memorizza un hash salato dell'identificatore occultato. L'identificatore occultato è definito come prima. Ma ora, quando si registra un nuovo cliente, si genera l'identificatore occultato, si genera un sale casuale per il cliente e si memorizza (sale, Hash (sale, cloakedid)) sul server. Non memorizzi una copia dell'identificatore occultato. Quando l'utente installa un'app client, l'app client ottiene l'ID cliente a 10 cifre, calcola l'identificatore occultato e invia al server una richiesta speciale che dice "Sono nuovo, ecco l'identificatore occultato, puoi inviarmi il mio sale ?" tramite una connessione SSL / TLS al server. Il server prende l'identificatore Cloaked I dal client, e per ogni coppia (salt, h) nel suo database, controlla se Hash (salt, I) = h. In caso affermativo, ha trovato la voce corrispondente per quel cliente e invia il sale del cliente all'app client. (Il server non conserva l'identificatore ammantato.) L'app client ora memorizza il valore salt e il valore Hash (salt, cloakedid). Quando l'app client si connette al server in futuro, invece di inviare l'identificatore occultato, invia il valore Hash (salt, cloakedid). Questo è sufficiente per identificare il cliente.

Analisi della sicurezza della soluzione n. 2 Ciò è più sicuro della soluzione n. 1. Un utente malintenzionato che mette le mani su una copia del database del server deve eseguire 10 operazioni di hash ¹⁶ per ogni ID cliente che desidera recuperare . Per recuperare tutti gli ID cliente N, un utente malintenzionato deve eseguire 10 operazioni di hash ¹⁶ × N; confronta con la soluzione n. 1, dove sono necessarie solo 10 operazioni di hash ¹⁶ .

D'altro canto, la soluzione n. 2 è più complicata e quindi potrebbe essere più complicata da implementare e distribuire. Inoltre, il server deve fare un po 'più di lavoro ogni volta che un nuovo cliente installa una nuova app client (il server deve eseguire N operazioni di hash ogni volta che un cliente installa una nuova app client).

OK è necessario un po 'di congetture qui, mappando i tuoi obiettivi su ciò che può fare la crittografia.

Obiettivo: fare in modo che un'applicazione client non sicura provi che hanno una stringa valida.

Probabilmente non è possibile senza la "stringa segreta" caricata sul server o una chiave incorporata nella stringa. In effetti la stringa diventa una "chiave pubblica" e il lato server utilizza la "chiave privata" per decrittografare qualsiasi messaggio inviato.

Obiettivo: fare in modo che un'app client non affidabile fornisca una stringa che può essere determinata come distinta dalle altre app che parlano con te.

Più facile da fare fintanto che c'è abbastanza casualità nella stringa chiave, basta usare un algoritmo di hashing della password sicuro con molte ripetizioni (vedi le librerie).

Quindi l'app client dovrà fare molto lavoro per hash la stringa, in modo che tu, come amministratore del server, non sia possibile forzare tutte le possibili stringhe di input in modo fattibile.

Obiettivo: aumentare la sicurezza lato server non richiedendo "stringhe segrete" come parte dell'infrastruttura server.

Puoi utilizzare la funzione sopra descritta con l'hashing della password e, se necessario, le indagini possono abbinare la stringa segreta con l'hash offline per i pochi casi che ne hanno bisogno.

Obiettivo: è necessario che le società distinte di seguito siano convalidate per l'utilizzo sui propri sistemi.

The other twist is that each client app is maintained by a separate company, so any key (or salting) based methods obvious to me would need a third party to co-ordinate the keys/salt values without them ever getting back to me.

La sicurezza https standard (più genericamente chiamata SSL o TLS) può essere configurata per risolvere questo problema. Ciascuna delle aziende crea i propri certificati, li invia per la firma, quindi li rispedisce. Quindi sia il tuo server https che il loro software client sono configurati per richiedere solo quei certificati firmati. Nota che questo preserva i segreti bene perché le chiavi private di tutti i sistemi coinvolti non devono mai essere divulgate ad altre parti (questa è la chiave per la magia nel sistema).