5 ms·

It's because IMAP, SMTP and POP allow substantial access to your google account and life, yet none have the ability to do 2 factor. Nor do they allow any kind

It's because IMAP, SMTP and POP allow substantial access to your google account and life, yet none have the ability to do 2 factor. Nor do they allow any kind of anti-robot verification. That means it's super easy to do credential stuffing attacks, and at google-scale, that sort of attack is going to let an attacker ruin a lot of lives. This is a good thing, and they should have done it years ago (they kinda did by defaulting IMAP/POP/SMTP access to off - that protects most users - this is just for the rest)

TacticalCoder 3y ago
I take it if someone really still want to fetch all his emails the old way, he could configure GMail to forward every single email to another address (not a GMail one): one still allowing IMAP/POP. Not a panacea but it may be an acceptable workaround for some usecases.
- londons_explore 3y ago
  You can still use app-specific passwords, so your 1992 mail client will still work... Although sending even an app-specific password in cleartext over the internet seems like a bad plan.
  - mcv 3y ago
    But why are those more secure than other passwords? How can they know that this 1992 app is the app it claims to be?
    - londons_explore 3y ago
      Because for the user account, people use things like "hunter2". But app specific passwords are long random strings unlikely to be reused by the user for another site.
      - mcv 3y ago
        My Gmail password is also long and not reused anywhere. My impression was that it's the app itself that Google doesn't trust, in which case, why trust it with that app-specific password? Can the app-specific password still get leaked and reused if the app is compromised?
        joshuamorton 3y ago
        Sure but Google doesn't know that, and app passwords are a way to functionally ensure no password reuse.
      - MikusR 3y ago
        What do you mean by things like "*******"? Seven asterisks?
  - pmontra 3y ago
    I use Thunderbird which already had a release this year. It's been using encryption since forever. Luckily I don't use GMail for my mail.
jojobas 3y ago
It's because old school passwords allow reasonable security, yet don't allow planting a user-identifiable cookie on the client machine.
- jonathanstrange 3y ago
  You shouldn't have been voted down. I've been using IMAP, SMTP, and Pop3 for the past 30 years without a single security incident. Meanwhile, I've had many accidental lockout problems and even had to abandon accounts because of 2-factor authentication and other paranoid security measures like arbitrary "device identification" algorithms. I swear to God the goal of this security theater is only to force customers into web-based logins so contents of emails and user behavior can be tracked in an Orwellian fashion.
  - Dylan16807 3y ago
    They said just identifiable though, and passwords are definitely user identifyable. And most users only have a couple devices so tracking that once you already know the user is usually very easy even without a cookie.
- minitech 3y ago
  App passwords are useless to Google as a tracking measure and are a much more secure option, especially across the entire user base.
gsich 3y ago
>Nor do they allow any kind of anti-robot verification. This is a feature.
gtech1 3y ago
It's trivial to add 2fa to smtp/pop/imap. Take your preferred auth module in Dovecot and modify it to read the input password as: pwd+otp code. If the user is 2fa enabled, read last 6 digits and compare against totp. If match, allow the IP through for x minutes or whatever other policy you want. It works surprisingly well
- 1000thVisitor 3y ago
  Which email clients support sending the input password as: pwd+top code?
  - 8organicbits 3y ago
    It's transparent to the client, so if the server adds support, every client gains 2FA support. The server needs to check if 2FA is enabled, and if so, try the last 6 characters of the user provided text as the OTP and the rest as the password. It's a pretty commonly used, and works very well, but requires user education on how to fill in their combined password. A proper API with distinct fields for password and OTP is cleaner, but requires protocol support.
    - oever 3y ago
      Isn't that horrible UI-wise? The UI will ask for password and show '******'. The user then has to remove the last 6 stars and put in the OTP. A dedicated question for the OTP would be much better. Also, the password manager would know to not save the password+OTP every time as a new password.
      - 8organicbits 3y ago
        > horrible UI-wise It is, but think of why you'd build this. You own the backend and need to add 2FA support. The various client software isn't written by you so you can't change them. This approach allows the client software to add an OTP field (concat the fields for the user) but doesn't require it (user must concat OTP on password manually). Many of the places I've seen this used don't integrate well with software password managers. OS login screen, console apps, etc; typically not web apps. But this is a good criticism.
