Re:Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
by londons_explore on Tuesday December 17, 2019 @02:16PM
(#21817495)
Are designers like you the reason password reset mails frequently take 30 seconds plus to arrive?
I expect things on the web to be damn near instant - I want to click that password reset button and hear a synchronous "ding" of an arriving mail. I don't want to wait for some cron job to run once per minute.
If you want to send mail off the serving path, at least use a push based queue so there is no scheduling or polling involved.
Re:Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
by c0l0 on Wednesday December 18, 2019 @09:10AM
(#21824946)
Yeah... and don't forget that the "R" in "SMTP" stands for "Real-time".
Re:Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'
by ljm on Saturday December 21, 2019 @06:21PM
(#21853928)
I can't speak for any other engineer anywhere else (where I'm sure they synchronously send out email because they haven't learned how to do it better), but there's not a chance github do this at their scale, and they're built on Rails. Rails gives you async mail by default and you just have to plug in a queue adapter for your worker processes to consume.
e.g. GitHub gets this request, queues the job in redis/zero MQ/SQS or whatever they're using, and another process dedicated to sending those emails (or jobs with that priority) does the rest of the work.
This is a massively common pattern in the Rails world and is as trivial to configure as your database connection.
Lots of non-thought too. Sending e-mail directly from the place where web requests are processed isn't very smart. What if the SMTP subsystem is currently down or very slow? How many e-mails will you send if an attacker starts 1000 parallel web requests for a password reset?
A saner way to do these things is to just set a flag ("password reset requested") in the user database there and do the actual work asynchronously in a regularly performed maintenance task. It'll also prevent all these attacks based on misuse of user input by default (unless, in this case, you pointlessly decide to update the user's e-mail in the user database to what the hacker specified).