[mszary]

Seems like it :) but I would be more pragmatic and didn't bash the system for the reasons you brought up :)

ad 1 - IMO, it's still sufficient at scale with some basic infra. hardening

ad 2 - AFAIK the "secret" was never meant to protect from brute-force, but rather mitigate threats from actors controlling the email part

ad 3 - again, let's be more pragmatic - no one would use it if it required typing 13-letters OTP :) there are other ways to mitigate the potential attack you've described.

Best.

[bradgessler]

OP here… this was a great thread. Here’s a few takeaways, which you may not like, but I think are worth writing out.

1. This def needs hardening. I currently only use it for really low stakes stuff. I need to make that clearer in the README.

2. The next level of hardening I was planning on implementing is rate limiting code requests per email address. I figure I can step up the time-outs between code requests pretty aggressively to slow down brute forcing the code. The ATM that eats the card is a great analogy.

3. Maybe I missed it in the thread, but nobody mentioned that this from of auth makes it evident to the persons being attacked that something is happening if they have a bajillion code requests in their email inbox. There’s a lot of other problems that creates for these auth scheme, like filling a users inbox beyond its quota, triggering high volume breakers for SMTP relay services like AWS SES, etc. that wouldn’t be good.

For those watching, if you’re a security researcher feel free to open a GitHub issue on that repo and I’ll address it.