From @adrianhopebailie on Wed Feb 14 2018 11:12:19 GMT+0000 (UTC)
@dappelt raised this issue specifically against payment pointers. Irrespective of what is done in the Payment Pointers spec to address it we should track this against SPSP too.
The following is an edited version of @dappelt’s issue with more general focus than just Payment Pointers.
How can a user or an implementation verify that they are communicating with the SPSP endpoint of the intended recipient?
Example 1: Phishing techniques may trick a user into paying a familiar looking payment pointer, that resolves to a different SPSP endpoint that they expect. (Examples are homograph attacks and typosquatting.)
Example 2: Man-in-the-middle attacks may result in a sender being passed the incorrect SPSP endpoint URL when attempting to make a payment.
Phishing will likely become a bigger problem for Payment Pointers + SPSP than it is for websites.
In comparison, phishing websites require some effort to look convincing while spoofed SPSP endpoints can more or less simply copy the data from the intended SPSP endpoint. Phishing websites also need to come up with a believable reason why a user should enter their password and a second factor, which makes careful users suspicious.
EV Certificates (proposed by @adrianhopebailie). Upon receiving a given payment pointer for the first time, an SPSP client could prompt the user to review the certificate details of the SPSP server. Subsequent payments to the same pointer do not have to be reviewed again by the user.
I don’t think EV certificates will solve the problem. It is easy to obtain fake EV certificates and they don’t help against phishing. Also, making EV certificates a requirement to run an SPSP server would hamper adoption, since they are expensive to obtain.
Another drawback is that a certificate is tied to the domain (i.e. SPSP server) and not to a particular SPSP endpoint. For example, if example.com is an SPSP hosting providing, the legitimate receiver
$bob.example.comwill have the same certificate as a spoofed receiver
$b0b.example.com. And there are other problems with using certificates for this purpose. For example, if the certificate is renewed the wallet implementation detects that the certificate changed and gives a false alarm about a phishing attempt.
Warn/reject if SPSP URL contains Punycode.
The client software could legitimately reject that (internationalized) pointer OR give an extra warning to the user that it is being converted from an internationalized form.
Showing a warning before displaying internationalized payment pointers does not help users of non-latin alphabets. Such payment pointers, no difference if legitimate or not, would always prompt a warning and quickly become ignored by users. In addition, users that send mostly to ASCII pointers would get irritated by such a warning when occasionally paying to a legitimate internationalized pointer. Either we support internationalized pointers or we don’t. Something in the middle doesn’t help either user group.
Picture in SPSP response.
For each payment pointer, the user could select a picture that must be returned in the SPSP response. A spoofed SPSP endpoint does not know the picture and, hence, a user could recognize phishing attempts (essentially what okta.com does to prevent phishing).
However, I discarded this idea again since a user would need to remember too many distinct pictures (one for each pointer).
Secure payment setup as part of SPSP.
I am currently looking into how a payment pointer can be tied to an SPSP endpoint on the protocol level. SPSP could be extended so that subsequent calls to the same payment pointer verify that both sides have knowledge of a secret. Such a secret would need to be established the first time a given wallet and SPSP endpoint interact. Phishing attempts fail since the spoofed SPSP endpoint does not have the secret. The name of the protocol I am looking into is secure remote password.
Copied from original issue: https://github.com/interledger/rfcs/issues/392