[cap-talk] RE: [e-lang] Eyes on the goal: real phishing solutions

[marcs]

> The way I think of what petnames give you is protection 
> against spoofing. If phishing = spoofing + social engineering 
> + authentication token theft (+ maybe some more?), then 
> defending against spoofing is a real step. Does that sound 
> right to you?

Sounds very reasonable to me.

> 
> >-- Capabilities, Not Passwords: Phishing must somehow capture an 
> >authority to be a success. Put all the authorities in 
> capabilities. To 
> >exercise the authority in a capability, you do not send it over the 
> >line like a password.
> 
> Yes, I think of this as getting at the "authentication token 
> theft" part of the equation above.  Simply replacing all 
> passwords with private keys and self-signed SSL client certs 
> seems like it would go a long way (if only our browsers and 
> servers supported that).  One perceived barrier to this, 
> though, is the mobility problem.  I can use my password on 
> any machine; but if I establish a private key on one machine 
> and then try to log in from another machine, that won't work. 
>  I don't know whether this is truly a big deal, or if it is 
> just perceived as being a bigger deal than it truly is, but 
> it is one of the considerations here.

With capabilities, you represent each single cap as a separate file that you
stick on a thumb drive. If you need a particular capability from a
particular machine, you load the cap from the thumbdrive. 

In this simple a form, it would have the disadvantage that you have to trust
the machine which will be able to read all your caps. One could imagine more
clever thumbdrive designs that only expose files specified by the user when
plugged into another machine. At that point the thumbdrive would have
security properties similar to the security properties of typing passwords
on machine of limited trust -- most of the passwords we use have very
limited authority, and caps on a fancy thumbdrive would offer comparable
exposure.

> 
> Another thing to keep in mind is that even if we were to 
> eliminate all electronic passwords and replace them with 
> capabilities, we'd still have the problem of phishers 
> capturing SSNs, etc.  As hard as it is to eliminate password 
> authorities from the computer world, it is probably ten times 
> as hard to do so outside the computer world.

Yes...but I can't help wondering, if we ever started getting traction with
this stuff, whether people would start looking at it and saying, "this is so
easy to use while being so secure, it's cool. Why don't the government and
the bank use the same ideas?" Probably no amount of traction will get this
response, but one can hope :-)

> 
> >-- Make Lightweight Digital Cash a Core Filtering Element for Message
> >Acceptance: Having made phishing a much lower probability 
> game, now we 
> >make it cost significantly more every time it fails: if 
> strangers must 
> >send money to get past your filters, and it is etiquette to send the 
> >money back only if the message was valuable to you, people 
> who get hit 
> >by phish who recognize it will just keep the money.
> 
> I don't know about this one.  People have talked about ideas 
> like this for spam prevention, too.  One problem is that 
> mailing lists become nearly impossible to run (by amateurs) 
> under this model.  And then there is the practical problem of 
> getting lightweight digital cash (that we are all willing to 
> trust and use) deployed.

How easy things are to do in the presence of "postage stamps" depends
enormously on the nature of the user interface. I presume, when talking
about this, that the UI will make it falling-off-a-log easy for the user to
add senders to the white book of addresses from which mail is accepted
without money. In that case, mailing lists work pretty much the way they do
today...unless someone other than you adds you to a mailing list :-)

The wicked hard thing here is, as you point out, getting such cash deployed.
Before you can even think about deploying real cash on computers, you have
to fix the virus problem. So in fact the 3-part fantasy described above does
not become practical without the Fantasy Desktop, with a secure microkernel
and a POLA-enforcing desktop.

> 
> 
> These are ambitious ideas.  Deployment and acceptance of them 
> seems like an extraordinarily hard problem, given the current 
> state of things. But I think they are worth thinking about 
> nonetheless. 

I wrote this proposal specifically to address the question, "is there a goal
out there that constitutes a sufficiently comprehensive solution to be
worthwhile, that you can tell if particular small steps take you closer or
farther?" These ideas are wildly too ambitious to be taken on all in a
single lump. But it really improves your chances of getting to a particular
place, if you first ascertain the place's location :-)

--marcs