taint.org: Justin Mason’s Weblog

There’s a common misconception about spam, email, and email authentication; Matt Cutts has been the most recent promulgator, asking ‘Where’s my authenticated email?’, in which various members of the comment thread consider this as an anti-spam question.

Here’s the thing — email these days is authenticated. If you send a mail from GMail, it’ll be authenticated using both SPF and DomainKeys. However, this alone will not help in the fight against spam.

Put simply — knowing that a mail was sent by ‘jm3485 at massiveisp.net’, is not much better than knowing that it was sent by IP address 192.122.3.45, unless you know that you can trust ‘jm3485 at massiveisp.net’, too. Spammers can (and do) authenticate themselves.

Authentication is just a step along the road to reputation and accreditation, as Eric Allman notes:

Reputation is a critical part of an overall anti-spam, anti-phishing system but is intentionally outside the purview of the DKIM base specification because how you do reputation is fundamentally orthogonal to how you do authentication.

Conceptually, once you have established an identity of an accountable entity associated with a message you can start to apply a new class of identity-based algorithms, notably reputation. … In the longer term reputation is likely to be based on community collaboration or third party accreditation.

As he says, in the long term, several vendors (such as Return Path and Habeas) are planning to act as accreditation bureaus and reputation databases, undoubtedly using these standards as a basis. Doubtless Spamhaus have similar plans, although they’ve not mentioned it.

But there’s no need to wait — in the short term, users of SpamAssassin and similar anti-spam systems can run their own personal accreditation list, by whitelisting frequent correspondents based on their DomainKeys/DKIM/SPF records, using whitelist_from_spf, whitelist_from_dkim, and whitelist_from_dk.

Hopefully more ISPs and companies will deploy outbound SPF, DK and DKIM as time goes on, making this easier. All three technologies are useful for this purpose (although I prefer DKIM, if pushed to it ;).

It’s worth noting that the upcoming SpamAssassin 3.2.0 can be set up to run these checks upfront, “short-circuiting” mail from known-good sources with valid SPF/DK/DKIM records, so that it isn’t put through the lengthy scanning process.

That’s not to say Matt doesn’t have a point, though. There are questions about deployment — why can’t I already run “apt-get install postfix-dkim-outbound-signer” to get all my outbound mail transparently signed using DKIM signatures? Why isn’t DKIM signing commonplace by now?

Tags: accreditation, anti-spam, authentication, dkim, domainkeys, email, habeas, reputation, return-path, smtp, spam, spamhaus, spf

So, Google have invented their own DRM, apparently. I’m keen to find out more details; Techdirt and Plasticbag.org are so far the only places I can find in the blogosphere to discuss it in any detail.

One tidbit worth noting from the LA Times coverage:

The Google copy-protection software also imposes a big restriction: The CBS shows, NBA games and other material protected by the software can be watched only on a computer that’s connected to the Internet.

“I think it’s going to be a problem,” said Li, the Forrester analyst, adding that Google executives told her they were trying to fix it.

That’s interesting. In my opinion, given that quote, I’ll bet Google’s DRM is something similar to the copy-protection systems used for many games since about id’s Quake 3 and Valve’s Half-Life; an online “key server” which validates codes, tracks player IDs, and who’s viewing what, “live”, as the video is cued up and played.

Some more info on the Half-Life WON authentication system can be found in this GamaSutra article; subscription required — try viewing this google-cache version with Javascript off if you don’t have a sub. That’s historical now, of course, since that WON system has been replaced by a new auth protocol as part of Valve’s ‘Steam’ system.

The key factor is the network, separating the dangerous, untrustworthy user machine from the trusted key server. Since the online key server can act as a platform for trusted, known-insubvertable code to run, along with the video server, both being under Google’s control, it’s actually possible to build reasonably solid DRM on this model. That’s as opposed to the usual case, where a reasonably determined teenager can break it in a week of school-nights. ;)

Anyway, that’s speculation. It remains to be seen if they’ve come up with something along the lines of WON authentication — and if it’s still easily subvertable or not.

Update: Aristotle Pagaltzis has a pretty good point in the comments:

Watching video, unlike playing a multiplayer game, is not an activity that inherently requires connecting to a server. Playing a multiplayer game, OTOH, inherently is.

So cracking a multiplayer game’s key check is fruitless, because then you can’t play online anymore, which was the whole point of the game in the first place. In contrast, a video player with a cracked key check still fulfills its purpose just fine.

I think he’s right. That’s a key point, demonstrating how WON authentication still can’t help — media playback, as a task, is itself fundamentally crackable.

Tags: authentication, dont-be-evil, drm, google, google-drm, half-life, tv, video, won

Web: a while back, I posted some musings about a web service to help authenticate users as members of a private group, similarly to how TypeKey authenticates users in general.

Well, Flickr have just posted this draft authentication API which does this very nicely — it now allows third-party web apps to authenticate against Flickr, TypeKey-style, and perform a limited subset of actions on the user’s behalf.

This means that using Flickr as a group authentication web service is now doable, as far as I can see…

Tags: api, authenticate, authentication, draft, flickr, general, group, service, typekey, web

Web: I’ve been doing a little thinking about group-based networking and services.

Here’s the situation. Let’s say you have a small group of people, and want to offer some kind of online service to them (like a private chat area, mailing list, etc. etc.) That’s all well and good, but maintainance of ‘who’s in the group’ is hard. You need:

