CAcert Code Development list.

[Ian G <iang AT iang.org>]

Hi Michael,

this is out of scope of birdshack.  The use of OAuth is as an internal 
authentication protocol, not a random user thing.

Which is to say, the question of user authentication isn't really an 
issue in the design.  If we used OAuth to authenticate users to the 
system we'll put in place our own one provider, and run that securely.

iang


On 11/7/09 12:01, Michael Tänzer wrote:
> Ian G schrieb:
> > 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?
>
> Provide. I think the idea of OpenID namely not to have hundreds of
> different accounts for every little site e.g. forums etc. is a good one
> but it makes the the site _providing_ the authentication (and through
> that every site which relies on OpenID) more vulnerable to phishing attacks.
>
> > 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.
>
> In OAuth too there has to be a provider and a relying party although the
> main purpose is data access and not only authentication it's very
> similar to OpenID in how the user authenticates with the providing party.
> Although I have to say I haven't read the OAuth spec (just some third
> party articles about it) AFAIK it uses the same mechanism as OpenID i.e.
> it forwards the user to a login form of the provider and is therefore
> vulnerable to the kind of attacks described on the site I linked to.
>
>
> > > 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.
>
> Yes, it has all to do with actors but security design which doesn't take
> actors into account doesn't deserve it's name IMHO.
>
>
> > 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.
>
> There already are OpenID providers which allow you to use client certs
> to authenticate (and also allow CAcert certs). No problems with them,
> because you never give credentials away, although there might be some
> risks if the provider says "well your client cert failed here's the link
> to CAcert login there and get a new one" but that risk sounds somewhat
> moderate to me.
>
>
> > > 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.
>
> The problem with the attack is the same as the attack on MD5 hashed
> certs (http://www.win.tue.nl/hashclash/rogue-ca/): it not only affects
> those who do use MD5 hashed certs it also has a big impact on those who
> use secure hashes (by the way is there any chance that we're going to
> generate the new root keys any time this year, cause the class3 cert is
> signed using MD5) because the only possibility to prevent it is for the
> browsers completely disallow MD5 signatures, the attacked website has no
> way to fix this.
> As well for the OpenID attacks the provider has no way to prevent those
> except to stop providing OpenID as then the user might be alarmed when
> redirected directly to a login form.
>
> > 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.
>
> If our users get phished easily that's not only their problem it's ours
> too. We want to be a CA, we want others to rely on us (yes I know not
> third parties, but at least our members) so we have to ensure that the
> risk of phishing is at least not higher than on an average site
> otherwise we might as well just give anyone the possibility to get a
> cert with the name of any registered user.
>
> If the user details of say some Google or Yahoo account get phished they
> can simply blame the user "you should have been more careful when
> filling out those forms" the only possible harm I can see for them is
> spam being sent from their servers (and they probably have mechanisms to
> detect this) but for us the harm will be more severe because we might
> loose the only thing we have to offer: trust.
>
> I agree that we can't dedicate our whole design to _prevent_ phishing
> attacks but doing a design that actually makes phishing a lot easier is
> nothing I will support.
>
>
> Michael