On phishing with a WebID

[calummackervoy]

I was thinking about an existing problem with email, namely that people register similar looking emails and use this in phishing attacks on users

The RFC 5321 states that the mailbox in mailbox@hostname of an email format is case-sensitive. ALICE@example.com and alice@example.com are therefore different email addresses (the domain is case-insensitive). Many providers ignore this and make similar email usernames point to the same email to help protect against spoofing

I think that since the WebID is a URI, and URI paths are case-sensitive, it follows that http://server/user/Alice/, http://server/USER/Alice/ and http://server/user/alice/ are all distinct webIDs and all distinct users ?

Evidently this could make it pretty easy to fool a human that I'm Alice

Also

Since many applications treat the emails alice@example.com and ALICE@example.com as distinct - in spite of the email provider - it leads to vulnerabilities. The reverse scenario, having more complex controls in what makes an email distinct on the application (but not the provider) opens it up to email conflicts

Since all of the code I've seen working with RDF relies heavily on just using resources/properties as URIs, I'd bet that the vast majority of applications would be treating http://server/user/Alice/ and http://server/user/alice/ as distinct resources whatever the IdP provider does. I don't think that this part is an issue with Solid - because I think that the Solid POD should hold all of the user data in an application (except links), which might make it safe to make it the IdP's decision ? Either way I think it deserves a "SHOULD" condition in the spec?

[bblfish]

That is an interesting point, as WebID's should be short enough to type into a browser and humanly readable.

WebIDs and Solid follow the motto that WebID and other RDF URIs should mostly be manipulated by software. Such software should seek confirmation of links: eg. a WebID pointing to a blog, could be confirmed by having the blog point back to the WebID. A public key in a WebID profile can be copied to another document, but that won't give the other owner access to the private key....

We are going to make small modifications to WebID spec, so that could be brought up on the recently opened WebID github repo.

[acoburn]

It is important to point out that only the path portion of a URL is case-sensitive.

In any case, the access token used to access a user's Pod is always generated by an IdP, and the WebID (or DID) identifier will be found in that access token, so ultimately, it's a question of what the IdP produces and whether the user's WebID document contains a trust relationship with that IdP.

Furthermore, capitalization is only one form of spoofing. There are many Unicode characters with ASCII look-alikes that can be even more difficult to spot.

[elf-pavlik]

Either way I think it deserves a "SHOULD" condition in the spec?

What exactly do you propose as "SHOULD" in the spec?

[calummackervoy]

@bblfish I see, so am I right in understanding that if something that the user owns is stored on a server, it should have a reverse link to the owner, and any application reading should be expected to check that reverse link against any claims?

For me that clears up my concerns about applications using Solid, I left that part in because it's a little hard to visualise and I was unsure

@acoburn I had in mind for example:

• I have a friend http://IdP.com/users/alice/ who uses http://application.com/ and who I trust
• tomorrow I get a notification that http://IdP.com/users/Alice/ wants me to share my data with http://appplication.com
• I click "Authorise" because it looks okay at first glance. I think to myself "cor why is it asking me this again?" as the hacker starts exploiting our new relationship

EDIT: note that the two application URIs in (1) and (2) are not the same... I think that I'm understanding data access grants correctly, that I might trust another agent with my data, but that I need to trust the application that they're using too?

[calummackervoy]

What exactly do you propose as "SHOULD" in the spec?

@elf-pavlik that the IdP should place some appropriate controls on a user's WebID path

[acoburn]

What exactly do you propose as "SHOULD" in the spec?

@elf-pavlik that the IdP should place some appropriate controls on a user's WebID path

I imagine that would be appropriate for a "Security Considerations" section. For all IdP-related code I've ever written, user account identifiers are normalized, and I suspect that's fairly typical.

@acoburn I had in mind for example:

I have a friend http://IdP.com/users/alice/ who uses http://application.com/ and who I trust
tomorrow I get a notification that http://IdP.com/users/Alice/ wants me to share my data with http://appplication.com

That seems like a problem with the IdP that it would have separate identities that differ by capitalization. This is also why you will find that IdPs often restrict user names to lower case ASCII.

[bblfish]

@bblfish I see, so am I right in understanding that if something that the user owns is stored on a server, it should have a reverse link to the owner, and any application reading should be expected to check that reverse link against any claims?

Checking links back allows one to develop a chain of trust, yes. You can build a lot on that.
I have a proposal for a Web of Nations that is buildt on that and https. So I think you can go very far that way.

There are other ways of verifying things of course too, which will be complimentary.

Not everything can be verified in life though. So we still need to develop libraries that make it easy to see what is and is not verified, and what the verification is, if needed. For a deep philosophical view of how language language work you can look at Robert Brandom's development of language and the Game of giving and asking for reasons. That shows how one way of giving a reason for a claim is to be able to state where it came from, and give reasons for why that was from a believable agent. That gives circumstantial evidence, which can be retracted.

[elf-pavlik]

@elf-pavlik that the IdP should place some appropriate controls on a user's WebID path

Actually nothing requires IdP to host user's WebID. User can delegate to any IdP they choose, and can change IdP they are delegating to by setting relation solid:oidcIssuer in their WebID document. WebID document can be hosted anywhere on the web, though often it would be hosted in solid storage (pod) to take advantage of read-write and access control features.

