replay attack protection questions / feature requests

[vanschelven]

When checking out this package, I wondered how it would implement replay attack protection.

It seems that the answer is: automatically, using Django cache, using the key as specified in ALTCHA_CACHE_ALIAS.

Questions/requests:

• Is that correct?
• Request to put this in the docs (README)
• Would it be worthwhile to (optionally) implement this in the DB too? This would remove the need to set up a cache. Alternatively, one could say "Just configure your cache using DB if that's what you want"

[vanschelven]

in any case, only if ALTCHA_CACHE_ALIAS is actually explicitly specified. Otherwise, there's a fallback to a local memchache (which will not work cross-process e.g. in production)

[tdruez]

Hi @vanschelven,

It seems that the answer is: automatically, using Django cache, using the key as specified in ALTCHA_CACHE_ALIAS.
Is that correct?

Yes, it's correct: If ALTCHA_CACHE_ALIAS is set in Django settings, it uses that cache backend.
If not set, it falls back to a local LocMemCache instance.

Important caveat: The LocMemCache fallback is process-local, so it won't protect against replay attacks in multi-worker deployments (gunicorn, uwsgi with multiple workers, etc.).

Request to put this in the docs (README)

Thanks for the suggestion, it was affectively missing from the docs.
Added in #26

Available at:

• https://github.com/aboutcode-org/django-altcha?tab=readme-ov-file#replay-attack-protection
• https://github.com/aboutcode-org/django-altcha?tab=readme-ov-file#altcha_cache_alias
• https://django-altcha.readthedocs.io/en/latest/#altcha-cache-alias

Would it be worthwhile to (optionally) implement this in the DB too

You can use the " Django's built-in database cache" as described in https://github.com/aboutcode-org/django-altcha?tab=readme-ov-file#altcha_cache_alias