Come memorizzare temporaneamente i dati in modo sicuro su un server cache / relay?

Avere un'architettura asincrona, in cui le richieste vengono accodate in una posizione centrale e quindi estratte dai client che vivono all'interno di un limite di affidabilità, rappresenta un importante miglioramento dell'architettura di sicurezza che richiede l'immissione diretta di un PIN da client Internet che si aspettano un sincronismo interazione.

Un PIN è inutile come credenziale e dovrebbe essere considerato solo come un dettaglio di implementazione dal punto di vista della sicurezza. Le aspettative per l'interazione sincrona possono limitare i tipi di intelligenza impiegati nella classificazione di una particolare richiesta come benigna o malevola. Spingere da non fidati in regali di fiducia a una superficie di attacco molto più ampia di quella ottenuta affidandosi a persone non fidate. E un'architettura sincrona in cui la comunicazione può essere transitoria può rendere facile perdere informazioni rilevanti per l'analisi post-facto. Quindi, cambiare tutto questo è già meglio.

Tuttavia, ci sono molte cose che possono essere fatte per migliorare la postura di sicurezza dell'interfaccia interfacciata ad azionamento umano. Li raggrupperei in 3 categorie.

1. autenticazione utente

   Poiché per l'uso di questo sistema è richiesta un'autorizzazione speciale per il personale, ci piacerebbe vedere un premio sull'autenticazione, ovviamente sui macchinari, ma forse ancora più importante sulla formazione e la consapevolezza degli utenti stessi.

   Il meccanismo di compromesso più comune e redditizio, di gran lunga, è il phishing. Lo scenario migliore è che queste persone autorizzate, attraverso la formazione e gli esercizi, sono in grado di diventare profondamente in sintonia con le minacce di impersonificazione e diventare avvocati e agenti sul campo nella scoperta e nell'eliminazione di queste minacce.

   Per quanto riguarda i meccanismi di autenticazione, i normali dettagli http / tls si applicano come linea di base, ma ci sono molte opzioni: 2FA, certificati client, callback attivi, credenziali rotanti, autenticazione social, ecc. I dettagli tecnici in qualche misura sono meno importanti rispetto all'impegno e all'addestramento che si verificano con gli individui che li useranno.

2. custodia dei dati

   I comandi rilasciati dagli utenti autorizzati devono essere archiviati in modo sicuro e integro. Ciò che va nella conservazione durevole dovrebbe venire allo stesso modo. Esistono molte opzioni per garantire la sicurezza dei dati in sicurezza, la maggior parte dei quali incentrati sulla crittografia dei dati sensibili a riposo e sulla firma di singole transazioni da parte degli utenti che li hanno emessi. Per il testo della domanda, non c'è "temporaneo" quando si tratta di archiviazione. Qualunque cosa durevolmente impegnata può vivere in quello stato per molto tempo.

3. intelligenza

   Il sistema come descritto ha autorizzato gli utenti a impartire comandi a vari sistemi di controllo. Ci sono probabilmente una vasta gamma di comandi e un gran numero di attività legittime che possono essere dirette da tali individui.

   Considera modelli di costruzione che supportano la classificazione dei comandi emessi da un individuo. Sequenze di comandi, tempistica dell'emissione del comando, informazioni di feedback consultate, posizione e ora del giorno: una combinazione di questi metadati può essere utilizzata per sviluppare le impronte digitali dell'attività prevista da parte di individui autorizzati. Le sequenze di richieste che non corrispondono alle impronte digitali possono essere contrassegnate per ulteriori revisioni e conferme.

   In modo simile, i sistemi di controllo hanno le loro opinioni su ciò che costituisce un'attività accettabile. Prendere in considerazione lo sviluppo di modelli di minaccia e schemi di classificazione per usi inaccettabili di questi sistemi di controllo. L'esistenza di una coda completa e una cronologia dei comandi per un intero impianto offre un'opportunità unica per questa analisi.

Non è necessario memorizzare il PIN sul database del server web, è sufficiente memorizzare qualcosa che ti consenta di dire (con estrema sicurezza) che l'utente ha inserito il PIN corretto. Supponendo che il PIN sia sufficientemente lungo (potrebbe funzionare un PIN di dodici cifre) potresti eseguire un classico caso di hash salt +.

