CAcert Code Development list.

[Ian G <iang AT iang.org>]

On 10/7/09 18:31, Michael Tänzer wrote:
> Hi,
>
> I just read through some of the design documents for birdshack and
> although I think that separating the web front end from the core system
> is a good thing to make it more secure I don't think we should go as far
> as providing the API to the whole world (although it seems to be the
> trendy currently).
> The reason why I think so is that if we provide OpenID or OAuth some
> websites may actually use it and those website don't necessarily have to
> be good guys.

Do you mean, provide, or use?

As far as I understood the discussions, the intention is to provide or 
make available OpenID for others.  But not to use it.

With OAuth the intention is to use it.  I'm not sure whether it was to 
be provided.


> Normally that wouldn't be a problem as both protocols
> involve that the user is supposed redirected to our own site,
> authenticates there and we pass a token to the site he actually wanted
> to use, which in turn knows that the user has been properly
> authenticated/can access our data. As the user only enters his
> credentials at our site the bad site won't see them.
>
> That's how it's supposed to be – but what happens if the site doesn't
> redirect to us but instead presents it's own log in form which happens
> to look exactly the same as ours? You're right, you have a A+ phishing
> attack. Not only, that you don't have to send thousands of spam mails
> with strange links which after long years of user education (if such a
> thing exists) fewer and fewer people will click, even more sophisticated
> users will fall for the trick as the process is totally streamlined, no
> suspicious email, just the things you will have got used to in a OpenID
> authentication.
>
> Marco Slot has published some PoCs about OpenID phishing
> http://marcoslot.net/apps/openid/
> Well that is only OpenID but as OAuth works in a similar way I guess his
> approaches also apply. In a high security environment such as ours we
> probably don't want to try.


OK.  But is this anything to do with the protocol question?  It seems as 
though this all to do with the actors.

On this question of providing OpenID, the current default situation is 
that any CAcert member could do this.  In which case the CAcert member 
can be controlled via the normal methods.  There is some view that 
anyone could run an OpenID server, but that's not really supported (as 
yet, if ever) in the CAcert view.


> I think we still can use both systems to separate our core system from
> our front ends, but the core system should also authenticate the
> requesting front end and we should only allow systems controlled by us
> to use it. Other sites can still use client certificates for
> authentication of our users if they want to, but we should avoid users
> getting accustomed to a log in form to enter their CAcert credentials
> when visiting a third party site, if we only use it internally we
> probably stay on the same main domain, so the user won't even notice
> that there is OAuth involved.


My understanding is that we'll use OAuth to secure front end to server 
communications.  That will involve registration of pre-accepted keys. 
This will be a manual act, managed by the sysadms.  It won't be an 
automated, user-oriented process.

What happens to users our in the wilds of phishing land is beyond the 
scope of the design.  A concern, but a separate subject.  Use of OAuth 
internally does not imply any decision / intention to provide it externally.

At least that's my understanding.

iang