Comment by pcthrowaway
1 year ago
> Never grant the user any special privileges based on the email domain, and always send a confirmation email from your own side before marking the address as verified in your database
Doesn't this fail if the user registered an account (on google) with the plus sign address, and then signed into your service with that google account before getting the boot? Unless you're sending a verification email for every sign-in...
The idea is that the company's Zoom admin should always specify the exact list of users who are allowed to be in their Zoom account. The email domain should have no bearing. So if you sign in as bob@mycorp.com, and that is a valid corporate account with the right permissions, you are let through. If you try bob+foo@mycorp.com, it should always fail. The pattern of "oh they have a mycorp.com email so they are probably legit" was broken from the start.
This is thankfully less of an issue now since everyone is moving to SAML-based logins and SCIM provisioning.
> This is thankfully less of an issue now since everyone is moving to SAML-based logins...
Hate to break it to you but SAML is same shit different coat of paint, the xml encryption/signature/encoding stuff it pulls makes it just as much a tarpit for bugs and misconfiguration.
SCIM seems pretty decent though to explicitly state who is and isn't on the Guestlist.
What I’ve also seen is integrations with a different OIDC endpoint for company X. It’s still OIDC, but it’s not “sign in with Google”.
This will help, but at the same time will ruin the whole idea of seamless corp users registration in external service, and damage adoption and increase friction.
If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.
9 replies →
> Unless you're sending a verification email for every sign-in...
Yes, absolutely do this! This is what Slack does, and what we do at my current employer (defined.net). "Magic link" email + TOTP is pretty slick.
Please don’t do this, or at least try offer normal login alongside it. This is really bad ux. Instead of being able to have my password manager sign me in without me having to do much, I suddenly have to open my email (which I might have closed because I want to focus), go to the email - god forbid I have to wait 10s for it to arrive - and then it opens a new tab for me…
> "Magic link" email + TOTP is pretty slick.
Agreed. But unfortunately it's also highly phishable.
Can you explain how you would phish a user with a magic link? Since the service is generating a one-time code, and sending it directly to the user's email inbox, I am not sure how an attacker would intercept the code.
5 replies →
As with sibling comment, what threat vector do you see phishing risk with?
A race condition where the phishing email lands first, user clicks link to g00gle.com, gets a convincing message that they also need to present username and password?
5 replies →
I hate this experience. It's an absolute pain when emails are delayed and sign in fails, or just when some apps fail to persist state when I switch to my email client on mobile.
MoneyGram recently lost my business because of this. Their auth emails weren't coming through. Couldn't complete my transaction. I have a 20+ char password. Dunno why they have to dick me around with email auth. Use TOTP if you must, it's also annoying but at least it doesn't fail.
> Unless you're sending a verification email for every sign-in...
Isn't that your typical 2FA flow?