From pedro@tastytronic.net Wed Jan 31 03:36:54 2007 Date: Wed, 31 Jan 2007 03:36:54 -0800 From: "Peter A. H. Peterson" To: Aleksandr Liber , Irina Litvin , Dan Jen Subject: [pedro@tastytronic.net: solicited commercial email standard] Message-ID: <20070131113654.GH8330@tastytronic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-pw: reindeer flotilla User-Agent: Mutt/1.5.11 Status: RO Content-Length: 4609 Lines: 108 Hey guys, here's my short writeup that I used to send to some of my friends. I'll probably talk to Reiher off of this tomorrow. Anti-phishing technique: So the idea is basically a Solicited Commercial Email Standard that makes it easy to distinguish between typical phishing attacks and genuine email. It doesn't require changes to the mail format protocol; it works on top of it. Key principles: 1. Solicited Commercial Email (SCE) must identify itself as such with a simple, standard phrase that would be the same for all SCE-compliant mail. Something like "This message is SCE compliant." This message could be an X-Header like: X-SCEmail: Version 1.0 Compliant 2. Email From: fields would not use "pretty names" like "Peter A. H. Peterson" -- they would just use the full email address: customer.service@lastbank.com. This ensures that a bogus address can't be hidden behind a friendly looking "real name". 3. ALL URLs included in the email message must be from the same domain as the email address in the From: field. This makes it vacuously simple to determine if potentially bogus URLs are in the email. Some banks have sites like mylastbank.com for user sites, but the customer service email address is customer.service@lastbank.com. This makes it confusing -- is it mylastbank.com or lastbankonline.com? I can't remember! But with uniformity comes simplicity. Surely bank network admins can make this work properly. 4. The domain name of the sender should appear in the subject line to make it readily visible to the reader that this is mail from his/her bank; something like this: Subject: lastbank.com: Please update your account information! These principles have some obvious outcomes: 1. Any email using the standard identification must be 100% compliant or the client (or server) will trash the message. Email messages that do not declare themselves as SCE compliant would be treated as potential spam. Any messages that mention "account" or anything similar but do not comply are obviously phishing attempts and can be quarrantined. 2. Corporate administrators will have to make sure that their web domains line up with the From addresses in their customer service email. This is a small price to pay compared to what phishing costs annually. 3. If companies want to reference things on other sites, they can create forwarding pages on servers they own. This serves to vett the URLs by putting them on servers the company must control. 4. Typical phishing redirection URLs will not work; phishers would actually have to take over the domains in order to phish this way. 5. This method requires no central whitelist or blacklist of known good/bad sites. It also allows even the smallest business or local bank to send compliant mail without having to get certificates or register with a central database. Some unintended consequences? 1. I DO forsee an unfortunate rise in the registration of things like myla5tbank.com, but these sites a.) should probably be registered by the company in the first place, and b.) should be prosecuted legally if they are serving malicious web pages. 2. How will this affect personal email sent between friends that reference URLs not in line with the sender's domain, such as youtube.com urls and the like? (I think the answer here is that it won't; the SCE filters will be applied to messages that say they are SCE compliant and messages that look like they should be. Otherwise general anti-spam filters apply.) 3. When is the SCE filter applied and when is it not? 4. These ideas may not be significantly different from filters already in use, but I think the difference is the current lack of standardization -- it is trivial to identify a phishing email if you look at the URLs in a text browser -- but this "sure fire test" is not available for most users because there is no quick way to programmatically check an email, and they typically don't see the URLs because they are buried under HTML (which is why they work). Because there is no claim of a standard, there is no way to reliably apply these techniques without catching some legitimate mail -- but having a standard is a small price to pay for the companies and a large price to pay for the phishers. What do you guys think about this? Is there any merit to this idea? Have they not tried this for some reason? Peter -- Peter A. H. Peterson, technician and musician. ---=[ http://tastytronic.net/~pedro/ ]=--- ----- End forwarded message ----- -- Peter A. H. Peterson, technician and musician. ---=[ http://tastytronic.net/~pedro/ ]=---