Clerk (@clerk) on X

1. After

was infamously hacked through a SIM-swap attack 2019, much of the world moved away from SMS-based one-time passwords (OTPs) The apparent

hack may lead to a similar decline in Magic Links... here's what you need to know 👇

2. Both SMS OTP and Magic Links are susceptible to "social engineering" attacks, but through slightly different vectors For SMS OTPs, attackers target cell phone carrier service agents to take over their victim's phone number, and then start receiving their text messages

3. These are called "SIM swap" attacks, and they're scary because victims are hacked without making any mistakes themselves This is unlike the social engineering attack on Magic Links, where the victim must be convinced to make mistake...

5. While we can argue this was the employee's fault, it's better to assess how the security system can be improved to prevent the employee from making the mistake We don't know Uber's systems intimately, but we can share how safety of "push auth" is generally approached...

6. First, there should be a rate limiter in place. The employee's behavior shows they knew they shouldn't approve a "push auth" they didn't initiate, but became convinced after an hour of spam Rate limiters should make it so the employee can only be spammed for a few minutes

7. Second, the push auth notification should contain context about the initiator Adding information like device type and location to the push notification can help reinforce that the employee did not initiate the auth, and that they shouldn't click "approve"

8. Third, ideally the "push auth" is pushed to the same device the user is signing in on This is great if it's possible, and clearly would have helped in Uber's case Unfortunately, it's not often possible...

9. "Same-device" push auth can be achieved in native mobile or desktop contexts, but the user experience is typically too cumbersome in Web contexts The challenge is that users are unlikely to click magic link in the same browser that they're using to sign in...

10. That's because either (1) they're changing to an email app on their phone which has it's own browser, or (2) they're signing in on desktop, but picked up their phone to click the magic link Forcing a magic link to be clicked in the same browser is nearly impossible, since...

11. since most users aren't even aware when they're technically in a different browser, especially on mobile This is a result of improved *privacy* protections in browsers, which unfortunately came at the expense of security.

12. Same-device push auth is the only mechanism that could truly have prevented this attack, but unfortunately the implementation challenges often mean it's a non-starter So, how can we protect user accounts instead?

13. Believe it or not, many in the security community have long been adamant that "push auth" is insecure, precisely because they're susceptible to social engineering attacks In fact, many Clerk customers disable magic link auth for this reason, and instead use email-based OTPs

14. The idea is that, although this attacker was apparently able to convince an employee to click a button on their phone, it would be much harder to convince that employee to copy a 6 digit code from their email into Whatsapp