This was particularly effective because the app was registered as "Google Docs" - to not even filter names of your own products out seems ripe picking for imposter apps.

Nah... they can just say "Free unsubscribe service" or "Free <whatever>". And people will click like crazy. And you can make actually make VC fundable business using that technique.

Was it actually called "Google Docs", or was it a homograph?

https://en.wikipedia.org/wiki/IDN_homograph_attack

I've seen this point and agree with it, but I really have to wonder: if the app was just called "Documents" or "My Docs" and had a professional-looking icon, would a significant number of people really have given it a second look anyway?

I'm fairly certain a large number of users would still click allow without a second glance, much like hitting "allow macros" in an office document. They just want the annoying dialog to go away.

It was "Google Docs"

I understand that - my question is whether the name is actually a factor that contributed to the spread. As AfroThundr said above, people just want to get to their content and want the dialog to go away. A known contact sends you a document - you're going to trust that and want to see the document. Unless it said the app name was "I'm going to hack your bank account" they'll probably click it (and even then, some would go for it anyway.)

The message was "Google Docs would like to 'Read, send, delete, and mange your email'".

People are way more likely to accept that than if the dialog had been "[email protected] would like to 'Read, send, delete, and mange your email'".

Trends are moving away from displaying full URLs as well, and while it may look cleaner, I never asked for information to be hidden from me.

Unicode domain names, Google OAuth phishing...changing my passwords every 30 days is looking less and less important.

It's sad we can't seem to provide good, usable secure software.

> changing my passwords every 30 days is looking less and less important.

Sidenote: I don't think that was ever a good idea, unless you think you were likely to type your password into phishing sites in the last month.

