Service/Endpoint specification

fmrsabino commented 3 years ago

Problem

For initial context of the problem please read: https://github.com/gnosis/safe-react/issues/2565

In order to mitigate this issue, Intercom provides an Identity Verification mechanism where it rejects the user login if a server side generated hash is not provided.

Currently we do not have such endpoint or service. The identity verification relies on a secret that lives in our infrastructure so this issue cannot be solved on the client side.

Proposed endpoint

GET /intercom/{userId}/

{
  "userId": <string>,
  "hash": <string>, // server side computed hash using secret set in environment
}

FAQ

Why is the userId returned in the response? The client needs to send both the user_id and the hash to intercom. But maybe we can just send the hash back and rely on the client to do the mapping (need input here)

From the support article (https://www.intercom.com/help/en/articles/183-enable-identity-verification-for-web-and-mobile)

Are you sending a user_id or email address along with the user_hash? If you just send the user_hash the identity verification check will fail.

Why not use the email address since it is also supported? I decided to go with the userId only if possible from the frontend side. There are some rules to take into consideration if both are provided

From the support article (https://www.intercom.com/help/en/articles/183-enable-identity-verification-for-web-and-mobile)

Are you generating the hash with the correct data? If you’re sending both user_id and email, your user_hash must be generated with the user_id. If you’re sending just a user_id, your user_hash must be generated with that user_id. If you’re sending just the email address, your user_hash must be generated with that email address.

Proposed Deployments

Two deployments were discussed:

1) AWS Lambda 2) K8s

We should decide which one to go with for this solution. For some context we have Devops take on this here: https://gitlab.gnosisdev.com/devops/planning/-/issues/911#note_56730

Proposed Solution (if K8s deployment is preferred)

Due to the nature of this endpoint, no state is required to be held by the application. So the technical requirements are:

API accessible by the safe-react client
Secret storage (single secret to use in the hash computation). Eg.: environment variable

With this in mind (and with the technologies that we have been using) a couple options were discussed (please do comment with more suggestions)

Django (Python toolchain)
Rocket (Rust toolchain)
Flask (Python toolchain)
... (your suggestions)

@gnosis/safe-services @gnosis/safe-web

rmeissner commented 3 years ago

Implementation wise it doesn't matter what is passed by the client to the service, right? It could be any string, the client should just always use the same kind. I would therefore maybe also make the param name very generic.

Note: we cannot use the email as this is a public known identifier in a lot of cases. We should probably define in the react issue what value is send to the service and how it is generated (e.g. is it a random hash). Also we should outline the behavior changes. Both are probably more information that should be on the react issue.

fmrsabino commented 3 years ago

Implementation wise it doesn't matter what is passed by the client to the service, right? It could be any string, the client should just always use the same kind. I would therefore maybe also make the param name very generic.

Implementation wise that is correct, any string needs to work. However on the safe-react <> intercom side the following needs to happen:

safe-react authenticates with intercom using both user_id and email → hashing needs to be done on user_id
safe-react authenticates with intercom using just the user_id → hashing needs to be done on user_id
safe-react authenticates with intercom using just the email → hashing needs to be done on email

Note: we cannot use the email as this is a public known identifier in a lot of cases. We should probably define in the react issue what value is send to the service and how it is generated (e.g. is it a random hash). Also we should outline the behavior changes. Both are probably more information that should be on the react issue.

Yes I agree. I commented on https://github.com/gnosis/safe-react/issues/2565#issuecomment-892662902 so that they are aware of the current payload discussion and requirements. We can maybe move the payload discussion to the safe-react issue

rmeissner commented 3 years ago

I am aware that the correct identifier needs to be choosen, but that can be done on client side and the service just acxepts an identifier of any form.

fmrsabino commented 3 years ago

In addition to the current spec:

The original issue is about accessing the user's history of messages. Since there's no authentication required right now and only the user's email is required, it means that by manually setting this to any email would query intercom to retrieve the correspondent chat history. So currently, just by having the email address the chat history can be retrieved.

If we add the secret and hash in addition to the email/user_id then we are just moving the issue to another layer if the hash generation is deterministic – ie.: anyone can ping the service with user email/id in order to get the hash and use this respectively with intercom to get access to the chat history.

Given this the current assumption is the following: with no authentication in place (eg.: password) the chat history can still be retrieved given deterministic data. This means that from the user perspective, chat history needs to be disabled.

So we have two possible working paths:

Chat History is disabled from the intercom side (no need for a new service or endpoint)
The user_id used by the frontend is randomly generated. This is the id sent to this endpoint. Access to chat history is only valid if this random user_id is known.

@katspaugh @rmeissner

katspaugh commented 3 years ago

Just talked with Tobias:

he sees value in the users being able to interact with Intercom via email, so we should go for the random hashed user_id saved in a cookie like a one-time password
we'll try to disable the email via settings for now to fix the security hole

Update: I couldn't find a way to disable the email feature completely. There's this but it will just disable sending a chat summary via email.

fmrsabino commented 3 years ago

This repo is no longer required. Please see the update here: https://github.com/gnosis/safe-react/issues/2565#issuecomment-898430996

gnosis / safe-intercom-id-generator