4 ms·

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 mess

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.

cozzyd 9y ago
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 http://www.megabank.com.phishingattempt.io instead of <a href="http://www.phishingattempt.io"><img 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?
- ameliaquining 9y ago
  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 9y ago
    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 9y ago
      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 https://news.ycombinator.com/item?id=7678729 If an increasing number of users aren't, then that is certainly a problem.
    - ameliaquining 9y ago
      They don't really look at the URL in the email body either, especially if it's long and intimidatingly technical-looking.
  - hnlmorg 9y ago
    > 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 9y ago
      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 9y ago
        > 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.
- diggernet 9y ago
  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 9y ago
    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.
    - proactivesvcs 9y ago
      Considering how much email is checked on mobile I am surprised your point is not being mentioned more frequently.
    - extra88 9y ago
      In iOS Mail, you don't have to guess where the link goes, press and hold on a link will show the URL.
  - ameliaquining 9y ago
    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" https://www.megabank.com.phishingattempt.io" title="https://www.megabank.com">https://www.megabank.com</a> 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.
- lucaspiller 9y ago
  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.
astrobe_ 9y ago
> 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-supported-in-an-email-message 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 9y ago
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 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.
proactivesvcs 9y ago
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 9y ago
"Mail clients don't execute JavaScript." Maybe not on purpose, but EmailPrivacyTester.com has found several clients in the past (usually webmail) which do.

cozzyd 9y ago

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 http://www.megabank.com.phishingattempt.io instead of <a href="http://www.phishingattempt.io"><img 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?

ameliaquining 9y ago
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 9y ago
  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 9y ago
    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 https://news.ycombinator.com/item?id=7678729 If an increasing number of users aren't, then that is certainly a problem.
  - ameliaquining 9y ago
    They don't really look at the URL in the email body either, especially if it's long and intimidatingly technical-looking.
- hnlmorg 9y ago
  > 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 9y ago
    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 9y ago
      > 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.
diggernet 9y ago
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 9y ago
  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.
  - proactivesvcs 9y ago
    Considering how much email is checked on mobile I am surprised your point is not being mentioned more frequently.
  - extra88 9y ago
    In iOS Mail, you don't have to guess where the link goes, press and hold on a link will show the URL.
- ameliaquining 9y ago
  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" https://www.megabank.com.phishingattempt.io" title="https://www.megabank.com">https://www.megabank.com</a> 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.
lucaspiller 9y ago
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.

astrobe_ 9y ago

> 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-supported-in-an-email-message 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 9y ago

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

proactivesvcs 9y ago

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 9y ago

"Mail clients don't execute JavaScript." Maybe not on purpose, but EmailPrivacyTester.com has found several clients in the past (usually webmail) which do.