Sadly, PCI compliance requirements believe otherwise :(

The PCI requirement is to change passwords every 90 days.

And is patently silly, forcing the requirement to decrypt rarely used private keys every 90 days.

The requirement should depend on password and hash strength, not some arbitrary decision.

PCI does not recommend employing password entropy checkers either.

90 day password can be weak while passing all the requirements.

Everywhere I've worked appears to have their own way of circumventing the security of PCI requirements. On a military base I worked everyone used an easily recognizable pattern on the keyboard. Another place was something like [employer][symbol][123 or 321]. All too often people use the same pattern that the IT team uses when they reset your password. So if the IT team typically sets your password to WhyCombin@tor1, then everyone's going to cycle through 1-10.

Making people reset their password every 90 days probably causes more problems than it solves and incentivizes more easily guessable passwords.

PCI in general is patently silly.

The problem, it seems, is that we are increasing the complexity of the "Secure Software" in an attempt to thwart the most sophisticated attacks.

However, as many people are already thinking, Complexity reduces Security and Stability. Therefore, it seems that the more we try to fight the "hackers", the more likely we will add some insecurity which they can exploit.

Complexity doesn't reduce security.

Complexity can both improve and reduce security depending on specifics, and thus generalizes to "no correlation" demonstrating that generalizations are often misleading.

Your claim that it generalises to "no correlation" is not supported by your assumptions.

Uh, begging pardon, but what are my assumptions again?

> changing my passwords every 30 days is looking less and less important.

Using some non-English Unicode text as password will make the password really strong. I sometimes include Malayalam text for passwords as it's my native language.

Then oauth based attacks like this come along and your password (however strong it may be) and two-factor auth are bypassed completely... It's interesting Apple can scale personally vetting apps for the app store but Google apparently can't be bothered to do the same for apps that could actually ruin businesses and lives with the data they could scoop up

It is not quite a virus, it works more akin to a trojan and exploits people not thinking about what they're clicking.

In 10s, why would Google docs ask for an oAuth prompt with big permissions?

People click through security dialogs, it is a known fact.

Funny that you'd ask that, as when developing Google Script automation scripts, Google Docs asks for exactly that.

(Of course, this is a different situation and all, and there is a lot of sense in your comment that mine doesn't at all invalidate.)

Or made up Malayalam words such as Melcow!

cs91PvMVtET37V%eKEMut0LI^kQYp3e&jSuCGl!9Lp

Lastpass.

All I see are asterisks, weird.

Bravo. Masterclass username for this comment. I'm dying.

(For those who may have missed it in this HN crowd, let me momentarily invoke a veil of joke-explainer and offer this http://knowyourmeme.com/memes/hunter2 of the joke.)

Haha, I've been around for a while but that one I missed. Awesome.

HackerNews: Where the subtlety of a comment's humor is inversely proportional to the size of the cognitive DDOS it initiates.

Oh. I just grabbed what would have been my next random 42 character password, hoping that would be sufficient to prove the point that (almost) ridiculously long one time use passwords is the way to go.

Appropriate username indeed!

Passwords for authentication was just always a flawed idea, typing them into the DOM and sending them over the wire even more so.

I agree. However I have yet to see a better alternative. Are there any out there?

Absolutely! My favorite is usually referred to as passwordless authentication, and generally means that when a user gives you their email address/SMS/etc, you send a login link to their device.

Here's an article: https://medium.com/@ninjudd/passwords-are-obsolete-9ed56d483...

Most people today authenticate their email account by typing their password into the DOM and sending it over the wire. It puts a ton of pressure on email providers to be secure. I consider my email password the absolute most important piece of information I have.

So although I do agree with you (and have created sites in the past that do passwordless login), the general password problem doesn't really get solved with this approach.

How about two-provider authentication? (2PA?) Send codes/links to two confirmed but independent accounts (email + Twitter, or Facebook + SMS) and require those to be entered.

Probably not anymore secure--and a nightmare to manage. But look to consensus algorithms for authentication ideas.

Phone is a (slightly) harder target, but Twitter + email is equivalent to just email.

I am not saying that any of this is practical for 99.99% of email users. In fact, I would venture to say the opposite - my suggestions are practical for less than 10 in 100,000 users. With that caveat, there are a variety of ways to make email more secure.

Every Unix system has a mail daemon as a core function. If you've ever seen "This incident will be reported." because your user is not in the sudoers group, the incident gets reported via the local mail system. Mail servers today (outside of Microsoft's Exchange servers) are still overwhelmingly Unix-like systems. A mail user just needs a Unix host, a username and ssh + mutt/pine to access their mail in this way. Then an attacker needs to identify the unix host, the username and the ssh credentials. The first two bits are likely to be trivial - the Unix host is probably published in DNS MX records, and the username is probably the local part of the email address. The last part does not necessarily need to be a password. Good security practices will have it be an ssh keypair. ssh keypairs are provably computationally secure (until quantum computing comes along) and ssh private keys often also have passphrases. Other measures - like U2F security keys - can also be required as part of ssh authentication.

So this is probably the gold standard when it comes to security for an email inbox. Is there any way we can make this more usable so that a GUI mail client can be used? One answer is to run the mail client on the Unix host and use ssh X forwarding to display it on the client machine. Another answer is to run a POP or IMAP server on the Unix host, force TLS and use normal plaintext passwords over the TLS tunnel.

Both the ssh and the IMAPS solutions require some way to authenticate the server side of the connection. The ssh mechanism typically defaults to trust on first use, but since one is publishing DNS records anyways, a SSHFP (ssh fingerprint) record seems like a good additional step. The IMAPS solution requires re-authentication of the certificate for each session. I am not sure what the current state of the art is for this for IMAPS servers. I personally believe that the CA model used for HTTPS is severely flawed.

All of this to say that for the truly dedicated user of a certain minimum (but high!) level of technical sophistication, passwordless login everywhere is possible (ssh keys; or having the email client securely store the password for use with IMAPS).

I really like that approach, but it's just shifting where a password is required, not eliminating it.

Basic auth doesn't use the DOM.

A technical alternative, yes, something like SRP. A usable alternative that is actually universally supported, well, no not really.

Did they ever solve the privacy issues with browser client certificates?

TLS 1.3 may solve some things. It depends what you lean by "the privacy issues"...

I'm not an expert or even particularly up to date, but I heard that other websites could see the client certificates installed. So a third party website might recognise the client certificate and know things about the user.

When you change your Google password, all OAuth tokens are revoked. The next time you use an OAuth connected App you will have to authorize it again, hopefully not making the same mistake twice.

We can, just need to take responsability serious like in other fields.

Software bugs should be no less than product defects, with possible fines in place.

To be clear, I'm not criticizing Google. Just presenting an interesting piece of information that shows the approach they've taken on this type of phishing attack in the past.

Phishing is a hard problem, and any technical solution will only go so far. The main criticism I have with many OAuth authorization dialogs, not just Google's, is that they often don't show enough information for technical users to vet the authenticity of the app. It's like if a web browser didn't show the address bar.

This is the most valuable comment here.