Passwordless Authentication #645
Conversation
nils-wisiol
force-pushed
the
20221127_email_login
branch
from
51956b8 to
aa3aa0f
Compare
missing: - correct redirect after clicking login-button - correct redirect when using auth action - testing for mfa
|
I've adjusted the API to allow passwordless login via an authenticated action. Webapp modifications are sketched out, but not fully functional yet. 2FA testing needs to be done for the API and for the webapp.
@peterthomassen let me know what you think! :-) |
There was a problem hiding this comment.
Looked over it, looks nice! Left some comments, but didn't do a real code review.
But why are we doing this? Would you like to have the feature yourself, or are people asking for it? -- The "real" way for passwordless login would be with FIDO2. Could the (potential) demand be met this way?
| data = self.get_serializer( | ||
| Token.create_login_token(user), include_plain=True | ||
| ).data | ||
| user_logged_in.send(sender=user.__class__, request=request, user=user) |
There was a problem hiding this comment.
The signal should be sent after the token is created but before the serializer is called. (The token also exists when the serializer raises an exception; we don't want the signal to get lost.)
| {% extends "emails/content.txt" %} | ||
| {% block content %}{% load action_extras %}Hi, | ||
|
|
||
| someone request a login link for your account. To log in, please use the following link (valid for {% action_link_expiration_hours action_serializer %} hours): |
There was a problem hiding this comment.
I think we should at least have the requesting IP address and perhaps the user agent here, so users can associate the request with themselves. (Geo-mapping seems not very reliable, so I'd vote for not having that.)
| except User.DoesNotExist: | ||
| pass | ||
| else: | ||
| serializers.AuthenticatedCreateLoginTokenActionSerializer.build_and_save(user=user) |
There was a problem hiding this comment.
This allows spamming a user with log-in emails.
To avoid such scenarios with sign-up emails, we store user pending registrations, and clean them up after 24h unless activated. During that time, no other registration email can be sent. -- Is there a way to deal with this here? (One way could be to only allow passwordless login if no password is set. This would need UI to switch between password and passwordless login.)
Password reset seems to have the same problem, though.
Don't want to intrude in the work ticket, but I was literally asking myself the same question. The few times I have encountered passwordless logins via E-Mail were really shoddy, quite unintuitive and unnerving. It especially hits two points that strike me as potentially problematical:
Also as an afterthought: relying on the user's mailbox security somehow strikes me as not better / passwordless login but simply using "the same password as email" again. So if a user's login info for his mailbox falls into wrong hands, his desec account is compromised, too. I'm curious as to the real world scenario covered. On a side note, even that annoying service that only had "login via email" abandoned it last year and now uses user/pass, TOTP and U2F/FIDO. :) Cheers |
You are not intruding at all. Community participation is highly welcomed!
This is especially true as people often run their mail server domain's DNS at deSEC. If the DNS config is broken and they need to log in to fix it, but that requires email access, that's a new failure mode.
The login token will be issued to whoever clicks the link, not to the person who issued the email. This is different from 2FA spamming, were the account owner unwittingly approves of a transaction they did not create. However, one could require another mitigation, e.g. "clicking the login link in the email" requires entering a code that is displayed when trigger the log-in email (i.e. you go to the log-in form, submit email address without password; as a result, an email is sent and a code is displayed; you click the link in the email, a form appears in which you have to enter the earlier code, and only if that's right you're logged in). I share the spam listing concern, but I'd also like to observe that the same issue exists with the password reset functionality.
That's already true for the password reset mechanism. The password adds no layer of security over your mailbox, whether log-in via link is supported or not. To avoid that, you'll have to enable MFA. I'm mainly worried whether the extra complexity and chance of bugs is worth the benefit. |
|
Thanks!
Yeah, that is another part coming into play. DNSsec or SPF, DMARC and DKIM could be totally shattered and to login I'd need the mail from a domain managed there that is currently broken. Ouch! Especially DNSsec could happen there, we watched quite a few happenings with bad key rollovers of the years.
Of course. I actually had that confused when thinking about SMS 2FA spam, right. But the spam could also trigger other automated mail defense mechanisms with various hosters or forwarders that then would classify the mail (or perhaps your servers) as spammy and won't deliver it. So a sort of quasi-DoS from an external attacker?
I'm with you with that, but - and that's a big but - an account covered with user/pass + TOTP (or U2F/FIDO) wouldn't be attackable. Also the attacker would have to know the email registered with you. That could be the same as the email account but with services like SimpleLogin / (now) Proton or Apples Mail hiding, adding mail aliases for services isn't that uncommon anymore. And if the mailbox gives no indicator of that email, an attacker would have to guess - so it's a tiny bit more secure than that even if not that much ;)
I'd have to say for me I don't see a benefit at all as it's not really passwordless (I have to login into my email) and depending on a second method of getting access (in that case email) that isn't "instant" (email certainly is not an instant medium) just adds many layers of potential problems if I have to access an account now and have to wait for a mail to arrive. Really curious about the use case though :) |
|
This is not to replace password-based login or 2FA/MFA. Because deSEC does not require a password to create an account, we have many accounts that do not have a password. For these accounts, if the user wants to use the web-based UI, they first have to reset their password and can then login. This makes things more complicated than they need to be, especially if it's (thought to be) a one-off thing or if this users was advised by deSEC support to go to the web UI. Unavailability arguments above apply equally to password reset, and generally we won't make it less available by adding more login methods. What we really should be talking is if this creates an additional attack surface. (I think it does not, simply because obtaining a password reset link is equally hard and essentially has the same effect.) That being said, I do not have hard data on user needs and just saw somewhere that you can just leave the password field empty to get a login link, which I found neat. My suggestion towards the password reset / login link spam would be to require a captcha and/or to have an additional field at the user that records the last time we sent an email and with that implement some very basic rate limiting. (But only if this ever becomes a problem.) |
Provide users the option to login using their mailbox. We send an authenticated action that will resolve into a login token.