Bypass passwords?

[ctessmer]

First, incredible library! Thank you so much for writing it. I've learned a lot already!

And… I want MORE!!! 🤣

I'd like to provide an alternate way for users to login—without passwords.

For example…

1. Login via a challenge code sent to their email or texted to to their phone
2. Login via Sign in with Apple

Is there a way to natively do this where the password field is bypassed? Or… is it fork time? Any thoughts on how to achieve this would be excellent—but of course not expected! My guess is to start dissecting the impersonate users methods (which I haven't done yet).

Again, thank you for the excellent library and learning tool! And for keeping it up to date!

[ocram]

Thanks for your appreciation!

As for the alternative login methods, does this other issue help perhaps?

When it comes to these challenge codes you mentioned, I’d like to note three things:

1. Short challenge codes are usually employed in addition to a password, not instead of it.
2. Sending a challenge code via email is practically the same as using the password reset via email, isn’t it? If you customize the UI messages and email text, there shouldn’t be any difference between the two that is visible to the user.
3. Codes texted to a phone may be dangerous. Some consider SMS not secure enough even as a second factor. If you use it as your only factor, that’s another threat level.

Regarding the functions for impersonating a user, i.e. Auth#admin()#logInAsUserById(int), Auth#admin()#logInAsUserByEmail(string) and Auth#admin()#logInAsUserByUsername(string), you are right: It seems these could indeed be used as well – since what they do is just establishing an active session for that user without checking in any way whether you are authorized to do that. That’s why they’re on the Administration interface, and you should wrap your own access controls around them.

So you could implement your alternative login mechanisms with custom database tables and handle the login in your application code, before calling the library methods to establish the session.

All in all, it appears no fork is necessary there. Let me know how that works for you.

[ctessmer]

Thanks so much for the thorough response, Marco!

That linked issue does seem to be really close to what I'm wanting. I'll give that a go. 😄

1. Short challenge codes are usually employed in addition to a password, not instead of it.

Totally understood. I am wanting to use codes instead of passwords. Maybe this is a mistake. More on this in № 3…

2. Sending a challenge code via email is practically the same as using the password reset via email, isn’t it? If you customize the UI messages and email text, there shouldn’t be any difference between the two that is visible to the user.

Definitely seems like it! Great point.

3. Codes texted to a phone may be dangerous. Some consider SMS not secure enough even as a second factor. If you use it as your only factor, that’s another threat level.

I've always had an inkling that allowing people to sign in with only a challenge code is bad practice. But whenever I've thought it through, I couldn't come up with any rationale for why it's bad practice.

I'm definitely open to being wrong… and would love to know if I am so I can correct how I do things!

My current position? Challenge codes are as secure, practically, as sending password reset emails.

Password reset email

With a password reset email, you're sending a token/link/code to a place the user claims to own (their email address). If they can retrieve the token/link/code, then we assume, "Yes, you are in control of this email address. I'll let you in now."

Sending a challenge code to a phone number seems to be identical. I'll demonstrate by rewriting the above sentence:

SMS challenge code

With a sms challenge code, you're sending a token/link/code to a place the user claims to own (their phone number). If they can retrieve the token/link/code, then we assume, "Yes, you are in control of this phone number. I'll let you in now."

Possible counter argument

A user's email account is password protected and thus "safe". Their messages app is not password protected, and thus "vulnerable".

However, in practice, if someone is in your phone, then they most likely have access to your email anyway, and thus the keys to the kingdom of every site that offers password resets.

Thoughts? Am I missing something obvious [or not so obvious] here?

[ocram]

Well, it all depends on your threat model. If you want to protect your account against access by your little sister or nephew, everything you describe is sufficient. But if your service is used by whistleblowers, wealthy individuals, victims of domestic violence, or other high-value targets, it’s not.

As a general security practice, you don’t start with the assumption that your users aren’t worth protecting anyway (because nobody is interested in their data). In the end, it’s totally up to you – since you are responsible for the security of your service and your users’ data.

Regarding SMS, it’s not so much about the security of your “Messages” app, but more about the security of cellular carriers / telcos / service providers. You can read more here:

• https://queue.acm.org/detail.cfm?id=3425909
• https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.html
• https://www.cnet.com/how-to/do-you-use-sms-for-two-factor-authentication-heres-why-you-shouldnt/
• https://techcrunch.com/2016/07/25/nist-declares-the-age-of-sms-based-2-factor-authentication-over/