-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
README does not mention lack of anti-replay #27
Comments
For example, https://github.com/bakwc/PySyncObj does anti-replay by issuing a 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 Details how I tried to mitigate the worst of it can be found here: bakwc/PySyncObj#174 |
@Sandwichs-del Probably this one can be closed? |
This one is for fernet cipher. Its readme still misses appropriate warnings |
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 ofdecrypt()
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.
The text was updated successfully, but these errors were encountered: