[foaf-protocols] local password - was WebID pre-alpha specification (uses RDFa)

[Bruno Harbulot]

On 17/07/2010 05:08, Henry Story wrote:
> On 16 Jul 2010, at 23:50, Bruno Harbulot wrote:
>>
>>
>> On 16/07/2010 23:23, Henry Story wrote:
>>>>> Finally it is clear that WebID is more secure than OpenID, as far as authentication goes, due to:
>>>>>
>>>>>    - the simplification of the protocol
>>>>
>>>> Simplification made at the expense of having to deal with certificates.
>>>
>>> You are switching theme here. We were speaking security, and now you are speaking user friendliness, which itself could be improved.
>>>
>>>> That doesn't improve the security that much, since once again, the
>>>> weakest link in the chain is still the same (the WebID itself, like the
>>>> OpenID, is the entry point for whatever information is gathered afterwards).
>>>
>>> Yes, it is not at that level that WebID is more secure. It is the
>>> fact that we only need one such service. OpenID needs the OpenId provider too- which could be broken into - and the extra verification between the Relyng party and the Identity Provider to verify the cookie. It is quite easy to see the difference in this schema
>>>
>>> http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram
>>
>> You've missed the point that the security problem with OpenID isn't nearly as much the redirections, but the fact that the URI itself tells you what you need to go through to trust it.
>
> We are here working out the security differences between the two protocols! Both have a relation between a URI - called an OpenID in one case and a WebID in the other - and a representation returned by that URI. So at that level there is no difference!

Exactly, no difference here.

> The difference comes from the extra complexity of the OpenId protocol. At that level there IS a difference, and it favors WebID. This is pretty simple.

Saying that having fewer steps improves the security isn't that simple.
WebID may indeed be more secure in some circumstances than OpenID, but 
what I'm really against is making that sort of statements without 
elaborating on the possible threats, including what are the best/worst 
possible configurations with both protocols.
In particular, some forms of phishing in OpenID could be solved by using 
certificate based provider (there are some, the WebID-OpenID bridge is 
one of them).

Perhaps the report from this project would be a good starting point for 
this analysis:
http://www.jisc.ac.uk/whatwedo/programmes/einfrastructure/reviewofopenid.aspx


The main point I was focusing on was the issue of trust infrastructure, 
from the point of view of the resource provider.
While WebID via simple dereferencing allows you to build a trust 
infrastructure between WebIDs (something that's helpful to make adequate 
authorization decisions), it lacks the trust infrastructure in the 
authentication mechanism itself: this would require your social network 
not only to assert it knows you, but also confirm the value of your 
public key.
Making sensitive decisions based on the former without relying on the 
latter can be quite dangerous. Resource providers should not assume that 
simply because they've managed to obtained a lot of information 
regarding the user's WebID from trusted sources (which would grant them 
sufficient permissions to access the resource), it is sufficient to 
grant them access. The tricky cases are about checking the identity of 
the user first, for that, they also need confirmation of the user's 
public key from trusted sources.

Again, I fully agree that WebID is an improvement in that domain, we 
just need to be clear on the difference w.r.t. what is trusted.


> The fact that I get a representation back from a secure server is
> clearly quite an acceptable risk, since OpenID allows it, and since
> most of e-commerce is based on that: You go to an SSL web page all
> the time in online shopping and you fill out a form there. If that
> server had been hacked in, you would be giving your credit card info,
> payment info, personal details to some rogue site!

Exactly, no difference here.


>> The redirections make the problem only slightly worse, since the
>> real problem is where those redirections come from.
>
> And indeed. In OpenId there is the problem that the user may mistype
> his OpenId and be redirected somewhere else!

Sorry, I'm not really buying the "typo attack". Possible, but low risk 
in my opinion.


>>>>> - no password being typed (for public terminals that is an
>>>>> issue)
>>>>
>>>> You'll somehow have to type a password in your WebID provider's
>>>> password to be able to re-generate a new certificate in your
>>>> account (like what you do with XWiki), so you're back to the
>>>> same problem.
>
> But you don't have to type any password for all the situations where
> you are not using a public terminal. And you don't have to type an
> ID. Or: the password does not go over the internet!
>
> So your argument below is restricted to the unusual case of public
> terminals which are anyway huge security loopholes.

The point here is that a large number of users stay logged on on their 
Google account (for example), so they don't need to re-type their 
password either. In most cases, that doesn't change much.


