Qui ci sono le mie "risposte in cima alla mia testa", che potrebbero cambiare dopo aver pensato più.
1) Non sono sicuro che ci sia molto da dire su un sale qui. Nell'uso normale un sale protegge un database di password trapelato contro gli attacchi arcobaleno. Questo certamente non è rilevante qui, e inoltre non penso ci sia alcun altro motivo per il sale.
2) Anche l'hash non aggiunge molta sicurezza, credo. L'hashing è usato per nascondere un segreto durante lo stoccaggio, non il transito. Se lo hai cancellato e passato lungo l'hash, significa che il tuo hash è efficacemente il tuo segreto, e un hash rubato non è meno pericoloso di un segreto rubato. Pertanto, in un senso molto reale, potresti anche solo inviare il segreto stesso, soprattutto perché cambierà regolarmente.
In sintesi, hai effettivamente due difese in atto: un segreto condiviso (che cambia) e un elenco IP bianco. Il tuo segreto condiviso sarà principalmente vulnerabile a cose come gli attacchi di replay o la richiesta di abbaiare: se qualcuno dovesse vederlo in transito, conoscerà il segreto fino a quando non cambierà. Hai menzionato che si tratta di un sistema a sistema, quindi a seconda che i tuoi sistemi si trovino o meno nella stessa zona di sicurezza probabilmente determinerai se tale richiesta debba o meno avvenire su TLS / SSL. Se questi sistemi comunicano tra i data center, probabilmente vorrai comunicare esclusivamente tramite TLS / SSL.
Il tuo secondo livello di sicurezza è tramite IP white-listing. Questo è principalmente vulnerabile allo spoofing IP, che, a seconda della configurazione della rete, potrebbe essere o meno un problema. Sono sicuro che ci sono anche altre opzioni, ma non sono un esperto di rete.
Per un approccio completamente diverso puoi provare a implementare una stretta di mano. L'idea di base è che quando il server A invia una richiesta al server B, il server B convalida la richiesta contattando direttamente il server A, trasmettendogli l'intera richiesta e ricevendo una risposta SÌ / NO (il "no" ovviamente sta restituito se il server A non ha inviato la richiesta in questione). Solo dopo aver ricevuto "SÌ", la richiesta viene effettivamente elaborata. Ciò richiede più impegno per l'installazione e richiede anche più risorse di rete / server, quindi potrebbe non essere preferibile a seconda delle esigenze dell'applicazione. Il vantaggio è che esclude lo spoofing IP e rende superfluo lo scambio segreto. Tuttavia, potrebbe non impedire più attacchi diretti alla rete (ad es. MITM e simili).
Modifica per aggiungere:
L'idea della stretta di mano non è in realtà la mia. Ho usato questo flusso generale nelle mie applicazioni per convalidare le notifiche da server a server. L'idea stessa mi ha rubato da paypal (è il modo in cui convalidano i loro IPN), anche se probabilmente non è nemmeno originariamente la loro idea. Lo sottolineo semplicemente perché è una pratica che è stata in uso per un lungo periodo di tempo, quindi puoi leggere la documentazione per capire il flusso e (potenzialmente) cercare informazioni sui problemi di sicurezza passati che potrebbero essersi verificati a causa di quel flusso . Presumibilmente, dal momento che paypal si basa su di esso per una parte critica della loro infrastruttura di pagamento, è abbastanza sicuro:
link