README does not mention lack of anti-replay

[Sandwichs-del]

Fernet is the default cipher available in python-cryptography.
This unfortunately means that it will be (ab)used for things other than just token signing.

I believe it would be prudent to stress in the README that users need provide their own anti-replay mechanisms, or at least use the ttl attribute of decrypt()

One way for users of Fernet (or even Fernet itself) to do this would be to use a monotonic clock for sent timestamps and then enforce monotonicity for received timestamps.

[Sandwichs-del]

For example, https://github.com/bakwc/PySyncObj does anti-replay by issuing a sendRandKey to the connection partner at the beginning of a connection. The parther is then required to provide this sendRandKey in every message, thwarting session replay attacks.

This is very elegant, but unfortunately they missed/ignored something: An attacker in the position to transparently proxy the TCP streams can still replay/reorder/drop messages.

If they were able to enforce monotonicity of timestamps, this would limit the attackers only to replaying/reordering messages carrying the same timestamp (and dropping, of course)

---

Another side-effect of (ab)using a token-protection scheme like that is that messages must be handled very carefully before they are authenticated. In this case PySyncObj did not do too good because it uses a length || message data format, allowing completely unauthenticated attackers to occupy up to 2 GiB of system memory by "incomplete message" per one attacker connection.

Details how I tried to mitigate the worst of it can be found here: bakwc/PySyncObj#174

[bakwc]

@Sandwichs-del Probably this one can be closed?

[Sandwichs-del]

This one is for fernet cipher. Its readme still misses appropriate warnings