Il MAC è lo strumento giusto qui e HMAC / SHA-256 va bene. L'utilizzo di una tolleranza di 5 secondi potrebbe essere un po 'ottimistico:
-
Devi assicurarti che entrambi i server abbiano orologi precisi; utilizza NTP . Inoltre, assicurati di utilizzare una rappresentazione ben definita, ad esempio qualcosa in UTC (altrimenti ti troverai nei guai con l'ora legale).
-
Il "ritardo di 5 secondi" deve essere sufficiente per ospitare il round trip: il server A invia la risposta "reindirizza" al client, quindi il client si connette a B e invia la richiesta. Se il cliente si trova in condizioni sfavorevoli (ad esempio un cliente che utilizza un laptop in un treno), la rete può non essere disponibile per alcuni secondi alla volta.
Gli attacchi di replica da parte di estranei sono prevenuti da SSL; l'inclusione del timestamp è per sconfiggere gli attacchi di replay da parte dell'utente stesso. Se il server B richiede un timestamp non più vecchio di n secondi, allora questo implica che se si blocca l'accesso all'utente su A , allora il l'utente può ancora parlare con B per n secondi. Probabilmente puoi tollerare un n più lungo; personalmente, userei un ritardo di 5 minuti. Un altro modo per vederlo è il seguente: se, una volta eseguita l'autenticazione, B consente richieste successive entro un determinato intervallo di tempo T , ad es. con una gestione delle sessioni basata sui cookie e la sessione scade dopo T secondi, quindi ha relativamente poco senso usare un n molto più corto di T .
Si noti che un malintenzionato potrebbe voler falsificare i pacchetti NTP per fare in modo che il clock del server B torni indietro nel passato, in modo da riutilizzare un vecchio URL di autenticazione con un MAC scaduto da lungo tempo . I pacchetti NTP non sono autenticati. Un normale client NTP non accetterà di modificare il suo orologio di quantità considerevoli, anche se un server NTP afferma che è spento da diverse settimane; tuttavia, una chiamata ntpdate di avvio può essere teoricamente abusata. Non ho osservato questo attacco nella pratica.
Suggerimenti per miglioramenti:
-
Potresti voler includere un identificatore per A e B (ad esempio nomi di server) nell'URL di reindirizzamento e come parte dell'input MAC. Questo tiene traccia di chi sta eseguendo l'autenticazione + autorizzazione e per quale server l'utente è autorizzato. Questo è più flessibile se si desidera espandere in seguito il sistema con diversi server A e B diversi.
-
Puoi sostituire il MAC con una firma digitale (RSA, DSA ...): il server A possiede la chiave privata e la usa per firmare; il server B utilizza la chiave pubblica A per verificare le firme. Questo evita di condividere un segreto tra A e B (più un segreto è condiviso, meno segreto diventa).