Tuttavia, la maggior parte dei PIN è composta da 4 cifre, quindi piuttosto inutile come metodo di autenticazione. Invece è possibile utilizzare un metodo di autenticazione decente oltre al PIN (rendendo il PIN solo un dettaglio dell'autenticazione).

Centoquote a atk per rincorrermi sul fatto di quanto un PIN a 4 cifre sia inutile come autenticazione e quanto sia facile forzarlo. Seriamente, ho imparato molto dalla scrittura e dalla riscrittura di questo.

Opzione decente: aggiungi autenticazione corretta

Aggiungi un'autenticazione di accesso e password (passphrase) per gli utenti sul server web. Questa autenticazione può rimanere solo sul server web.

Un utente che desidera interagire con il frontend (almeno con la parte in cui può modificare i dati) deve prima effettuare il login. Notare che se la configurazione corrente del server Web esegue già questa operazione, è possibile riutilizzarla a tale scopo.

Ora che hai un'autenticazione corretta (la passphrase) puoi memorizzare il PIN nel database del webserver basato su di esso. È possibile crittografare il PIN sotto una chiave generata dalla passphrase. Ad esempio utilizzando PBKDF2. In altre parole, alla prima richiesta di un utente, il server web dovrà parlare al sistema di controllo e recuperare il PIN. Quindi memorizzerà il PIN nel database come segue:

AES(pbkdf2(user_passphrase), PIN)

L'utente deve fornire entrambi: la sua password / passphrase per il server web e il PIN per eseguire la richiesta.

In una richiesta successiva, l'utente deve nuovamente fornire la passphrase e il PIN. Tuttavia, il server Web può utilizzare PBKDF2 nella passphrase e utilizzare la chiave generata per decodificare il record dal database e confrontarlo con il PIN fornito.

In sintesi, si aggiunge una funzione di sicurezza migliore (una passphrase corretta) oltre al PIN (piuttosto insicuro). È possibile (e probabilmente dovrebbe) consentire all'utente di modificare la sua passphrase sul server web, ma è necessario un modo per invalidare il PIN crittografato nella cache nel database.

Opzione limitata: hash banale + sale

Quanto segue è come potresti eseguire ciò utilizzando un PIN sufficientemente lungo (ad esempio un PIN alfanumerico di 12-20 byte in lunghezza sarebbe sufficiente contro gli attacchi di forza bruta di oggi). Nota che la selezione della funzione hash è importante.

Su una richiesta dal server web il sistema di controllo, invece di inviare il PIN, può creare un salt concatenato al PIN e utilizzare un hash crittografico per generare un valore. Ad esempio il sistema di controllo può eseguire qualcosa del tipo:

1. Riceve la richiesta dal server per l'utente Bob;
2. Genera un salt casuale (ad esempio 012345667890abcdef );
3. Recupera il PIN di Bob (ad esempio, abdd );
4. Esegue hash <- hash_function(abdd + 012345667890abcdef) ;
5. Restituisce hash e salt al server web.

Il server web memorizzerà sia salt che hash nel database. Su richiesta di Bob al server web verrà inviato un PIN, chiamiamolo reqPIN . Il server può eseguire quanto segue per verificare che il PIN sia corretto:

1. Recupera salt e hash per Bob dal database;
2. Preforma reqHash <- hash_function(reqPIN + salt) ;
3. Confronta reqHash con hash dal database.

Se gli hash sono uguali, Bob ha inserito il PIN corretto.

Se il server web è compromesso, è sufficiente avviare un altro e chiedere nuovi Sali e hash dal client di controllo. Nulla sul database del server web può essere utilizzato per recuperare il PIN (non in meno di una dozzina di anni di hash crunch completo almeno).

Note:

• Il hash_function può essere un qualsiasi hash crittografico e ti dà una possibilità di collisione molto piccola, che è abbastanza sicuro da ignorare nella pratica
• Le funzioni di hash come bcrypt o scrypt sono necessarie (forse anche argon2 ), queste funzioni di hash sono costose dal punto di vista computazionale, rendendo molto più difficile un attacco a forza bruta. Puoi anche eseguire l'hashing più volte, ovvero hash_function(hash_function(hash_function(...)))
• Il sale è necessario nel caso in cui due persone abbiano lo stesso PIN e uno di loro sia l'attaccante. Non può dire che l'altra persona abbia lo stesso PIN di se stesso anche in possesso di tutti gli hash. Avrebbe bisogno di tutti gli hash e tutti i sali, e avrebbe comunque bisogno di ricalcolare tutte le iterazioni di hash.