>>>>> That is all both specs deal with. Trust is a different issue
>>>>> and neither OpenId nor WebId as we are specifying. WebId
>>>>> clearly makes it easier to specify trust in the web manner.
>>>>
>>>> Sure, but 3rd parties will have to link to other public keys,
>>>> which is a problem for certificate generation on-demand.
>>>
>>> ? Why do 3rd parties need to link to other public keys. Just link
>>> to the WebId. Or if you need it create a special public key that
>>> does not change.
>>
>> Again, if you just link to the WebID, you'll just be able to know
>> from other trusted source information about the WebID, not about
>> the actual person that's in front of you.
>
> What do you want? DNA Sampling?

I'm just talking about something equivalent to PGP or PKI (which have 
their own shares of problems). This is not for all use-cases of WebID.


> In any case I don't see that OpenID is doing anything here that is stronger.

Indeed not.


>> Creating a key that doesn't change and that your friends can vouch
>> for doesn't help in this case, since it won't be the key you're
>> using then.
>
> Well it does help. In both cases your friends are vouching for
> something that is being used. After all that is how PGP works.
>
> Let me explain again. The foaf profile could be signed with the key
> that does not change. And if it is then clearly the foaf file
> stating that you are using a new key would now be signed by the key
> that your friends were vouching for. There is here a clear Signature
> level trust chain equivalent to PGP, which should make you happy.
>

That's where your crypto logic doesn't work.

You generate a new key on your friend's machine because you don't have 
your usual private key (which is the one for which 3rd parties can 
confirm the public key). Setting up that new key changes the FOAF file, 
so the signature you've made with the usual key no longer works. Since 
you don't have the usual key, you can't sign that new FOAF file.
If you did have that private key, then you might have well have used it 
directly.


>> Sure, but that's never feasible on demand, simply because when you
>> need to use a new/temporary certificate, it's exactly when you
>> don't have the long-lasting private key to be able to sign that.
>
> Ah well you put that on the server! The server signs your foaf using
> the key. This is just how SSL connections work. The server signs the
> SSL connections. And all of e-commerce is based on that.

If an e-commerce site is compromised, this only impact that site. If you 
WebID is compromised, the consequences can propagate to all the services 
that accept your WebID.


>>>> As I was saying just above, as soon as 3rd parties start
>>>> including your public keys and you enhance the security using
>>>> that, you lose in terms of usability w.r.t. on-demand
>>>> certificate generation.
>>>
>>> Not necessarily, as I managed to show above.
>>
>> Your demonstration doesn't work: when you need the on-demand
>> certificate generation, it's exactly when you can't use your
>> long-lasting private key which would allow you to sign the
>> assertion in your new key (otherwise, all the attacker has to do is
>> to put his own key next to your long-lasting public key, instead of
>> deleting it).
>
> The attacker does not have access to my machine, so he cannot sign
> the foaf there.

Exactly, but neither can you.


> And there is not just the redirection argument. You have 3 services
> that can be attacked with OpenID. The OpenID HTML file, and the
> OpenId provider, and the connection between the Relying Party and the
> the OpenId provider.
>
> Sorry but it is absolutely clear that there are more weak points in
> OpenID: the protocol is obviously more complex!

Indeed, but we should make a more detailed analysis of that one day.


>> It's more or less the same problem, WebID is only slightly better
>> in that respect.
>
> No, it is a lot better. It is not as good as the perfection you are
> seeking, but that is another issue.

What I'm really talking about is the degree of assurance by which the 
resource provider knows the association between person and URI. Both 
have the same problem (except that WebID clearly has a mechanism that 
can improve that: the use of public keys).


> And it is not clear that the perfection you are seeking cannot be
> added to WebID later:  - eiher in the way mentioned above with friends
> publishing a public key that is constant

Which doesn't work...

> - or them publishing a public key that you always use. In that case
> you would have trouble with public terminals. But is that really a
> problem for people who take security seriously?

Indeed, public terminals are vulnerable either way.


I think I wasn't clear in my previous e-mails. I'll agree that out of 
the box, the WebID mechanism is likely to be more secure when it comes 
to protecting the interaction from the user's point of view.
Where WebID by dereferencing is equivalent to OpenID is from the point 
of view of the resource provider, which merely knows that the user had 
control of the WebID hosting at the time of verification. Ultimately, 
it's what matter, because it's the resource provider that's in control 
of the resource (e.g. where your ID is used, where you data is stored, ...)


Best wishes,

Bruno.