Quindi in alcuni casi gli IP possono essere considerati PII (o informazioni di identificazione personale), quindi hai ragione a voler valutare se è necessario proteggerli. Generalmente questo non significa, tuttavia, andare a qualsiasi lunghezza aggiuntiva oltre a come proteggerebbe altre informazioni personali, ad esempio gli indirizzi di posta elettronica.
In ogni caso, l'hashing tradizionale sarà probabilmente un meccanismo inefficace. Esistono solo 4 miliardi di indirizzi IP v4 potenzialmente esistenti e la realtà è che probabilmente stai affrontando uno spazio di indirizzi molto più piccolo. Ciò significa che è relativamente facile per un utente malintenzionato con gli hash calcolare gli indirizzi IP che generano tali hash. Salting generalmente non è utile in questo caso, perché presumibilmente vuoi sapere quando due richieste sono associate allo stesso indirizzo IP e non sarai in grado di confrontare facilmente un hash esistente con l'hash dell'indirizzo IP associato a una nuova richiesta se tutti gli hash sono salati in modo univoco.
Potresti, potenzialmente usare un hash con chiave senza sale, usando una funzione come HMAC. Questo, presumendo che tu possa mantenere la chiave sicura, porterà a hash che possono essere confrontati tra loro, ma non può essere associato agli indirizzi IP che sono stati usati per crearli da un utente malintenzionato che ha gli hash, ma non la chiave. Tuttavia, se la chiave viene ottenuta dall'attaccante, ciò non è più sicuro dell'hash tradizionale.
In generale, suggerirei che il rischio qui non richiede la complessità di una mitigazione di questo livello. Penso che la complessità che stai aggiungendo (e che devi mantenere) probabilmente superi la sicurezza aggiuntiva che otterrai. Tuttavia, se per la propria applicazione si richiede in effetti di considerare gli indirizzi IP sufficientemente sensibili da garantire una protezione straordinaria, si consiglia di utilizzare una funzione di hash con chiave.