5 ms·

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

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

paxys 3y ago
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.
- klodolph 3y ago
  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”.
- SergeAx 3y ago
  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.
  - layer8 3y ago
    If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.
    - SergeAx 3y ago
      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.
      - faeriechangling 3y ago
        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.
      - layer8 3y ago
        Employee records as wiki pages? That must be a joke, right?
        SergeAx 3y ago
        Why not? If your company has lots of employees, like tens of them, you may create a nice template for those pages.
        IlliOnato 3y ago
        Why not on a piece of paper then?..
        SergeAx 3y ago
        It's hard to share and update.
        layer8 3y ago
        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?
- tehbeard 3y ago
  > 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.
malfist 3y ago
> Unless you're sending a verification email for every sign-in... Isn't that your typical 2FA flow?
andygeorge 3y ago
> 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.
- tinodb 3y ago
  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…
- apitman 3y ago
  > "Magic link" email + TOTP is pretty slick. Agreed. But unfortunately it's also highly phishable.
  - radlad 3y ago
    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.
    - apitman 3y ago
      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.

paxys 3y ago

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.

klodolph 3y ago
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”.
SergeAx 3y ago
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.
- layer8 3y ago
  If a company has no directory of their employees, associated company email addresses, and employment status, they likely have much worse problems.
  - SergeAx 3y ago
    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.
    - faeriechangling 3y ago
      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.
    - layer8 3y ago
      Employee records as wiki pages? That must be a joke, right?
      - SergeAx 3y ago
        Why not? If your company has lots of employees, like tens of them, you may create a nice template for those pages.
        IlliOnato 3y ago
        Why not on a piece of paper then?..
        SergeAx 3y ago
        It's hard to share and update.
        layer8 3y ago
        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?
tehbeard 3y ago
> 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.

malfist 3y ago

> Unless you're sending a verification email for every sign-in... Isn't that your typical 2FA flow?

andygeorge 3y ago

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

tinodb 3y ago
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…
apitman 3y ago
> "Magic link" email + TOTP is pretty slick. Agreed. But unfortunately it's also highly phishable.
- radlad 3y ago
  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.
  - apitman 3y ago
    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.