deleted 3y ago
[deleted]

TacticalCoder 3y ago

I take it if someone really still want to fetch all his emails the old way, he could configure GMail to forward every single email to another address (not a GMail one): one still allowing IMAP/POP. Not a panacea but it may be an acceptable workaround for some usecases.

londons_explore 3y ago
You can still use app-specific passwords, so your 1992 mail client will still work... Although sending even an app-specific password in cleartext over the internet seems like a bad plan.
- mcv 3y ago
  But why are those more secure than other passwords? How can they know that this 1992 app is the app it claims to be?
  - londons_explore 3y ago
    Because for the user account, people use things like "hunter2". But app specific passwords are long random strings unlikely to be reused by the user for another site.
    - mcv 3y ago
      My Gmail password is also long and not reused anywhere. My impression was that it's the app itself that Google doesn't trust, in which case, why trust it with that app-specific password? Can the app-specific password still get leaked and reused if the app is compromised?
      - joshuamorton 3y ago
        Sure but Google doesn't know that, and app passwords are a way to functionally ensure no password reuse.
    - MikusR 3y ago
      What do you mean by things like "*******"? Seven asterisks?
- pmontra 3y ago
  I use Thunderbird which already had a release this year. It's been using encryption since forever. Luckily I don't use GMail for my mail.

jojobas 3y ago

It's because old school passwords allow reasonable security, yet don't allow planting a user-identifiable cookie on the client machine.

jonathanstrange 3y ago
You shouldn't have been voted down. I've been using IMAP, SMTP, and Pop3 for the past 30 years without a single security incident. Meanwhile, I've had many accidental lockout problems and even had to abandon accounts because of 2-factor authentication and other paranoid security measures like arbitrary "device identification" algorithms. I swear to God the goal of this security theater is only to force customers into web-based logins so contents of emails and user behavior can be tracked in an Orwellian fashion.
- Dylan16807 3y ago
  They said just identifiable though, and passwords are definitely user identifyable. And most users only have a couple devices so tracking that once you already know the user is usually very easy even without a cookie.
minitech 3y ago
App passwords are useless to Google as a tracking measure and are a much more secure option, especially across the entire user base.

gsich 3y ago

>Nor do they allow any kind of anti-robot verification. This is a feature.

gtech1 3y ago

It's trivial to add 2fa to smtp/pop/imap. Take your preferred auth module in Dovecot and modify it to read the input password as: pwd+otp code. If the user is 2fa enabled, read last 6 digits and compare against totp. If match, allow the IP through for x minutes or whatever other policy you want. It works surprisingly well

1000thVisitor 3y ago
Which email clients support sending the input password as: pwd+top code?
- 8organicbits 3y ago
  It's transparent to the client, so if the server adds support, every client gains 2FA support. The server needs to check if 2FA is enabled, and if so, try the last 6 characters of the user provided text as the OTP and the rest as the password. It's a pretty commonly used, and works very well, but requires user education on how to fill in their combined password. A proper API with distinct fields for password and OTP is cleaner, but requires protocol support.
  - oever 3y ago
    Isn't that horrible UI-wise? The UI will ask for password and show '******'. The user then has to remove the last 6 stars and put in the OTP. A dedicated question for the OTP would be much better. Also, the password manager would know to not save the password+OTP every time as a new password.
    - 8organicbits 3y ago
      > horrible UI-wise It is, but think of why you'd build this. You own the backend and need to add 2FA support. The various client software isn't written by you so you can't change them. This approach allows the client software to add an OTP field (concat the fields for the user) but doesn't require it (user must concat OTP on password manually). Many of the places I've seen this used don't integrate well with software password managers. OS login screen, console apps, etc; typically not web apps. But this is a good criticism.

deleted 3y ago

[deleted]