Hacker News Reader

Comment by londons_explore | Hacker News Reader

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)

View on HN

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

Which email clients support sending the input password as: pwd+top code?

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.

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.

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

all of them.

instead of sending your password as johndoe, you send johndoe123456 where 123456 is the code

Apple does this for older devices signing into iCloud!

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.

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.

But why are those more secure than other passwords? How can they know that this 1992 app is the app it claims to be?

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.

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?

Sure but Google doesn't know that, and app passwords are a way to functionally ensure no password reuse.

What do you mean by things like "*******"? Seven asterisks?

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.

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

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.

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.

App passwords are useless to Google as a tracking measure and are a much more secure option, especially across the entire user base.

>Nor do they allow any kind of anti-robot verification.

This is a feature.

Reply on news.ycombinator.com