I imagine that would be appropriate for a "Security Considerations" section. For all IdP-related code I've ever written, user account identifiers are normalized, and I suspect that's fairly typical.

@acoburn does this particular implementation of IdP host WebID documents? It sounds like it does and uses some URI Template to create WebIDs based on user account identifiers.

tomorrow I get a notification that http://IdP.com/users/Alice/ wants me to share my data with http://appplication.com

I think authorization agent presenting consent screen should have access to user's address book and clearly mark if that WebID exists in mentioned address book or if some 'unknown' WebID.

[acoburn]

@acoburn does this particular implementation of IdP host WebID documents? It sounds like it does and uses some URI Template to create WebIDs based on user account identifiers.

The IdPs don't host WebID documents but they do use a type of URI template based on user account names

[calummackervoy]

@bblfish thanks for the reading recommendations I'll get into that. For info on David Lewis - Scorekeeping in a Language Game I found this PDF

I think authorization agent presenting consent screen should have access to user's address book and clearly mark if that WebID exists in mentioned address book or if some 'unknown' WebID.

I think that this approach could work, but if the webID was very similar, e.g. Alice  vs alice, I still think that a lot of users would click "Authorise", maybe unless the authorising agent really spelled out the difference to them and said "Check with Alice first!!!". I haven't done anything to measure that though, it's just a hunch

I see what you're saying about pointing the WebID document wherever you like, I'm not sure I fully get the difference between Pod provider and IdP, I thought that the pod provider was an IdP with a datastore 🤔 I suppose that in any case if the document can be stored anywhere then with my suggestion then whilst I might not be able to get http://IdP.com/users/Alice/, depending on the host I could still get http://IdP.com/docs/alice/, if that domain allowed me to store documents under the docs subpath

[bblfish]

Note: I don't myself really think we need IdP's at all. The WebID document is the Identity, and that can be used for authentication using HttpSig.

The question is how do you trust the information about the agent described in that document. And there it depends on the information.

1. If there is a public key listed there, and the agent proves that it owns the private key using HttpSig, then the guard knows that <#i> cert:key key.
2. If the WebID profile has a foaf:blog relation to a weblog space and that links back, then that relation can be verified.
3. If the profile makes a statement of age, then what you make of that depends on the context. If you want to send an notification you can use that information without verification to adapt the language of your message. If you have a legal requirement to know the age before giving access to a resource, and since self certification of that fact is clearly open to abuse, then you would need a verifiable claim from an agency that is response-able for making those claims (hence the link to Brandom) within a given legal jurisdiction. There may be many agencies that can make such claims reliably in any area.

As you see there are many ways to verify claims, many different agencies for different claims (eg. drivers license), so there cannot be One Identity Provider for all attributes. The most important attribute on which most of this can be built is the possession of a private key though, since for any claim an agent needs to prove of claims made about it that it is the object of those claims. And for that we just need a keyid, which can be an https url too allowing us to tie it into the space of linked data.

But having said that, could someone find a way to get people to link to fake WebIDs, etc... Sure, there is no completely fail safe system. That is where you need good UIs that will help people make intuitive context sensitive decisions. You also need verification mechanisms that bring the legal space into account.

[elf-pavlik]

I see what you're saying about pointing the WebID document wherever you like, I'm not sure I fully get the difference between Pod provider and IdP, I thought that the pod provider was an IdP with a datastore 🤔
I suppose that in any case if the document can be stored anywhere then with my suggestion then whilst I might not be able to get http://IdP.com/users/Alice/, depending on the host I could still get http://IdP.com/docs/alice/, if that domain allowed me to store documents under the docs subpath.

I think we will need some 'best practices' document. I know that many implementations put different instances of solid storage (datastore) on different subdomains, one could get similar subdomain but not something only differing by path element.

But having said that, could someone find a way to get people to link to fake WebIDs

WebID document links to IdP currently designates and their OIDC Provider. Pretty much we always follow the nose starting from user's WebID.

[calummackervoy]

Thanks @bblfish I hadn't read about HttpSignatures... I suppose that using an IdP gives you the ability to authenticate your identity in Solid-less contexts, as if it was a vanilla OIDC provider? I've tested our (WIP) implementation of Solid-OIDC in Django using Bearer tokens

I think that the suggestion of having a best practices for the IdP makes sense, even just a paragraph in any relevant security considerations would suffice for me personally. I'd be happy to try writing a paragraph for the Solid-OIDC spec if it would be useful

I suppose that with the IdP to one side, phishing is still possible if I'm pointing my WebID to a different domain and I try to mimic Alice's profile, which has already been brought up. It sounds like this concern could feasibly be addressed by a good consent form

I think that secure and accessible HCI on consent documents will require time and user research because it's a level of control that a user rarely has over their data. This part sounds like it falls within the scope of the data-interoperability-panel goals?

[bblfish]

@calummackervoy

Thanks @bblfish I hadn't read about HttpSignatures... I suppose that using an IdP gives you the ability to authenticate your identity in Solid-less contexts, as if it was a vanilla OIDC provider?

I think that is only true if well known OIDC providers adopt the Solid-OIDC spec.