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”.

If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.

Most companies have these directories but in different forms, including Wiki pages. The idea of auto-enrollment is that it is based on a standard and widely adopted OAuth protocol.

Employee records as wiki pages? That must be a joke, right?

Why not? If your company has lots of employees, like tens of them, you may create a nice template for those pages.

Because it’s not suitable for machine-processing of employee data. This belongs in a database, Active Directory, or HR software. Do you also do payroll with wiki pages?

Not everything should be suitable for machine-processing. A certified MS professional should administer Active Directory. HR software should be paid for and learned how to use it first.

On my second startup we payrolled via Google Spreadsheet. By the way, it is also an okay storage for employee data.

I suppose I'll confess that you are correct, this approach is totally viable at smaller scales. I've just seen what happens in a large business context.

It's above all, a security nightmare, since the wiki pages are perpetually out of date and incomplete, and it makes the process of thing like provisioning and deprovisioning access so labor intensive.

Why not on a piece of paper then?..

It's hard to share and update.

They sure have those directories in different forms out of sheer need but every time I’ve seen people have to consult wiki pages to get information that should be in a standardized directory it’s a shitshow that is borderline impossible to automate.

> 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.

The attack works by getting the user onto a page you control that looks like a slack page that says, "we need you to confirm your email". User enters their email and gets a legitimate email from slack. User enters the code on the original phishing page and the attacker gets a link that lets them log in as the user. I built this exact exploit for slack in a few hours. It was trivial.

I've never seen a foolproof way to mitigate this. Best you can do is big warnings in the email telling the user never to enter the code anywhere but slack.com. You can also do fancy stuff like comparing IP addresses to make sure they're from the same region but the attacker can also do fancy stuff like detect where your IP is from and use a VPN to get an IP in the same area.

The foolproof way is to not send codes as a 2FA (be it mail, SMS or whatever). There is always a risk that the user fails to verify where they're putting that code. Instead use something that verifies the domain without relying on the user, e.g. U2F or passkeys.

In that case the user needs to be fooled to sent the physical device or passkey-app-backup to the attacker. This is much more suspicious and needs a much worse fool than someone entering a code after they already entered their user+password.

If you know that the user uses the same browser to open links sent via mail as they use for their login: For the 2FA step, set a cookie with some unique value on your login domain and sent the user a mail with a link. Opening the link only finishes the login and starts a valid session if that unique cookie is present. This makes it harder for an attacker, since they need to inject that cookie into the victims browser, which means they need to find an XSS-style exploit. Of course you then want to reduce the attack surface by putting the login function on a subdomain of its own.

And obviously this fails if the user is about to login e.g. on their personal computer and then tries to verify the session on their company phone. This can be good or bad, depending on the scenario.

TBF, I wish some companies would use even that basic code-by-whatever 2FA. I've seen cases which have like 5 different domains, all with various logins that customers and employees use. Want to phish them? Just register another domain that looks similar enough to the others and sent some mails. But then there are still services limiting the password length to something like 16, so I think we will still have plenty of work...

Passkeys are cool, but not widely deployed yet. Also, there's currently no way to express "give X identity Y access on Z server", unless X identity already has a passkey set up with the server. This is a non starter for decentralized networks with lots of federated and self-hosted servers. This use case is trivial with email.

Thanks - but this sounds like an email 2FA flow, not a magic link.

A magic link is a link a user clicks in their browser, that lands them on the appropriate service, where the one-time code is part of the URL. The service consumes the token and provides the user with a (first factor) authentication token.

In other words, the email doesn't display a code which they could go paste into the attacker's page. Though they may still need to perform a 2FA flow following the magic link flow (and this portion is still phishable!)

Your critique is definitely valid for most forms of 2FA (email, SMS, and TOTP.)

You are correct that this mitigates the security problems.

However, the method you're describing has fallen out of favor, in large part because mobile email apps often use a built-in browser that doesn't share cookies with the system browser. This creates several confusing UX problems. You also can't use a logged in device to log in a new device, unless you implement something like QR login which is also phishable.

Slack for example used to work the way you describe but now uses emailed codes for 1FA login.

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?

See response to sibling

Thank you - as sibling also mentioned, what you're describing in isn't a magic link but a standard TOTP/HOTP delivered via email which absolutely is phishable in the manner you described.

Magic link is a process where you enter your email address and the service sends you an email that contains a clickable hyperlink that contains a cryptographically strong, short-lived nonce in the URI that is used as a proof-of-possession factor (the email account) to authenticate users.

See third cousin

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?