At Nametag, we are constantly innovating to create the best defense against phishing attacks and bad actors, helping companies and their implementation teams feel secure and resilient an evolving threat landscapes. This post describes how Nametag is resistant to phishing attacks. In a phishing attack, the attacker wishes to either (1) trick the user into providing their personal information to the attacker rather than Nametag, or (2) trick Nametag into providing the user's information to the attacker rather than the intended organization.
Request Links and Domain Binding
All Nametag requests start with a request URL. This can be generated by either a person, using the Nametag console, or by an automated process using our API (link), or by initiating an OAuth 2.0 flow (link). This request URL can be transmitted to the user by sending an email or SMS with the link, showing the end user a QR code, or by directing the end user's browser to the link.
Example request link:
When the link is visited on an iOS or Android device, the Nametag AppClip (iOS) or Instant App (Android) is launched. Apple and Android both require domain validation to bind the nametag.co domain to the corresponding app, and our app only launches when triggered by nametag.co domains. If an attacker sent the user a link with a similar looking domain, it would not launch the Nametag app, nor would the Nametag app accept the link as valid. Similarly, if at attacker crafted a QR code containing a link to a similar looking domain, the app would not launch.
Attestation
A clever attacker might create a fake version of the Nametag app, either as a native app or as a web page. In order to complete a request, the attacker must communicate with our API to deliver evidence (photos of IDs, device telemetry, etc.) and accept requests.
Our API must ensure that it only accepts evidence from the genuine Nametag app signed with our code signing keys, not from a copy-cat version of the app or a web browser pretending to be our app.
We achieve this with Play Integrity (Android) or AppAttest (iOS). These services provide a cryptographic assurance that the device and app are genuine. We build upon that by producing a cryptographic signature that covers the content of each request from the app to our service and proves to us that we are processing requests that originated from our genuine app.
Example request with an attestation header (X-Nametag-Integrity):
POST https://nametag.co/mobile/v2/vault/phone HTTP/1.1
Content-Type: application/json; charset=UTF-8
Content-Length: 31
Authorization: Bearer eyJ...Mtw
X-Nametag-Date: 20221012T165444Z
X-Nametag-Integrity: NT4-ECDSA-SHA256 Credential=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE_vRnP3mg8ySK93iURm_cI0lU1qO_N_N3-kF3b9qZ2nk3vFa37piPJzxcyxuD0exN3VQMcuptntqLqADDUGsKRA/nametag:nt-android:nametag.hello.dev, SignedHeaders=authorization;user-agent;x-nametag-date, Signature=MEUCIQDJvQozD6fys4dfmjKOXp5eXWoxkgcxrXChCejxJ4dyqAIgcEt4IMW2XA0STesgFyNwJoeqVkhvSNx3zorDt-q9VcI
User-Agent: nametag.hello/3.3.15; Android/12; google Pixel 6a
{"phone_number":"+12025551212"}
An attacker mimicking the Nametag app would not be able to produce a valid signature and thus would not be able to interact with the Nametag API server as if it were the real app.
The Signature field is a signed hash over the headers (including the current time), the request method and URL, the device authentication key material, as well as the body of the request. Generating a valid signature requires the app to be genuine as attested to by iOS or Android, and is bound to the particular device that originated the request. Replay attacks are prevented by including a timestamp in the signature.
API Keys Control Completing the Request
Once the user has provided evidence and consented to sharing data with you, you must retrieve the data, either using the /requests API, or using OAuth 2.0. In either case, in order to receive the data, you must do one or more of:
- Provide a Nametag-issued API key
- Prove possession of a domain that you'd previously entered into the Nametag configuration for your organization.
This precludes an attacker who does not have access to configure your Nametag organization from receiving information that was intended for you.
Brand Trust
Imagine a scenario where an attacker tries to deceive others by creating a fraudulent Nametag account that mimics your company's identity. To prevent such impersonation attempts, Nametag employs a rigorous manual review process during new company onboarding (in addition to identity verification of account administrators) and whenever there are branding changes to company accounts. This ensures that when your company's name, logo, and colors appear in the Nametag app, they have been carefully verified by our team to be authentic and associated with your organization. By doing so, we provide users with the assurance that the verification requests they receive accurately represent the intended recipient, enhancing trust and confidence in the verification process.
