Questo viene fermato dagli autenticatori. Ogni volta che si presenta un ticket Kerberos, deve essere accompagnato da un autenticatore, che viene crittografato utilizzando la chiave di sessione e contiene (tra le altre informazioni) un timestamp. Il server controlla che il timestamp sia recente (in Kerberos 4, che significa "entro 5 minuti;" in 5, è configurabile, ma 5 minuti è l'impostazione predefinita) e che non ha mai visto quell'autenticatore prima. L'autenticatore fa semplicemente affidamento sulla chiave di sessione, quindi può essere generata dal client; un nuovo autenticatore viene creato ogni volta che si invia un ticket.
Per rispondere "e se usano la stessa sessione", il protocollo di base Kerberos non lo gestisce. Kerberos, al suo interno, autentica l'utente che apre una connessione; non deve fare altro. I protocolli applicativi sono responsabili della gestione della protezione di ulteriori messaggi se ciò è importante; Kerberos fornisce due modi per farlo, oppure può fornire dati dall'autenticazione a qualsiasi sistema utilizzi il protocollo dell'applicazione, ma un protocollo applicativo non deve utilizzare Kerberos a parte l'autenticazione iniziale. Tutto dopo dipende dal protocollo dell'applicazione.
Kerberos ha due opzioni per la comunicazione protetta da Kerberos oltre il messaggio iniziale (una autentica, una crittografa e autentica); un protocollo di applicazione può usarli per proteggere le comunicazioni successive, ma non è necessario. Entrambi utilizzano un timestamp e / o un numero di sequenza per impedire i replay; il numero di sequenza protegge dai messaggi scartati e dal riordino dei messaggi, mentre il timestamp è indulgente se non è un problema (ma impedisce a un utente malintenzionato di ritardare un messaggio, poiché un messaggio ritardato verrà rifiutato), ma entrambi impediscono i replay.
Se si è preoccupati che un utente malintenzionato maneggi il flusso di dati sul server di stampa, è possibile definire il protocollo del server di stampa in modo che utilizzi KRB_SAFE o KRB_PRIV (rispettivamente "autenticarsi solo" o "crittografare e autenticare" ); entrambi proteggono contro i replay. Oppure puoi usare un altro sistema che preleva una chiave di sottosessione dall'autenticatore come una chiave pre-condivisa e ha una protezione di riproduzione; un protocollo TLS-PSK con la chiave della sottosessione come probabilmente funzionerebbe PSK (TLS protegge dagli attacchi di replay). Il punto è che Kerberos non protegge intrinsecamente da quel tipo di replay, perché non dice nulla su come fare il resto della comunicazione; per proteggere dagli attacchi sulla comunicazione post-autenticazione, devi utilizzare% di% co_de Kerberos o KRB_SAFE o utilizzare qualcos'altro che protegge quella comunicazione.