• the ability to let other ‘admins’ add/remove people
• a nice UI for doing so
• a nice UI for people to request to sign up
• possibly, multiple groups
• privacy for group members
• possibly, some public groups
• decent authentication, username/password
• the usual stuff that goes with that — ‘I’ve forgotten my password, please email it to my listed address’
• did I mention a nice UI?

The traditional approach is to code all that up myself, in my copious free time presumably. Urgh, talk about wheel reinvention on a massive scale.

I’d prefer to use something like TypeKey, a web service that exposes an API I can use to offload all this hard work to. Initially, I was in the ‘ugh, Typekey 0wnz my auth data’ camp, but I’ve eventually realised that (a) they’re not quite as evil as MS, (b) they’re not quite as stupid as MS (deleting Passport accounts if you don’t log in to Hotmail, which is only one of the supposedly many services, including third party services? hello?!), and (c) it’s actually really convenient having a single-sign-on for weblog commenting after all.

Having said all that — TypeKey’s out. Unfortunately, it only does authentication, without dealing with group maintainance.

However, social networking services are all about groups and group maintainance.

Running through the options — LinkedIn, Friendster and Orkut are all grabby and gropy and ‘my data! mine!’, so they’re out immediately.

The next step was to take a look at Tribe.net, which seems kind of nice and had a good rep for open APIs — but as far as I can see, all they’ve got really in that department is FOAF output, and a simple server-side-include thing called TribeCast. I could list all the group members in a FOAF file, but without authentication, that’s pretty useless since anyone could claim to be one of the FOAFs.

That leaves Flickr, which has a great set of APIs. Using that is looking quite promising. If you’re curious, I’ve gone into detail on this at the taint.org wiki.

Tags: authentication, group, kind, maintainance, networking, password, service, situation, thinking, typekey, web

Spam: SMTP Sender Authentication, by David Jeske of Y! Groups (pointer from Jeremy.

Schemes similar to this — calling back to a sending server to verify that a mail was really sent via that host — have been proposed before in several venues, the most high-profile and public being the ASRG list. Here is a message I sent to that list in April 2003 discussing a few of those schemes:

• J C Lawrence’s ‘forward chained digital signatures’ on Received headers
• William at elan.net’s ‘complex callback verification requirying full message tracking server functionality with dns extensions’
• Russ Nelson’s Q249
• Our own ‘porkhash’

I still like this style of system, I think, but in terms of deployability and simplicity, I’m supporting Sender-Permitted From for now — which similarly forces senders to use registered relays for a given SPF-supporting domain, but using DNS as the protocol and IP addresses as the hard-to-forge identity component.

Another bonus of SPF is that it’s simple, easy to implement, has *running code* out there now, and is being pushed strongly by a pragmatic and sane driving person (in the form of Meng Weng Wong). It’s not always easy in the anti-spam field to find a solution like that ;)

BTW, SPF also, similarly, breaks envelope sender forging. However, I agree, this is one egg that has to be broken to help stop spam (or at least force spammers to use their own domains and IPs.)

Tags: authentication, list, mail, message, pointer, schemes, sender, server, smtp, spam, spf

SMTP Sender Authentication, by David Jeske of Y! Groups (pointer from Jeremy.

Schemes similar to this — calling back to a sending server to verify that a mail was really sent via that host — have been proposed before in several venues, the most high-profile and public being the ASRG list. Here is a message I sent to that list in April 2003 discussing a few of those schemes:

• J C Lawrence’s ‘forward chained digital signatures’ on Received headers
• William at elan.net’s ‘complex callback verification requirying full message tracking server functionality with dns extensions’
• Russ Nelson’s Q249
• Our own ‘porkhash’

I still like this style of system, I think, but in terms of deployability and simplicity, I’m supporting Sender-Permitted From for now — which similarly forces senders to use registered relays for a given SPF-supporting domain, but using DNS as the protocol and IP addresses as the hard-to-forge identity component.

Another bonus of SPF is that it’s simple, easy to implement, has *running code* out there now, and is being pushed strongly by a pragmatic and sane driving person (in the form of Meng Weng Wong). It’s not always easy in the anti-spam field to find a solution like that ;)

BTW, SPF also, similarly, breaks envelope sender forging. However, I agree, this is one egg that has to be broken to help stop spam (or at least force spammers to use their own domains and IPs.)

Tags: authentication, list, mail, message, pointer, schemes, sender, server, smtp, spf

Great report auditing the security features of the Diebold e-voting systems. Summary: what security?

• despite using relatively ’smart’ smartcards, they don’t actually get those cards to perform an authentication task; they’re just used as ‘dumb’ memory cards, and there’s no central online database of valid card IDs. Plus, the same write password is used for all smartcards.

  So they really might as well have used formatted floppy disks ;) Duplicating cards (a card is a voting opportunity, ‘vote early, vote often’) would be pretty easy, from the sounds of it.

• amazingly, the software does not record the ‘voter serial number’ that appears on the card, when a voter casts a vote. So again, duplicating the cards is trivial. Bizarre.

• all that is required to extract the PIN from an administrator card is a smartcard reader; the PIN is immediately sent in the clear as soon as the card is inserted and the terminal-card protocol initiates.

• for storage on the internal writable media, between voting and the final upload operation, the logs and votes are encrypted using single DES in CBC mode, with a single shared initialization vector. IMO this is not a big deal as far as I can see, as that’s only stored on the hardware; and if someone can read/write to that, they can subvert the WinCE OS anyway.

Then the kicker:

• the votes are then decrypted before being sent in the clear over a dialup internet connection.

The mind boggles.

Tags: authentication, card, diebold, pin, report, security, summary, vote, voter, voting