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

[Henry Story]

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!

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. 

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!

>  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!

> Incidentally, we could very well have 30x redirections in the same way with a WebID.

We could but we don't usually right! And if there were, then that would not be something that differentiates OpenId and WebID.


>>>>   - no possible typing mistakes
>>> 
>>> I can type in my e-mail address in Google. I don't even have to know my
>>> WebID. That's not really a security issue...
>> 
>> you can make a spelling mistake in typing. That means someone could then capture your password perhaps.
> 
> You were talking about typos in the ID itself initially.
> So if I make a mistake when I type my password, some can get... my incorrect password? I'm afraid this argument falls apart completely.

If you mistype your webid, you could get redirected to a login page that looks very much like yours but yet that is a fake one, where you then enter your password which gets captured. 

In WebID this redirect does not exist from the users point of view, so the whole phishing type of attack cannot take hold.

> 
>>>>   - 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. 

>> 
>> that can be a one time password. Usually you don't need that.
>> Btw, I have had this computer for 4 years. Getting a new key every 4 years
>> would be a great improvement.
> 
> OTP needs to be adequately supported by the server,
> and a suitable device on you, possible

yes, though perhaps not so difficult to imagine. And one also can have one time password lists written out on a piece of paper. Then the "Device" you need is a piece
of paper.

> but again, equally possible with OpenID.

yes, for the situation when you use a public terminal there is not that much difference. But in any case using public terminals is insecure full stop.

> I'm afraid this argument falls apart completely again (as an advantage over OpenID, but OTP are not a bad idea in general indeed).

Not really. Unless one uses cryptokeys, there is just not much usability difference between openid and WebId on public terminals. It is clear though that OpenId on public terminals also requires one time passwords, because otherwise you are giving everything away. At least with WebId it is clear that something special is going on.

And in any case there is not much to discuss security wise concerning public terminals. 

> 
> 
>>>> 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?
In any case I don't see that OpenID is doing anything here that is stronger.

> 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.

>>>> You have an idea of using public keys to sign documents to get more
>>>> distributed security. That is not a problem really. We could create a
>>>> special public key that people use to identify someone for signing
>>>> purposes.
>>> 
>>> That's not what I'm talking about. I'm talking about things like /me/
>>> putting /your/ public key in my FOAF file (along side foaf:knows) so
>>> that I, as a 3rd party to whatever service to want to connect, can
>>> assert that it is you indeed with a higher level of assurance.
>> 
>> Ok, so perhaps that will be an issue for another even more secure protocol,
>> which is also going to be a lot more difficult to implement for all kinds of
>> reasons.
>> 
>> Also why not put one long lasting public key of mine in your foaf file.
>> I could then perhaps use that public key to sign my foaf file, which would
>> prove that it had not been altered?
>> 
>> Would that satisfy you?
> 
> 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.

> 
>>> Putting other people's public keys in our FOAF file is feasible, we just
>>> haven't done it (I've actually put your public key in my FOAF file, a
>>> while back, but I think an early implementation of our libraries choked
>>> on it because of an incorrect SPARQL query at the time, a small early bug).
>>> (Signing those documents is an even higher level of assurance, but
>>> that's to solve the problem of how you trust the way you've obtained the
>>> 3rd party's FOAF document.)
>>> Of course, the 3rd-parties need not be foaf:Persons you know, but you
>>> can mix hierarchical and web-of-trust in that model.
>> 
>> yes, I don't think we have excluded those options. But as you see
>> just getting the basics working is already a lot of work. As Volatair said: The perfect is the enemy of the good.
> 
> Sure.



> 
> 
>>> 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.


>>> In short, WebID can provide you additional security when you're using a
>>> key others know (typically, on once of your devices), but will not
>>> improve the situation for keys your social network don't know (typically
>>> on devices that aren't yours, because you'd have generated temporary
>>> keys for that device). Nothing wrong with that.
>> 
>> If you create a temporary public key with for some temporary device, and that
>> foaf file is signed with a long term pub key, then you should be ok. But in the
>> end, clearly having your server compromised is not going to be good whatever you
>> do. And that seems to be what you want to solve. OpenId has that same problem 2ce over, since you need to avoid 2 servers being compromised.
>> 
>> 
>>> WebID can improve the security of the authentication,
>> 
>> Good to hear you say that!
>> 
>>> I'm just saying we
>>> need to be clear on the reasons. The arguments you put forward are not
>>> really security-related.
>> 
>> They are precisely security related.
> 
> Of your 3 points, only the simplification on the redirections could potentially be considered as a security improvement over OpenID. (The typo argument, it's a convenience thing at best; the OTP is the same in both cases.)

No the typo argument is another issue. You cannot have phishing with WebID. 

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!

> 
> The redirections could very well happen in the same way with 302 redirects with WebID, though.

You are thinking of your OpenID home page redirecting to another one? If that is a problem, then it would be exactly the same problem between OpenId and WebID, so it would not differentiate between them. And that is why I did not speak of redirects at that level, which are clearly not a good idea.

> 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.

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
  - 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?

  Henry

> 
> 
> Best wishes,
> 
> Bruno.
> 
>