Training users to be phished


Curve is using poor e-mail practices that train users to be phished by linking to a third party website. It contradicts Curve’s own phishing advice.

Received an e-mail from Support (Curve) with a link to demanding to verify my identity. This domain is not owned by Curve.

Since this is outside the app, it contradicts your official policy: “We’ve detected a phishing attempt targeting Curve customers. We never ask you to share personal information outside of the Curve app. If you have shared details through an SMS or link, please get in touch through our usual support channels.”

Expected behaviour
Always link to a site owned by Curve.

The first interaction should be in the app as per your official policy.

Cryptographically sign e-mails.

How to reproduce it:
Spend a lot of money then get an e-mail from support?


Wow, this is really bad. Along with their recent claim that switching to SMS for login verification was “more secure”, I’m genuinely concerned that Curve either don’t take cybersecurity seriously or don’t understand it. I’m not sure which is worse.


Yes, my friend (curve user) also got very suspicious about that onfido link and thought it is a phishing.
I understand Curve uses 3rd party for verification but it probably should be relatively easy to make link which uses curve subdomain for that purpose.

1 Like

It was enough to google a little bit, to understand that it is not phishing :slight_smile:

It was enough to Google a bit, to understand how to link to Curve’s own website then from there direct users to Onfido. Always link to the company’s own domain in e-mails.

Sorry, but I can’t keep quiet… Where do you see phishing?! When they clearly send you this link? Seriously, explain to me where you see phishing because I don’t understand :thinking:

I think what he is trying to say is that by directly referring users to *external links you are kind of training them to *expect such behaviour from Curve. To avoid this other companies using redirected links for example is better than

Meaning everything had to go through Curve first, so I am assured it legit. Unlike when it’s just a random email with random website link if that makes sense :smile:


I don’t doubt it… but passing off a service as phishing, when the support provides it, I don’t think it should be classified as phishing :slight_smile: maybe he could have opened a post in the ideas section and proposed it.

You must also take into account the Onfido API… I know that a token is generated after /redacted/… if the API does not allow it, Curve cannot use their domain :thinking:.

1 Like

Phishers gather information by impersonating a bank or other trusted party, usually by sending links in e-mail. The links go to a site they control and then they gather personal information or login details because the user has been tricked into thinking they are legitimate.

This fits that pattern of phishing: it is e-mail, it is unexpected, it solicits personal information that Curve already holds (I passed KYC a while ago), and the link goes to a third-party website.

To counter phishing, Curve said all such interactions would be in the app: . Following your own guidance, therefore, Curve will never send me an e-mail soliciting information and thus this e-mail is phishing.

E-mail from addresses can be forged. Sending a forged e-mail from is not hard. For example, your SPF records allow a broad range of Google cloud and AWS IP addresses:

host -t txt descriptive text “MS=ms19255557” descriptive text “atlassian-domain-verification=Es6HjAjsMLWh/ETspitTbzEzt2MbEM9gEONq7JyikTvkuDKGDpvePC5taffUe+V6” descriptive text “google-site-verification=4BUU9xFVEIM16pUiOT-L9IyErZGsc9vaIax3VBWfHr4” descriptive text “google-site-verification=4KZ8wkx_RPyiS1dhK4_eh3YKXrRA87nDnpCZHV6Vl8Y” descriptive text “google-site-verification=6tEhTCNjJ1YlhrXEShXs8-pk0wDuhSgeqC81XE9uSK4” descriptive text “onetrust-domain-verification=bb1820074bce41b0bc39ea313d9eb78a” descriptive text “status-page-domain-verification=cl7704tmbqqq” descriptive text “v=spf1 -all”
host -t txt descriptive text “v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4:” “/19 ip4: ip4: ip4: ip4: ~all”

Most likely, all a phisher would need to do to impersonate and pass SPF validation is use the same cloud providers.

Getting a valid SSL certificate for a domain is easy. All you need is LetsEncrypt. A valid SSL certificate means that communication is more likely to be with the owner of the domain. That communication with is encrypted means very little if there is no authentication that is associated with Curve.

Please, please follow best practices:

  1. If you’re going to post guidance to your users about how to avoid phishing, follow it . In this case, that means doing all interactions in the app because that’s what you said you would do.
  2. Never send e-mail soliciting personal information.
  3. If you must send an e-mail with a link, that link must go to a domain owned by Curve. Never by a third party. Setting up a Curve landing page is not hard.

Average users are not going to Google around to make a decision about clicking a link or not. They do not have a list of your partners memorized. Don’t tell me I can find an obscure blog post mentioning the partnership.

If you don’t follow best practices, you are training users to accept e-mails as legitimate, which makes them a target for phishing campaigns. Costing users and you money. And in the UK at least, training users to be phished through your poor e-mail practices makes it more likely Curve will be responsible for any losses incurred.

The correct practice here would have been to send an interstitial to the app referring the user to Onfido. Or a chat message. Perhaps send an e-mail to the user altering them that they need to login to the app to see a message.

Curve’s practices and responses on this thread suggests Curve lacks staff with cybersecurity knowledge. Which should worry everybody about Curve’s security, not just about phishing.


Yeah I agree. While I am not a fan of the word choice nor delivery, I think it’s a good point.

1 Like

Source email address can be easily spoofed. Anyone can send an email from with little effort. Getting an email from Curve support email is not a guarantee that it is legitimate. All links pointing to Curve domain gives assurance that link itself is legitimate regardless of how it was obtained.


It would be easy for to redirect to . There is no issue with the OnFido API here. All the user needs to do is land on that page.


Funnily I got email from Barlcays bank on the same topic today. Now that is a little more sensible advice.

Who is the security specialist in curve, do they even have one? i hope so.

1 Like

Used to be this guy :point_down:t2:

But he moved on

If you carefully read the posts, no one is accusing the email of being phishing. Rather what’s being said is that linking to external websites is exactly what phishing attempts would do. As such, it’s unwise for Curve to train users to expect being linked to external websites. It’s basic security 101


Hey @megamaster, this feedback was given to our product team and they’ve now created a feature for submitting identification through the Curve app so that Curve users can use this instead if it helps them to feel more secure! :grin:

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.