Fino a che punto devo andare a proteggere l'UUID SMBIOS di un utente?

7

Il mio server riceverà dati da diverse centinaia di computer. Come parte di tenere traccia di quale computer ha inviato cosa, mi occuperò delle impronte digitali dell'hardware e conserverò i risultati nel mio database.

Al giorno d'oggi la fonte più ragionevole da utilizzare è l'UUID SMBIOS. Questi numeri a 128 bit sono impostati dal produttore della scheda madre e dovrebbero essere unici, ma non così imprevedibili. Ad esempio, l'ultima parte contiene spesso l'indirizzo MAC della scheda NIC integrata e molti di questi sono specifici del produttore.

Dato che non guadagno molto conoscendo l'UUID esatto, sto usando un hash. Ciò introdurrebbe già un po 'di privacy. Tuttavia, dal momento che (senza ulteriori misure) gli hash possono essere calcolati rapidamente, e quegli UUID non forniscono effettivamente 128 bit di entropia, suppongo che sarebbe fattibile risalire all'hash di alcuni UUID.

varrebbe la pena introdurre una funzione hash più costosa per evitare quanto sopra, nel caso in cui il mio server fosse compromesso? Non penso che sarei in grado di usare salt con esso, perché non posso immagazzinare il sale nell'hardware e si suppone che i dati arrivino già in hash (per non comunicare mai l'UUID effettivo). Sul server dovrei essere in grado di raggruppare i dati provenienti dalla stessa fonte. Quanto potrebbe essere utile conoscere l'UUID di alcuni computer, che potresti anche sapere appartenere a una particolare azienda o individuo?

L'ID derivato da utilizzare deve sopravvivere alle reinstallazioni del sistema, quindi un'alternativa puramente basata sul software non funzionerà. L'introduzione di hardware personalizzato (ad esempio chiave hardware / dongle) non è un'opzione. Altre idee che ho avuto, di cui non sono sicuro quanto siano buone:

  • Accorciare deliberatamente l'hash fino al punto che è ancora improbabile incontrare lo stesso hash più di una volta per un singolo utente (quindi sarò ancora in grado di distinguere i loro sistemi) mentre non conserverò abbastanza l'entropia da essere reversibile - I Non sono sicuro di quale sia la lunghezza appropriata e quanto di un miglioramento se invece di un UUID effettivo, si possa stabilire un insieme piuttosto limitato di potenziali UUID
  • Aggiungere un po 'di hardware in più all'hash, a costo di aumentarne le probabilità, ma aumentare l'entropia della sorgente in qualche modo
posta Thijs van Dien 15.10.2015 - 23:20
fonte

1 risposta

1
  1. Puoi almeno aggiungere sale specifico per un'applicazione (con l'hard-coding nell'app), quindi non vale la pena costruire una tabella arcobaleno solo per il tuo piccolo database.
  2. Puoi utilizzare una funzione hash più lenta (pre-calcola l'hash una sola volta per ogni avvio dell'app).
  3. L'aggiunta di più entropia, se possibile, per la tua applicazione sarebbe di grande aiuto.
  4. Se possibile, non associare gli hash con informazioni identificabili o rendere difficile l'associazione, ad esempio richiedendo la password dell'utente per decodificare il suo hash UID. (per ulteriori suggerimenti, avremmo bisogno di sapere di più su cosa ti serve per)

Accorciare l'hash può essere d'aiuto in alcuni casi, ma potrebbe essere dannoso in altri. IMHO non farebbe molto in una situazione in cui l'UID è associato ad altre informazioni come IP, o Nome / Azienda.

    
risposta data 20.04.2018 - 12:33
fonte

Leggi altre domande sui tag