[HN Gopher] Does Your Domain Have a Registry Lock?
___________________________________________________________________
Does Your Domain Have a Registry Lock?
Author : jmsflknr
Score : 130 points
Date : 2020-01-24 17:27 UTC (5 hours ago)
(HTM) web link (krebsonsecurity.com)
(TXT) w3m dump (krebsonsecurity.com)
| gist wrote:
| > With a registry lock in place, your registrar cannot move your
| domain to another registrar on its own. Doing so requires manual
| contact verification by the appropriate domain registry, such as
| Verisign -- which is the authoritative registry for all domains
| ending in .com, .net, .name, .cc, .tv, .edu, .gov and .jobs.
|
| Putting a 'registry' lock into place has upside and downside. As
| mentioned in the story the downside is in an emergency it's
| harder to make a change because of the friction of another step
| to make a change (and that means any change even DNS servers).
|
| That said it still doesn't prevent social engineering. The
| implication in the article is that if you social engineer a CSR
| at a registrar the registrar having to have another step to get a
| domain unlocked (contact the registry ie in the case of .com et
| all Verisign) then someone will say 'hmm let's be sure on this'.
| In theory why would this happen? Once someone has been social
| engineered that's that, right? (I mean sure it's another step and
| sure that could mean someone thinks more but...)
|
| Now let's say you take care of a domain using registry lock. What
| is the tradeoff if someone gains access to your dns servers and
| you need to change those servers but you can't do that easily
| because a domain is registry locked and now you need to depend on
| a registrar to contact the registry and get that done. How
| quickly will that happen?
|
| My point is it's not a non-trivial decision to make at all and
| the downside has to be taken into consideration.
|
| One last point. There are procedures in place if a domain is
| transferred to another registrar to get it back to the original
| registrar. The best advice is to setup some kind of manual
| monitoring (not dependent on a registrar) where you periodically
| check the registry whois for the domain and note any changes to
| it (dns or otherwise).
| parliament32 wrote:
| The usual "registrar lock" is the clientTransferProhibited status
| you see on domains... that's easily removed by social engineering
| the registrar.
|
| "Registry lock" is serverTransferProhibited, the kind where both
| your registrar and the main registry need to agree to transfer
| the domain to another registrar. For instance, you can buy a .ca
| domain from any registrar, but you need CIRA's compliance (the
| issuing body for all of .ca) to enact a registry lock. This
| explains it a bit better: https://cira.ca/ca-domains/optimize-
| your-ca/registry-lock
|
| I'm having trouble tracking down how to do this for a .com
| though.
| mehrdadn wrote:
| Oh wow, so you have to manually lock and unlock and wait like
| an hour before you can e.g. update DNS? That sounds painful.
| ryukafalz wrote:
| To transfer the registration, but not to update records.
| Domain ownership is generally largely separate from zone
| management. Transferring a domain to someone else typically
| isn't something you do often.
| mehrdadn wrote:
| Oh I see. It said "any changes" so I figured that included
| DNS. Thanks.
| parliament32 wrote:
| You'd have to wait if you change your NS records (ie move to
| a new DNS provider) but normal DNS changes will be outside
| this.
| clarry wrote:
| > that's easily removed by social engineering the registrar.
|
| I decided to eliminate that one by becoming my own registrar.
| And that's one less man in the middle siphoning money off of
| me.
| josefresco wrote:
| That seems like an expensive and time consuming solution,
| unless you have many, many domains.
|
| https://www.quora.com/How-much-does-it-cost-to-become-an-
| ICA...
| admax88q wrote:
| So what actually makes the "registry lock" robust against
| social engineering.
|
| Reading CIRA's page it just says that to make changes the
| Registrar will talk to CIRA to have to lock removed on their
| behalf. Doesn't sound like there's any mandatory OOB check from
| CIRA back to the actual client.
| [deleted]
| teddyh wrote:
| A.k.a. the serverTransferProhibited status.
| jiveturkey wrote:
| I was never aware of this, and it appears only a tiny handful of
| TLDs support it. I think BK is overstating the case:
|
| > a more stringent, manual (and sometimes offline)
|
| How is it more stringent? Who's to say the registry (eg verisign)
| will do any more stringent of an unlock process than the
| registrar?
| wnevets wrote:
| I'm not able to find a registry lock on google domains. There is
| a lock feature but i'm assuming that is a registrar lock
| CydeWeys wrote:
| You mostly see registry lock offered by corporate registrars
| that have a high touch customer service flow, e.g. you have a
| dedicated person servicing your account.
| arkitaip wrote:
| Probably because the manual management of these requests is
| relatively expensive.
| xoa wrote:
| Yeah, CloudFlare is one that offers it, but it seems firmly
| in "Request Quote/Call Sales" territory for pricing. It dates
| from when they first intro'd their original registrar
| offering [1] a few years ago, and they said right out:
|
| > _" CloudFlare Registrar is not designed for the masses.
| There are plenty of great mass-market registrars. However, if
| you're an organization where losing your domains would be a
| front-page story, then CloudFlare Registrar is for you."_
|
| Of course, they later did introduce a mass market offering as
| well, but not with that set of features! :)
|
| ----
|
| 1: https://blog.cloudflare.com/introducing-cloudflare-
| registrar...
| [deleted]
| mehrdadn wrote:
| Confused, how do you get a registry lock then? Do you have to
| email your registrar? Why is there so little info on this? Or is
| this the same thing as clientTransferProhibited that is often
| provided?
| megous wrote:
| You have to deal with the registry directly. Otherwise it's
| kind of pointless if registrar itself can lock/unlock it.
|
| I have registry lock. I just asked my national domain registry
| to lock the domain. All that was needed was a strong proof of
| identity. (not just a photo of an ID, but doing a physical
| verification in person somewhere, like on the post office or
| sending a notarized letter) It was free.
|
| But this is a national domain, where I have a high trust in the
| registry itself (registry manager makes the Turris router, btw,
| and some key software like knot dns server, etc), and that's
| also the reason why all my important stuff is linked to this
| domain.
| belorn wrote:
| No, some registrars are still the one that manage the
| communication with the registry. A big reason for the
| registry, registrar and registrant model is so that the
| registry do not interact directly with customers.
|
| It also depend on the type of registry. .se for example allow
| registrars to set registry lock automatically but not unlock.
| Unlocking is a manual process and there is contractual
| conditions that the registrar must have verified the identity
| of the customer who is requesting the unlock, and the
| registrar must also sign to that fact. So far no registrar
| has failed yet to do so, thus the legal ramification of
| failing this has yet to be tested.
| [deleted]
| omarhaneef wrote:
| Wow. Some random person was able to move a domain to their own
| account simply by whatsapp ing the registrar, telling them that
| they had bought the domain and were having trouble moving it.
|
| That's it.
|
| It makes me realize that Google's no humans policy -- is it a
| policy? -- is actually a strength here. My domains purchased
| through Google are safe from social engineering because, well,
| there are no humans to contact to ask them to manually move
| domains.
|
| (p.s. That is _not_ some kind of dare to hackers! I am not
| suggesting you prove me wrong.)
| BinaryIdiot wrote:
| > It makes me realize that Google's no humans policy -- is it a
| policy? -- is actually a strength here. My domains purchased
| through Google are safe from social engineering because, well,
| there are no humans to contact to ask them to manually move
| domains.
|
| Except Google actually has a lot of humans in the loop for
| Google Domains. I was having an issue transferring a domain and
| I clicked a button to chat and was talking with a real person
| in about a minute.
|
| Granted, they may have better security procedures but they're
| still humans.
| 3xblah wrote:
| "In the end, E-HAWK was able to wrest back its hijacked domain
| in less than 48 hours, but only because its owners are on a
| first-name basis with many of the companies that manage the
| Internet's global domain name system. Perhaps more importantly,
| they happened to know key people at PDR - the registrar to
| which the thieves moved the stolen domain.
|
| Dijkxhoorn said without that industry access, E-HAWK probably
| would still be waiting to re-assume control over its domain."
|
| A different read: It was "humans"-based customer support that
| saved E-HAWK. A "no-humans" customer suppport system might have
| left E-HAWK powerless, waiting, hoping.
|
| Analogising to the parent's example, if parent had a serious
| problem, a "no-humans" customer support system might result in
| helplessness, waiting, hoping for some human at Google to
| discover and fix parent's problem, unless parent happened to
| know key people at Google.
| arkitaip wrote:
| Google Domains does have phone/chat/mail support but I still
| would like to believe that their security practices are solid
| enough that they wouldn't fall for this most basic of social
| engineering attacks.
| duxup wrote:
| The no humans thing also just closes off any path for
| exceptions that occur outside of what is coded.
|
| I bought a domain for a blogger blog ages ago. At the time
| google had no domain registry so they partnered with some
| company.
|
| Years later and google starts hammering me with "hey your
| credit card is expired we're not going to renew your domain"
| ...
|
| Fine right?
|
| "Hey go update your payment information on admin.google.com"
|
| Wait. I don't have a g-suite account... and on my personal
| account my payment info is up to date, so I figure maybe they
| migrated my email address or emailed me about it but nope.
|
| Then comes circular system where if you forgot X you need Y and
| if you don't have Y you need X and links on pages that always
| lead to admin.google.com...
|
| There was no place to find / get help from google. Blogger
| seems like the information there is wrong / hasn't been updated
| / abandoned. Just links that ran in circles.
|
| I found the old registrar they partnered with and got them to
| help.
|
| With Google as far as I could tell there was no way to resolve
| the issue in a situation where I"m even trying to give them
| money (granted a nominal amount).
| xemoka wrote:
| Yep, similarly here. eNom successfully "extorted" $300 from
| me due to it. My fault ultimately in the end though. But it
| was a stressful couple days, and eNom and Google partnership
| soured my view of both of them. I no longer do business with
| eNom.
| reflectiv wrote:
| What happened, if I may ask? I use both enom and
| google...so, I am curious...
| RileyJames wrote:
| Just guessing, but the "extortion" fee's are likely due
| to renewing the domain after it has 'expired', during one
| of the last chance renewal phases.
|
| https://help.enom.com/hc/en-
| us/articles/115003360647-Renew-E...
|
| https://www.enom.com/kb/kb/kb_1487-last-chance-renew.htm
|
| There is a whole process via which domains expire, they
| do not simply become available to register upon their
| 'expiry' date.
|
| Full process is outlined here: https://tee-
| solutions.com/index.php/our-blog/127-domain-name...
| duxup wrote:
| That's a bummer, they just moved it to an enom account
| (understandable) and charged me the usual renewal fee.
| Seenso wrote:
| > It makes me realize that Google's no humans policy -- is it a
| policy? -- is actually a strength here. My domains purchased
| through Google are safe from social engineering because, well,
| there are no humans to contact to ask them to manually move
| domains.
|
| I'd suppose that goes both ways. If someone does find a way to
| steal a domain that's managed by Google, who are you going to
| contact to get it back?
| 0xff00ffee wrote:
| AWS Route53 user chiming in here. I have IAM accounts and soft-
| token 2FA, and I like how minimal the R53 panel is. This makes
| me feel like I have a handle on things because there are so few
| paths to make changes. It also makes me worried I'm missing
| something. 7 years and no hacks (that I've detected). Knock on
| wood.
| indigodaddy wrote:
| So according to the article, there is:
|
| 1) "registrar lock" - a service that requires the registrar to
| confirm any requested changes with the domain owner via whatever
| communications method is specified by the registrant.
|
| 2) "registry lock" - with a registry lock in place, your
| registrar cannot move your domain to another registrar on its
| own. Doing so requires manual contact verification by the
| appropriate domain registry.
|
| So... I assume the "lock thingy" within most registrars'
| interfaces (I'm familiar with the one within Namesilo, the
| registrar I use), is the less restrictive "registrar lock" ?
| Operyl wrote:
| Yes, generally the lock you see is the simple registrar lock.
| gist wrote:
| > had already protected their domain with a "registrar lock," a
| service that requires the registrar to confirm any requested
| changes with the domain owner via whatever communications method
| is specified by the registrant.
|
| Wrong. That is not true. Although some registrars might 'confirm
| any requested change' that is neither ubiquitous or required by
| ICANN etc.
| xoa wrote:
| DNS takeover is a huge issue, but some kinds of mitigation like
| Registry Lock (as opposed to _Registrar Lock_ aka
| clientTransferProhibited) also seem to be fairly inherently
| pricey. It requires multiple actual humans involved, like for
| .com having the right person actually pick up the phone at the
| registrar and get in touch with Verisign. Cloudflare offers it
| for example, but only for their enterprise class Custom Domain
| Protection [1] service, which they explicitly describe as "high
| touch" or "very manual", since the whole point is that it's a
| fully offline/out-of-band communication requirement.
|
| In principle it seems to me that there could be a "per-incident"
| price model that would more accessible to more general DNS users
| who setup their core domain DNS and touch it once a decade, where
| a flat upfront $200 payment (spit balling) enables Registry Lock
| and two uses, after which the fee must be paid again for more.
| The idea here is that you'd directly be paying the $100/hour or
| whatever it costs a couple of engineers to take time for this
| each time, on the logic you'd be using it very infrequently. This
| would avoid ongoing subscription costs which might be easier to
| justify for non-enterprises, while still being feasible for a
| registrar. I don't know of anyone who does this though.
|
| A lot I think ultimately really does come down to the registry
| itself and their specific security practices, as well as
| fundamental tensions between stopping alterations by unauthorized
| people while enabling recovery by authorized-but-forgot-password-
| or-token-broke-or[...]-people. Supporting hardware factors for
| example is great, but if support can just override them that's a
| hole. Conversely there needs to be some fallback procedure for if
| a token breaks (maybe a super long key written down and put in a
| vault, maybe based on payment information). Some methods can be
| real footguns too, my current registrar for example offers IP
| address/range restriction options, but it's not hard to see how
| that could come back around to bite you in the butt in an
| emergency if not used quite carefully. It's one of many tough
| problems due to the ongoing primitive state of electronic
| authentication I guess.
|
| _Edit to add_ : useful direct quote on Register vs Registry Lock
| from their initial enterprise-only CloudFlare registrar launch
| [2]:
|
| > _" Many registrars support Registrar Lock, which prevents the
| registry from altering information unless the lock is explicitly
| removed. The problem is, if an attacker compromises your
| registrar account, they can unlock it and make whatever changes
| they want._"
|
| > _" Registry Lock prevents changes by any registrar until the
| lock is removed. Unlocking at the registry level requires out-of-
| band communication between the registrar and Verisign (the global
| registry operator for several top-level domains), and is thus
| very manual. Since most registrars are volume operations, it's
| very difficult to find one that takes the time to literally pick
| up the phone and call Verisign every time someone makes a change
| to their DNS settings."_
|
| So yeah I'm sure that stops attackers real well, but not exactly
| scalable. "[I]f you're an organization where losing your domains
| would be a front-page story..." indeed!
|
| ----
|
| 1: https://www.cloudflare.com/products/registrar/custom-
| domain-...
|
| 2: https://blog.cloudflare.com/introducing-cloudflare-
| registrar...
| Animats wrote:
| For really important domains, there was MarkMonitor, the high-end
| registrar. But they've been acquired by an analytics company, so
| now it's necessary to wait a few years to see if they are still
| trustworthy.
|
| It's useful to trademark your domain name. That gives you a very
| likely win if things ever get to the ICANN dispute process.
| jjeaff wrote:
| Cloudflare has an Enterprise registry service. If I remember
| correctly, you can create the ruleset that must be followed
| before allowing a transfer.
| RL_Quine wrote:
| MarkMonitor are really dull to listen to, hours of upselling
| from them for pointless services has been my experience.
| james_pm wrote:
| PM at a large, retail domain registrar here.
|
| Registry Lock isn't something most retail registrars will offer,
| because generally, the vast majority of registrants don't really
| need it. It's not something you can just put into your domain
| management panel and roll out to everyone because of all the
| hoops required once enabled.
|
| That said, Brian Krebs does need it on his domain(s) for obvious
| reasons - his domain is a massive target for hacking - and so
| it's enabled on his domain with specific procedures around how
| updates happen when required which I won't get into.
|
| Beyond Registry Lock, the best way to secure your domains is to
| have them in an account with a random username (prevents guessing
| to aid in social engineering vs. "firstlast" or "flast"), a
| strong password and 2FA. Perhaps consider a unique account email
| address that you only use for that registrar account since losing
| control of that could result in losing control of your entire
| domains account and all the domains in it (assuming you didn't
| use 2FA).
|
| On the Registrar side, look for one with good protections to ward
| off social engineering against the account and domains. In our
| case, we have a system that requires the account holder's
| specific consent (obtained via account email) to have a support
| person view personal information or access the account.
| fierro wrote:
| This does not seem like a sound philosophical security posture
| -- that only domains who are "massive targets for hacking"
| should use Registry Lock.
| james_pm wrote:
| It's one of the situations where registry lock is a useful
| tool with appropriate trade offs. It's far from the only one.
| tialaramex wrote:
| Why? It's about threat models.
___________________________________________________________________
(page generated 2020-01-24 23:00 UTC)