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

[Bruno Harbulot]

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.
The redirections make the problem only slightly worse, since the real 
problem is where those redirections come from.
Incidentally, we could very well have 30x redirections in the same way 
with a 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.

>>>    - 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.
>
> 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, but again, equally possible with OpenID. I'm 
afraid this argument falls apart completely again (as an advantage over 
OpenID, but OTP are not a bad idea in general indeed).


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



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



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


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

The redirections could very well happen in the same way with 302 
redirects with WebID, though. It's more or less the same problem, WebID 
is only slightly better in that respect.



Best wishes,

Bruno.