CAcert Code Development list.

[Sam Johnston <samj AT samj.net>]

And this is worse than the status quo how?

On Saturday, July 11, 2009, Michael Tänzer
<NEOatNHNG AT users.sourceforge.net>
 wrote:
> 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
>
>