In Depth: Magic Emails
[InDepth#10] One time codes, magic links, and more...
Greetings my friends! This week we’re covering an interesting topic in depth: magic emails. I’m not talking about emails themselves, but rather handling one-time passcodes (OTP) and magic links in emails (using Signed URLs from the last In Depth). Both of these have security important implications1, which is what I’m hoping to convey in this email. It’s a bit different than our usual focus of a specific feature, but I’m sure you’ll learn a lot. As per usual, if you’ve got any questions or I don’t cover a specific use case you’re interested in, let me know in the comments!
P.s. Stick around to the end, Substack have added a Polls feature, so I’ve got a poll for you to vote in!
There are two main types of magic emails we’re going to cover today: one-time passcodes (OTP) and magic links. Both are designed to verify current access to a specific email address, and as such they are in many cases interchangeable. Although magic links have a much higher entropy than OTPs (I’ll explain this below), there are many use cases where an OTP makes more sense and there are protections you can put in place to protect your OTPs from attack.
One-Time Passcode (OTP)
I’m sure you’ve experienced OTPs before - they are a common method used in the Multi-Factor Authentication (MFA / 2FA) systems we use daily for our various online accounts.
You’ll be familiar with SMS-based OTPs and App-based OTPs (Time-based One-Time Passcodes), both of which typically produce a 6-8 digit number you need to enter into a box. Email-based OTPs are functionally the same as SMS-based, just with a different method. They also share the same risks and fear mongering - we’ll cover this a bit later.
The way an email-based OTP works is relatively simple (on the surface):
Keep reading with a 7-day free trial
Subscribe to Securing Laravel to keep reading this post and get 7 days of free access to the full post archives.