[ameliaquining]

This is silly. The authors establish that phishing is a serious problem (duh), and that this problem is caused by the absence of reliable authentication of messages (a worthwhile observation, albeit one that the industry is already aware of and doing its best to patch over), but they fail to establish that text-only email solves this problem in any meaningful way.

Text-only emails can and will still contain links, which users will still click on. Misleading domain names will work just as well in the email body as they do in the address bar. Even if (as this article seems to imply should be done) mail clients don't make the links clickable, users will still copy-paste them. (Not to mention that the usability benefits of making links clickable are significant enough that mail clients won't forgo them just for a speculative hypothetical security benefit.)

The authors seem to think that inserting a "speed bump" here will cause users to pay closer attention and not be fooled. This is not how humans work, especially very busy humans who get too much email and just want to get through it as quickly as possible.

Also, the reference to JavaScript in email leads me to question whether the authors have any idea what they're talking about. Mail clients don't execute JavaScript.

[astrobe_]

> but they fail to establish that text-only email solves this problem in any meaningful way

The quote from US-CERT isn't "meaningful"?

FWIW, I'm the first to bitch about security experts that sacrifice usability in the name of security any day, but for once I completely agree with them.

> Also, the reference to JavaScript in email leads me to question whether the authors have any idea what they're talking about. Mail clients don't execute JavaScript.

https://stackoverflow.com/questions/3054315/is-javascript-su...

And that's only until someone finds a way to make them execute Javascript anyway. I don't think it ever actually happened, but not using an HTML engine drastically reduces the attack surface for sure.

[userbinator]

Text-only emails can and will still contain links, which users will still click on. Misleading domain names will work just as well in the email body as they do in the address bar.

...that brings up the other elephant in the room: Unicode. More specifically, https://en.wikipedia.org/wiki/IDN_homograph_attack

The 0/O/i/1/l/I distinction is a classic one that can be somewhat mitigated by good font choice (plaintext emails are often presented in monospace, so that helps a little), but some of the other sets of Unicode characters are designed to look identical to ones in the ASCII range, often using the exact same glyphs.

For those who use non-English characters exclusively, it is not possible to use ASCII only emails, but non-Unicode encodings are still helpful in this situation --- e.g. the Cyrillic characters most known for IDN homograph attacks aren't even encodable in 8859-1 or Shift-JIS.

[cozzyd]

At least with plain-text, it's a slightly harder to forge links. (i.e. you have to do http://www.megabank.com.phishingattempt.io instead of <a href="http://www.phishingattempt.io"><img src="megabank.com/logo.png"></a> )

Speaking of JavaScript in e-mail, gmail doesn't allow you to send or receive .js files (even tarred up), which is somewhat inconvenient, and I'm not really sure what attack that prevents. Maybe there is a mail client out there that will happily execute attached js?

[lucaspiller]

I got a phising SMS today (please login to verify unusual account activity) with a link to mybank.online-eauth.co.uk. I knew from before even seeing that it was probably not legit, but I did check the domain whois as UK banks are rather arcane, and I wouldn't be surprised if they had a completely different domain for something like this. I know when I buy something online, my bank has a different domain for Verified by Visa.

[diggernet]

Also, I gather that non-text emails make it possible to disguise the link target when you hover over it to see where the link goes. Whether that is using css or js, I'm not sure.

[toast0]

On mobile, there's no hover, so HTML mail means I just have to guess if I think the link will go where it says or not.

[extra88]

In iOS Mail, you don't have to guess where the link goes, press and hold on a link will show the URL.

[proactivesvcs]

Considering how much email is checked on mobile I am surprised your point is not being mentioned more frequently.

[ameliaquining]

You can't falsify the browser indicators of link targets (status bar on desktop, modal dialog from holding down the link on mobile) without JavaScript.

You can create a misleading tooltip in HTML: <a href="https://www.megabank.com.phishingattempt.io" title="https://www.megabank.com">https://www.megabank.com</a>. But since modern browsers don't use tooltips to indicate link targets, users probably won't be looking there in the first place.

[ameliaquining]

The real URL will appear in the browser address bar anyway before the user gets the chance to disclose any information. I don't know exactly what proportion of users will notice a well-disguised phishing URL in the email body but not in the address bar, but I bet it's not that high.

The attack prevented is simply having the user open the attachment, allowing the sender to execute arbitrary JavaScript on their machine in the file:// context. (Modern browsers have made the security consequences of this somewhat less dire than they once were, but it's still not something you want to do if you can help it.)

[stan_rogers]

That involves the rather large and utterly baseless assumption that users look at the address bar at all. You probably do. Does your somewhat less-savvy next-door neighbour?

[userbinator]

This observation I made a while ago shows that a considerable number of "average users" used to, and even understood how URLs are formed:

https://news.ycombinator.com/item?id=7678729

If an increasing number of users aren't, then that is certainly a problem.

[ameliaquining]

They don't really look at the URL in the email body either, especially if it's long and intimidatingly technical-looking.

[hnlmorg]

> The real URL will appear in the browser address bar anyway before the user gets the chance to disclose any information

Which is already too late for anyone compromised by a drive-by download attack.

[ameliaquining]

The threat model here is phishing, not drive-by downloads. Browsers have a much greater ability to mitigate those. Also, a drive-by download email doesn't have to impersonate any particular sender, it just has to look like something that a user might want to click on.

[hnlmorg]

> The threat model here is phishing, not drive-by downloads.

I think you missed my point. What if it isn't a phishing attack? Or even, what if it isn't just a phishing attack?

Your suggestion leaves users vulnerable by encouraging them to open suspicious looking links on the off chance it is, at most, a phishing attack.

> Browsers have a much greater ability to mitigate those.

Except when they don't. For what it's worth, I've also seen mobiles fall victim to drive-by download attacks.

> Also, a drive-by download email doesn't have to impersonate any particular sender, it just has to look like something that a user might want to click on.

E-mail worms are spread by the trust relationship between people known to each other (ie a user opening an attachment because it's from a recipient they know). I don't see why drive-by download attacks couldn't exploit the same human condition (ie "Hey bob, check out this link. It's awesome").

In fact I have seen that kind of malware in the wild, now I think about it.

[ameliaquining]

I don't know what you mean by "encouraging". I am taking it as a given that users cannot be reliably prevented from clicking on links in emails. The security benefit of forcing the URL to be displayed before the click is extremely minimal.

[proactivesvcs]

A small, but not insignificant, proportion of malware and phishing emails I receive do not show any links at all in their plaintext part. Some of the links are probably easy to skim over and miss the fact they're suspect, but some really do look very dodgy indeed (coupled with very poor plaintext formatting), facts that I would expect a non-expert would notice in some cases. Certainly enough to make it worthwhile.

[mike-cardwell]

"Mail clients don't execute JavaScript."

Maybe not on purpose, but EmailPrivacyTester.com has found several clients in the past (usually webmail) which do.