Feature Request: For Passwordless implementation in mix gen auth, make it a magic code and not a link

I will also add that some versions of outlook do some weird base64 encoding on the magic links so the login link functionality does not work with those browsers. it’s very frustrating.

Hm, for my signup flow I offer the user both a link and code and then validate the original session if the user visits the link on another device.

But for magic links you are also using this flow for auth after account creation, so that results in a serious risk of hijacking by spamming users hoping they click the link and validate an attacker’s session. I assume that’s the underlying reason for this pattern?

I have to say, 6-8 numeric digits does not seem like very much entropy for a login mechanism. If this is implemented the endpoints will have to be rate-limited very carefully.

I agree - If you allow the magic link to validate the original session you have a big risk of hi-jacking. If it is limited to just the session/browser where it is clicked, I am not sure how hijacking can happen?

As for codes - they do need to be rate limited - yes. But it’s not that hard. You can just invalidate the code after X attempts and lock the account for Y minutes after Z attempts. Also the code obviously is only temporary which helps.

Even if you rotate the code on every attempt the probability of randomly guessing a 6-digit numeric code is 1 / 1,000,000, so it would take on average 1 million requests to compromise an account. If on the other hand you never rotate the code and brute-force every possible code in order, it would take on average 500,000 requests to compromise an account. In other words, rotating the code does not buy you much.

This is rate-limiting, yes, but I disagree that it’s “not that hard”. The problem is that with such low-entropy codes the rate-limits go from “defense in depth” to holding up the security of the entire account system. If there is any bug in your rate-limiter then any account is trivially brute-forced. So you have to be very careful, which was my point.

As an example, say you limit each account to 1 attempt per hour. Now say you have 1 million users. All someone has to do is try every user over the course of each hour and they will on average get into one account per hour! So you have to rate-limit globally as well.

If this feature is being proposed for Phoenix all of this has to be carefully considered. Phoenix does not have any rate-limiting solution, so something will have to be built or added. If you pull in a dependency for rate-limiting (Hammer is one) then that dependency is now holding up the security of the entire auth stack, and has to be carefully audited for bugs.

Alternatively you could user higher entropy codes at the cost of the user experience. For a framework like Phoenix which has to cater to everyone, that might be a better path to go down.

Agree with everything, I would add:

Even if you rotate the code on every attempt the probability of randomly guessing a 6-digit numeric code is 1 / 1,000,000

It not taking account timing attacks that may make it even faster to crack a code if implementation is weak.

A good point in general, though strangely in this case the token is so small that it trivially fits into an int32 so I imagine the (integer) comparison would take place in a single CPU cycle. You never know, though, easier to hash anyway than worry about it.

Another reason to hash the tokens is to protect against a database compromise, but that doesn’t help here because the tokens have too little entropy for the hash to be effective.

Also note that in this case there is so little entropy that a crypto-hash alone is not enough to prevent the timing attack for a non-constant comparison because there are so few values that you can just build e.g. a sha256 lookup table (32MB for 6 digits) and then do the timing attack against it, reversing the token back out.

I guess if you salted the hashes that would work? Ensuring the comparison is constant-time would be sufficient here, though, as long as you don’t use the token as the lookup key in the DB. Which you wouldn’t here, I think.

This stuff is never easy!

Username/password are still king, if anything it should have been passkeys.

I still haven’t caught up on passkeys. Apropos, what are they really? (Thought it’s relevant to the discussion here.)

It’s webauthn WebAuthn - Wikipedia