5 ms·

This. It's not unreasonable to flat-out require 2FA.

atmosx 11y ago
2-factor auth might be good for SendGrid but depending on another device (be it your phone or a token-device) sucks big time in the real world.
- jsmthrowaway 11y ago
  Your data growing legs also sucks big time in the real world.
  - troycarlson 11y ago
    Exactly. If I'm trusting a company with a core component of my business/livelihood (code repositories, email marketing campaigns, etc.), phrases like "it's a minor inconvenience" are unacceptable excuses for lax security.
- dublinben 11y ago
  Enterprises that are serious about security have been requiring their employees to use security tokens for years. It's not an unreasonable burden to maintain control over account access.
- toomuchtodo 11y ago
  Seriously? People can't be bothered to take the extra 45 seconds to open an Authenticator app and type in the current 6 digit code?
  - Karunamon 11y ago
    Seriously, because getting into the website is one thing, getting into anything that uses an API is something else altogether. Google and Github both require the use of app specific passwords if you have 2FA on. Which means that accessing anything that uses the API is no longer a matter of username+password+token, it means username+password+log into site+generate huge and ridiculous password that is only shown once+save that into the app. It's a pain in the ass. Massively.
    - toomuchtodo 11y ago
      > It's a pain in the ass. Massively. Compared to someone gaining access to your Gmail (and the rest of your Google platform services) account or Github access? Hardly. I agree its not perfect, but its relatively painless for the benefit obtained.
      - Karunamon 11y ago
        This is an argument that can apply to any particularly annoying security arrangement. What you miss is that by making the process so arduous, people will not use it. There's no reason I can't generate my own app passwords, nor is there a reason to prevent me from accessing my own passwords later.
        tracker1 11y ago
        I would just assume let the system generate one... usually it's as random/long as anything I would create and people in general create short/weak passwords... if the password requirements where 16+ characters, upper, lower, number and other characters that would piss people off too. In this case, if you didn't copy/paste it into your app/service... generate a new password, and revoke the old one. The only flaw here is when you aren't able to label your prior passwords and are only given the option to nuke them all. That ticks me off more than anything. I've got 2fa enabled most places that allow it now, and use Authy too. The only times it's been a real pita is when I've had to setup email on a new phone with a generated passphrase (I'm trying to stop using the "password"). Other than that has been one day where I forgot my phone at home and didn't go back to get it after I was in my car...

2-factor auth might be good for SendGrid but depending on another device (be it your phone or a token-device) sucks big time in the real world.

jsmthrowaway 11y ago
Your data growing legs also sucks big time in the real world.
- troycarlson 11y ago
  Exactly. If I'm trusting a company with a core component of my business/livelihood (code repositories, email marketing campaigns, etc.), phrases like "it's a minor inconvenience" are unacceptable excuses for lax security.
dublinben 11y ago
Enterprises that are serious about security have been requiring their employees to use security tokens for years. It's not an unreasonable burden to maintain control over account access.
toomuchtodo 11y ago
Seriously? People can't be bothered to take the extra 45 seconds to open an Authenticator app and type in the current 6 digit code?
- Karunamon 11y ago
  Seriously, because getting into the website is one thing, getting into anything that uses an API is something else altogether. Google and Github both require the use of app specific passwords if you have 2FA on. Which means that accessing anything that uses the API is no longer a matter of username+password+token, it means username+password+log into site+generate huge and ridiculous password that is only shown once+save that into the app. It's a pain in the ass. Massively.
  - toomuchtodo 11y ago
    > It's a pain in the ass. Massively. Compared to someone gaining access to your Gmail (and the rest of your Google platform services) account or Github access? Hardly. I agree its not perfect, but its relatively painless for the benefit obtained.
    - Karunamon 11y ago
      This is an argument that can apply to any particularly annoying security arrangement. What you miss is that by making the process so arduous, people will not use it. There's no reason I can't generate my own app passwords, nor is there a reason to prevent me from accessing my own passwords later.
      - tracker1 11y ago
        I would just assume let the system generate one... usually it's as random/long as anything I would create and people in general create short/weak passwords... if the password requirements where 16+ characters, upper, lower, number and other characters that would piss people off too. In this case, if you didn't copy/paste it into your app/service... generate a new password, and revoke the old one. The only flaw here is when you aren't able to label your prior passwords and are only given the option to nuke them all. That ticks me off more than anything. I've got 2fa enabled most places that allow it now, and use Authy too. The only times it's been a real pita is when I've had to setup email on a new phone with a generated passphrase (I'm trying to stop using the "password"). Other than that has been one day where I forgot my phone at home and didn't go back to get it after I was in my car...