-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bypass passwords? #244
Comments
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:
Regarding the functions for impersonating a user, i.e. 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. |
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. 😄
Totally understood. I am wanting to use codes instead of passwords. Maybe this is a mistake. More on this in № 3…
Definitely seems like it! Great point.
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 emailWith 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 codeWith 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 argumentA 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? |
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:
|
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…
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!
The text was updated successfully, but these errors were encountered: