 |
| - A - |
| - B - |
| - C - |
| - D - |
| - E - |
| - F - |
| - G - |
| - H - |
| - I - |
| - J - |
| - K - |
| - L - |
| - M - |
| - N - |
| - O - |
| - P - |
| - Q - |
| - R - |
| - S - |
| - T - |
| - U - |
| - V - |
| - W - |
| - X - |
| - Y - |
| - Z - |
Replay Prevention
Replay Prevention
Replay prevention happens in two ways: first, network protocol may call for the exchange of freshly generated random data strings. This prevents replay because the old messages are not subsequently able to contain generated random data. Secondly, severs have the ability to record every message received in a replay cache. Replay is prevented as the cache discards any duplicates that may exist.
One advantage of a replay cache is that it supports stateless protocol. For instance, if a client desires to make a RPC ( remote procedure call) to a server, it can send a single message and receive and instant reply. There are also disadvantages in this type of replay prevention. Maintaining the coherent functioning of replay caches across multiple programs and networks can be rather tricky. Even more established authentication systems such as Kerberos still do not have a fully functioning replay cache.
Considering the difficulty in implementing a replay cache, the best approach in replay prevention is to exchange generated random strings in authentication protocols.