New hijacking - Done via via good old-fashioned Identity Theft
Joe Greco
jgreco at ns.sol.net
Fri Oct 8 13:00:30 UTC 2010
> On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote:
> > you just give contacts for the passwords with which you have received
> > a new one.
>
> Hi Sven/others,
>
> This very much sounds like TMDA:
>
> http://tmda.net/
> http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent
>
> Where by each person that needs to contact you, you give a unique e-mail
> address.
>
> So you give out key1 at domain.tld to user1 and key2 at domain.tld to user2.
That's a good start, but for general use, if I'm handing out an
address like "sven at jgreco.net" to Sven, and "leen at jgreco.net" to Leen,
the real problem here is predictability. If Sven is a bad guy, he
can cause trouble by guessing that I'd use "leen at jgreco.net" for Leen
and proceed to pass that address out to spammers, making Leen look like
a bad guy.
That particular problem is reduced by generating random tokens for the
LHS, however, doing so introduces new problems, such as the fact that
"23ycs7ia877oij at jgreco.net" is no longer obviously associated with Sven.
I've been very successfully using a much better tagging system here.
Take a user-specified identifier, such as, say, "sven".
You run this through a one-way crypto function, such as MD5:
md5=`echo "${1}/SomeMagicSecret" | md5`
f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"`
echo "${1}@${f8}.demo.jgreco.net"
This results in something like
nanog at e6ecd2ea.demo.jgreco.net
Now this has a bunch of interesting properties.
1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to
your actual mailbox address.
If and when a problematic address is issued, you can add at the DNS
level an MX (or whatever nasty you prefer) for the particular domain
name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net
to NS from 127.0.0.1. Never even touches the mail server. Of course
MTA or procmail deny works too.
2) By using a separate zone, it makes it trivial to configure your mail
system so that these addresses blow completely by any normal spam
filtering; the problem of false positives for things like transactional
e-mail that spam filters often find "spammy" vanishes completely.
3) You need not keep a database of valid tokens; you can simply re-validate
the LHS in Procmail. This means that you can do things like write a
mobile app or web app that doesn't have to have access to your mail
server's innards. The primary downside is that you need some way to
compute the crypto-signed bit.
4) You can keep a database of issued tokens along with when and why they
were issued.
5) If you make it a habit of using a LHS that's descriptive, it's hard
for a sender to argue that the tag was not assigned to them. It's
particularly entertaining for things like e-pending because it will
reveal which companies you will no longer choose to do business with.
This turns out to be very powerful and very flexible. It can be extended
to include functionality such as single-use addresses or limited-age
addresses, etc. The big trick is to leverage the e-mail address field
itself rather than trying to add a password or something like that in the
body.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
More information about the NANOG
mailing list