One Phone Call Undid 13 Years of Namecheap Account Security

A 13-year Namecheap customer posted a story on Hacker News this week that should worry anyone whose infrastructure hangs off a domain name — which is to say, everyone. He held a .com on behalf of an old college club, registered under his own name, address, and phone number. When the club's new leadership wanted DNS changes, they didn't know who owned it, so they triggered a password reset against the account. The owner spotted the reset email, filed a ticket saying "I did not initiate this," and Namecheap called him to confirm. So far, textbook.

Then the club leader called Namecheap support and asked for access. According to the owner's account, support changed the account password and the account email — the two credentials that gate everything else — with, in his words, "no verification or validation whatsoever." The person who convinced them wasn't the account holder, didn't share the registrant's name or address, and had already failed the legitimate recovery path. He just asked persistently on the phone.

The story resolved amicably: the two parties connected offline and transferred the domain properly, and the owner says he'd have handed it over gladly if asked. But that's exactly why the account is so damning. This wasn't a sophisticated social-engineering crew with spoofed documents. Namecheap, on its own view of the world, saw a personal account, a fraud report from its verified owner, and then a stranger on the phone — and sided with the stranger. Worth noting: this is one person's firsthand telling, and Namecheap hadn't publicly responded to the thread as of this writing. But commenters piled on with their own versions, including one who says support handed account access to an unverified caller claiming to represent a client. The pattern is familiar enough to take seriously.

Your registrar's support desk is your real password

Here's the uncomfortable framing developers should internalize: your domain's security is not your password, not your TOTP app, not your hardware key. It's whatever your registrar's lowest-discretion support agent is empowered to do for a persuasive caller. Every control you configure sits behind the recovery path, and the recovery path is staffed by humans measured on ticket resolution.

This isn't a Namecheap-only disease. In March 2020, attackers spear-phished a GoDaddy employee and used that access to redirect DNS for escrow.com — a company whose entire business is being trustworthy — to a server in Malaysia. Eight months later, scammers talked GoDaddy staff into transferring control of domains belonging to multiple cryptocurrency platforms, including NiceHash. Both incidents, documented by Brian Krebs, at least required deceiving an employee with phishing or impersonation. What the Namecheap story alleges is a step worse: no deception artifacts at all, just a request.

And you can't hide from this attack. WHOIS privacy masks the registrant, but your registrar is public information forever — the NS delegation and RDAP records name it to anyone who runs one dig query. The club leader found the domain "parked at Namecheap" exactly this way. Anyone who wants your domain knows precisely which support line to dial.

Locks that hold, and locks that don't

The standard advice — enable transfer lock, use 2FA — mostly protects against the wrong threat. clientTransferProhibited is set by the registrar and unset by whoever controls the account; if support will reassign the account to a caller, the lock travels with it. Same for 2FA: it guards the login form, not the phone queue.

The control that actually addresses this is registry lock — serverTransferProhibited, serverUpdateProhibited, and serverDeleteProhibited set at the registry itself (Verisign, for .com). With registry lock, even your registrar can't change nameservers or transfer the domain without a manual, out-of-band verification ceremony between registrar and registry. It's how google.com and facebook.com are protected. Historically it lived behind corporate registrars like CSC and MarkMonitor at enterprise prices, though Cloudflare now offers it to its enterprise customers. For a revenue-critical domain, it's the difference between "an attacker must defeat a process" and "an attacker must defeat a mood."

Below that tier, you're managing risk, not eliminating it. Some moves that cost nothing:

• Break the circular dependency. If your registrar account's recovery email lives on a domain inside that same account, a takeover is self-ratifying: attacker gets the account, gets the domain, gets the email, and now passes "legitimate" verification everywhere downstream. Recovery email goes on a domain held elsewhere.
• Stop registering shared domains personally. This whole incident was a bus-factor problem — a club domain under one alum's personal identity — that support "solved" in the worst possible way. Org domains belong in org accounts with multiple authorized users, boring as that is.
• Monitor from outside. Poll your NS and DS records from an external host and alert on any change; watch certificate transparency logs (crt.sh will email you) for certs you didn't issue. A hijack you catch in ten minutes is an incident; one you catch from a customer email is a catastrophe.
• Split registrar from DNS host. It forces an attacker to change delegation — the exact event you're alarming on — rather than quietly editing records in place.

The economics won't fix this

Retail domain registration is a race to the bottom, and support desks are a cost center in a business with wholesale-thin margins. Verification ceremonies create tickets, escalations, and churn; "just help the caller" closes tickets. Nothing about the incentives pushes toward rigor, and Namecheap's recent history — its Sendgrid-based email system was hijacked to blast MetaMask phishing at customers in February 2023 — doesn't suggest security is winning internal budget fights. Since September 2025 the company has been majority-owned by private equity firm CVC Capital Partners at a $1.5 billion valuation. PE ownership doesn't automatically mean worse support, but it rarely means expensive new friction in the name of account security.

Several HN commenters announced migrations to Porkbun or Cloudflare, and switching is reasonable — Cloudflare in particular has no retail phone support to socially engineer, which in this one narrow sense is a feature. But treat the lesson as bigger than the vendor. Every registrar's support channel is an authentication bypass of unknown strength, and you find out its strength only when someone tests it against you. Price your domains accordingly: the ones that would hurt belong behind a registry lock or, at minimum, inside an account whose recovery paths you've actually mapped. The ones protected by "surely they'd verify first" are protected by nothing.