CAcert Code Development list.

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

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

Attachment: signature.asc
Description: OpenPGP digital signature