CAcert Code Development list.

[Michael Tänzer <NEOatNHNG AT users.sourceforge.net>]

Hi Alejandro,

Alejandro Mery Pellegrini schrieb:
> when I was actively thinking in this, the idea was to have application
> accounts. all application were supposed to be bound to one or more
> assured members and an application would need explicit permissions to be
> used "publicly" (i.e. by other members beside those responsible for each
> app).
> 
> does this make sense to you for helping us against these problems?

Application accounts do make sense (e.g. we could whitelist some client
certs and only accept SSL connections from them) but that's not enough.

If I'm a user and are used to be redirected from a third party site to a
CAcert site to fill in my credentials because that's just how these
CAcert people do this (and they drive a CA so they know what they're
doing) then I won't be alarmed if I go to another third party site which
again presents me the CAcert login form (except that this time it's not
on the cacert.org domain, but most users won't notice), that's what
always happened so I'll just fill my email and password in.

So here's what has gone wrong:
- the user doesn't get a warning that the third party site he's
currently visiting has no application account i.e. is not trusted by us
(maybe except checking on our website which lists the ones that are
trusted, but no one will do that)
- the user expects to give his CAcert credentials to a third party site
(users do think this way (although not all of them), the CAcert login
belongs to the work flow on the third party site they don't differentiate)
- even if the user can differentiate he might have missed that this time
the form he filled in didn't come from cacert.org (the force of habit)
or Mallory might have put some effort in it so it really seems to come
from cacert.org. All phishing attacks to get the domain name right also
apply here (unicode domain names, javascript (although that shouldn't
work with any up to date browser), DNS poisoning (mind the Dan Kaminsky
attack)) and never underestimate social engineering.

How to avoid:
Don't give the user the feeling that it's usual to give his CAcert
credentials to a third party site. If then a third party site just gives
him a login form which seems to come from CAcert this won't meet his
expectations and there's a high(er) chance that he will not fill it in
(what would you do if some site suddenly presented you a login form of
say ebay, this wouldn't be quite what you expected to happen hopefully).

As I said in terms of separation of critical and uncritical systems it
can still make sense to use OAuth internally but the user must have the
feeling that he's always on the same site which can be archived by
making all apps subdomains of the cacert.org domain and give them the
same design. The big players like ebay, Amazon etc. also have divided
their systems into critical and uncritical (and more valuable to them
static and dynamic) systems but by making them subdomains and having the
same overall design users just regard them as one.


Additionally we should not only have application accounts but also
assign data access rights to them. For example the geo/social app should
only be able to access the primary email address in order to send
announcements, maybe the name (the user could also enter this separately
as e.g. he might want to omit middle names) and possibly the number of
experience points while the web frontend needs wider access to the data
(in order to let the user tweak preferences, request certs etc.).


Cheers,
Michael

Attachment: signature.asc
Description: OpenPGP digital signature