I'm trying to find a way to automate our company's domain transfer process, and one of the first steps requires validating the domain's EPP code before we initiate the actual transfer.
Currently, we're having to login to our domain registrar and manually use their domain EPP validation tool. They don't provide any API access for this and setting up what would essentially be a macro to automatically log in and run the tool is too fragile for our requirements. The code for their tool is closed source so I'm unable to see how they're validating the EPP codes.
Is there any other method for validating domain EPP codes? I've searched StackOverflow and Google but have been unable to find any information on how to do this.
By "EPP code," do you mean the temporary transfer auth codes that registrars usually send via email (or show in their web UIs)?
For reference: https://en.wikipedia.org/wiki/Auth-Code
(EPP codes can also be these status codes, fwiw: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en)
I'm also not quite following what you mean by "validating" the codes?
An EPP (Extensible Provisioning Protocol) code, also known as an 'Authorization Code', 'Auth-Info Code', or 'transfer code', is typically generated by the domain registry or registrar and can expire. It will normally be between 1 - 32 character long, and will contain at least 1 number, 1 letter, and 1 special character.
Depending upon the Registrar, the EPP code might expire after a certain period of time to avoid security vulnerabilities. If the domain owner requires the EPP code after expiry, they must request or generate it via their domain registrar.
Because the EPP code is used like a password to verify ownership of a domain, it should be secure and inaccessible to third parties, therefore a third party cannot explicitly validate it.
You can validate the syntax of it, because it is in the EPP specifications, but it is quite lax, so won't help you much (it is just an XML normalizedString, there are no restrictions on content or length basically). You may get further constraints detailed by the specific registry, so you need to peruse their documentation or ask them directly (if you can get access to that because it is restricted to registrars most often), but that will differ anyway from one registry to another.
I guess, even if you don't want that as answer, since you say:
They don't provide any API access
and it means to be a problem for your business, then you either need to find another provider more suitable for your needs, or pressure your current one to give you the tools you need.
If you were a registrar, with direct connection to registry, you could, for some registries, assess if a given authInfo (the official name from the specification, that is then often code "auth code" or "epp code" or things like that, but no point in defining new terms) from customer does indeed work,
as a domain:info EPP command can specify an authInfo and hence done on a domain you don't sponsor yet, the results from registry will change depending on if the authInfo is correct or not.
Anyway, even as a reseller, if you start a transfer, you have to provide the authInfo. If it is wrong you should get an error immediately, as the registrar sending the command to the registry to transfer the domain will also get an error immediately. And if there is a success instead, it seems the domain has started the transfer and as such proves the authInfo was correct.
Related
Say a company successfully applied to IANA to make .bob a Top-level domain and the company now operates the registry of every domain with .bob as the TLD. If the comany is under an authoritarian government with a track record of manipulating the Internet infrastructure, can a domain target.bob be hijacked so that it gets resolved to a server the government owns, instead of going through the name server the domain owner specified? Will DNSSEC help?
Yes, technically any node in the DNS tree can pervert everything below. But, especially at the TLD level it will be akin to a move with a nuke, it will be seen quickly and draw lots of actions and consequences.
You may want to go back at the Verisign Sitefinder fiasco. Not exactly the case you describe but very similar. It generated two consequences:
contractually, gTLD registries at least because under contract with ICANN are now prevented to do things like that
technically, there are safeguards, see for example root-delegation-only in bind that means exactly that (for both root and TLDs) to ensure there is no "hijacks".
And DNSSEC can help, but in a limited way. Because in your case even if the domain is properly delegated and DNSSEC secured before the hijack, it means the registry has and published the DS record, so once the hijack happens those DS records can be hijacked as well, or just removed, and end resolvers will see the change but just with that can not detect really a problem nor work around it.
Note that in your case of "authoritarian government" they don't even need to go to the registry and the authoritative nameservers. They can force things at the recursive state also, forcing ISPs. And it completely happens today, and even in non authoritarian government: various names are, by law or judge, forbidden to be resolved. Sometimes it happens at registry side (see Microsoft seizing domains recently - and regularly - at https://arstechnica.com/information-technology/2021/12/microsoft-seizes-domains-used-by-highly-sophisticated-hackers-in-china/), and sometimes at resolver (this the recent judgment against Quad9 a big public recursive nameserver service: https://www.quad9.net/news/blog/quad9-and-sony-music-german-injunction-status/)
Also, side technical note: in the DNS a dot does not mean necessarily a delegation, and both sides can be administratively and technically handled by a single party. For example gouv.fr and fr are technically and administratively handled by the same entity, there is no delegation nor hijack.
I have been trying to figure out how to programmatically check if a gmail account exists. Almost all searches lead to validation services like xverify or EmailOversight where you validate any email address on a cost per request basis.
What I am interested in is a way to do that directly, without a middleman. In other words, how do these validation services do it? Seems like there should be some sort of an API that google provides for those guys to ping to see if an email address is valid.
Please note that I am not interested in checking the syntax of an email address. So I am not looking for some kind of a regex solution.
Also, what I have tried is connecting to gmail.com MX record domains (e.g. alt3.gmail-smtp-in.l.google.com) and trying to extract the validity of an email address by running simple SMTP commands. Essentially what this article suggests: https://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/
But I cannot do that for any kind of volume. Gmail will start blocking your connection attempt after a certain number of connections. So that method is not scalable. That's why I feel like there has got to some other way.
*******ADDED*********
Here is why this question is different from How to check programmatically a email is existing or not
That post provides only one solution, and it's one I have already tried - using SMTP commands. Google will NOT allow to do that on any kind of scale. If I only had to validate a few emails, then that would be a sensible solution, but if I have 10,000, it is not.
I work for a bank and security is a major concern. We are currently using a cname on Adobe's collection servers (e.g. stats.bank.com) in order to have Adobe serve first party cookies on the bank.com domain. Our security council now says we shouldn't provide Adobe with a new SSL cert for stats.bank.com because it is too risky and if stats.bank.com is compromised and someone attacks our customers then we our liable due to it being our brand and all the cookie data is exposed as well as leaving customers open to malware attacks. So we have the following options:
Bring reporting in-house
Set up a filtering proxy operating as “stats.bank.com” that front-ends the relevant Adobe service
Go back to Adobe's 3rd Party solution 2o7.net namespace
Use a different 3rd party namespace on adobe's servers (e.g. stats.bk.com)
Here are our thoughts:
1) Too expensive
2) We thought it was a good solution but then the cost came up. It seems like it would be very costly to build that type of infrastructure due to the volume of calls.
3) Adobe's 3rd party namespace blocked too much.
4) Seems to maybe be a solution but still concerned about 3rd party being blocked.
I was wondering if anyone has had to deal with these type of security concerns and what the solution was. Also what are the drawbacks of solution #4 in particular?
There is no personally identifiable or personal information at all in Adobe's tracking cookie.
Before I say anything else, based on what you have said, let me just say that I think your security council is either misinformed about Adobe's tracking cookie or else blowing things unrealistically out of proportion.
The visitor id (s_vi) cookie is just that: a cookie that contains a visitor id value. Here is an example of what the cookie value looks like:
[CS]v1|2A933F6C05079103-6000110EA000D3F3[CE]
The value has nothing to do with a visitor's personal information or data or anything like that. It is a randomly generated value that sticks to the visitor for as long as the cookie persists.
Cookies that are created for any custom coding you do are NOT the same thing
See, this is where I think some people may be confused. Here is a common scenario to explain: member id tracking. A visitor when they first come to your site is anonymous. They login to your site and now your site knows who they are.
From a tracking perspective, it is common to have a prop and/or eVar that reflects this. So on pages/hits where you don't know the visitor, you wouldn't pop anything, or maybe you'd pop some default "anonymous" or "unknown" or "logged out" value. Then when the visitor logs in, you pop the prop/eVar with a value that your site recognizes as a member or account id.
Maybe this id is their email address. Maybe it's a randomly generated value. Maybe it's a username. Point is, it's something to uniquely identify the visitor within your own site's system.
So let's say you write code where upon login, you pop prop1 with the value and then you decide to make use of Adobe's getAndPersist plugin. This plugin basically takes a value and puts it into a cookie and then retrieves the value each time the plugin is called. The idea here is that you only have to do the work to come up with the value from your end one time and then Omniture will persist it from there. This is particularly useful for when you want a value to pop for each page/hit but may not have easy access to replicate or scope the logic to all areas of your site, particularly across subdomains.
So now you have a cookie set by Adobe Analytics code from this. This has nothing to do with the s_vi cookie at all.
Firstly, it is something you explicitly set, even if it is just to get the ball rolling. Secondly, the value is not stored in the s_vi cookie; it is stored in a separate, 1st party cookie.
Even if you have FPC tracking, it is still set in a separate cookie. The actual cookie name depends on what plugin you are using (or using Adobe's s.c_w cookie write function yourself), and also whether or not you are using the combined cookie plugin (in which case it will be put in s_sess or s_pers, depending on what you set the expiration to be)
Now.. if you do have FPC implemented, you can obviously overwrite that cookie with your own value. And you can obviously make that value whatever you want it to be, including something personal to the visitor. But that's not Adobe's doing; that's your doing.
The overall point here is that whether you make the visitor tracking 1st party or 3rd party, that's a completely separate cookie that has nothing to do with personal data.
You may have custom coding that contains personal data and you may put that data into cookies, even using Adobe Analytics functions, but that is not the same thing. It will always be first party cookies (impossible for js to write 3rd party cookies), and the cookies will always be separate.
Nonetheless, the s_vi visitor id may be used to indirectly get personal data
I'm sure the next thing heard will be something along the lines of "But it doesn't matter, it's a unique id for the visitor, and it's in Adobe, and so is this other data, and you can use the visitor id to find the data within Adobe!"
And this is true. However...
Firstly, in order for there be personally identifiable data to be found within Adobe Analytics, you have to explicitly put it there. For example, you have to set stuff like:
s.prop1='jon doe'; // name
s.prop2='4321 1111 1111 1111'; // credit card #
s.prop3='04/2020'; // exp date
s.prop4='123'; // security number
I don't think I should have to tell you that this is a supremely bad idea, but point is, this isn't Adobe collecting that info, it is you doing it. And it's not in the s_vi visitor id cookie, nor can it ever be (again, unless you have fpc imp and decide to explicitly overwrite the cookie with those values..).
So that data, along with the visitor id, goes off to Adobe servers. So there's the next road block: getting access to the data within Adobe. The bad guy would have to have a Adobe Analytics user account under your company, and it would have to have proper permissions to gain access to that data.
And even then, Adobe doesn't actually expose the visitor id value in the reports. So in order to get the data associated with a certain visitor id, you need access to data warehouse, or to be listed as a supported user and request raw hit logs from ClientCare.
I guess the overall point here is that all by itself, that visitor id isn't really the dangerous thing. It's not the personal data, and being able to make use of it to find specific data associated with it would involve acts of extreme foolishness about storing personal data on Adobe servers in the first place, as well as gaining access to said servers/interfaces.
All that aside..
Okay, so maybe you don't care about all of that stuff above. Or maybe none of that convinced your security council to budge. You're moving away from Adobe FPC imp and that's all there is to it. So let's talk about the options you listed and your concerns about them.
Bring reporting in-house
You said this is "too expensive." You know, I gotta be honest here.. this is a bit laughable, coming from a bank! But seriously..
Perhaps you thought it too expensive from a building-from-the-ground-up-from scratch perspective? If this is the case, have you considered options for ones that have already been built, that you can put on your own server and customize or build off of from there?
Webtrends offers this. Frankly, I loathe Webtrends as a tracking solution, but it does offer ability to put it on your own server (last I heard, anyways). Also, Piwik is a really good open source solution.
Filtering proxy
I'm not quite sure what you mean by this. This sounds a lot like FPC tracking.. except having a means to scrub all requests of personal data before it goes to Adobe? Well if that is the case, I'd go back to the point about sending personal data to Adobe in the first place. But okay, maybe you aren't doing that, but want to have an extra measure of precaution just in case; fair enough.
So maybe you setup a service on your end that sends all requests to stats.bank.com and it scrubs stuff and maybe even has a mapping of values (like visitor id). In principle, this isn't really a complex script, so again I have to wonder why cost is an issue, especially coming from a bank.. but whatever..
Sticking with Adobe's 3rd party cookie implementation
If you want to go back to 3rd party cookie tracking using a domain owned by Adobe, instead of using the default 2o7.net domain, I suggest you consider their new(er) 3rd party cookie implementation for Regional Data Collection.
Rolling your own 3rd party cookie implementation
As far as I am aware, Adobe does not offer any kind of service involving you specifying a domain name for them to purchase/own and collect data from as a 3rd party implementation.
The closest service to this is the first party cookie tracking. So, you if you have www.bank.com, normally you'd specify something like stats.bank.com (something on the root domain) and that's FPC tracking.
However, you can tell Adobe to use for example stats.someotherdomain.com (assuming you own and control it) and they can implement FPC tracking for that domain. Then, when you implement tracking on www.bank.com, that effectively becomes 3rd party cookie tracking.
The caveat though is that you still own that domain, so I can only assume that on some level, you will still be liable for it (I'm not a lawyer). However, maybe this will be enough to appease your security council, worth bringing it up to them.
I add that, under the Adobe General Terms of Service, "customer agrees not to collect, process, or store any Sensitive Personal Data using the on-demand or managed services." Hence, if you are collecting any data that can be traced back to an individual -- e.g., email address or phone number -- you are violating the TOS. Therefore, the response to security concerns can be, "Exposing customer PII is a violation of our terms of service and so we don't do it."
I'm in charge of an app that uses the internet to transfer data between sites, and some customers are being awkward about paying, so we need a mechanism that will allow us to cut off the service of non-payers. I'd like to protect against the admin people using firewalls to block off our checks, but conversely I'd like to give some allowance for our company web site disappearing for some reason and not being accessible.
The scheme I'm imagining is:
server makes twice daily check to web page using a URL like:
http://www.ourcompany.com/check.php?myID=GUID&Code=MyCode
This then returns a response that contains either nothing of interest, or the GUID and a value.
GUID=0
That zero indicates that the server should stop operation. To make it work again, the server will check every 5 mins for the same info, until the value matches what it thinks the code that it passed in should be transformed to.
This scheme makes sense to me, but the question really is how to protect against blocking. Given we know we must have internet access, how long should we continue to operate without being able to get the response from our web server? Is something like 14 days and then we just shut it off anyway the best way?
The solution I used in the end was pretty much as I suggested. Yes, it is defeatable using tools outlined here, but it is better than nothing.
The app checks daily to access a web site that contains a control file encrypted using public key encryption. It decrypts in memory, and if it finds its GUID, then it must match a code. To disable the operation, the code is set to 0 (zero) which will always fail. When disabled, it checks every two minutes to allow rapid restoration. There is also a manual mechanism to generate a code that will work for a week in case of server trouble.
The code will allow up to 14 days without connecting to the server before it takes this as a deliberate attempt to block it. After 10 days, it shows an error message which asks them to contact support.
This method is really easy to circumvent: just use a local dns server to point www.ourcompany.com to the local machine, or use a http proxy. Then the user can return whatever response they want to the program.
Assuming the user hasn't circumvented the check, how long you are to continue to operate without confirmation is a business decision and not a programming decision.
A user can use a tool such as OWASP WebScarab to change values on the fly to subvert your security model. You need to include something more difficult such as requiring a secure channel, comparing public key and so on.
Before I begin, I guess this may not be strictly programming related but I think it's definitely related to web programming.
I'm after a domain for a startup project and I notice that it is currently on "clientHold" registrar status. From the research I've done this suggests that it is in dispute either due to an ownership dispute, a payment dispute or someone has suggested the domain is used by spammers/scammers. The whois data seems similar to other spammer details I've seen posted, and at the very least is largely anonymous.
The domain is registed with XIN NET who appear to be notorious for supporting spammer domains. I'd love to just contact the registrar but their site copyright is 2006 and I can't find any appropriate contact path. Even then, they are probably too large to actually deal with and my Chinese skills are limited to Google Translate.
One thing to note is that the expiry date for the domain isn't for a few months.
My questions are:
Is there any rule on how long a domain can be held in clientHold status?
Does the "last updated" whois data indicate when the domain was initially put
on clientHold?
If the site is put up for deletion, will it enter a pending deletion status
for some time or is it likely to just drop instantly?
Any details on how this stuff works would be appreciated.
your best bet if you really want it is to use a backordering system like godaddy has. If after a few months it still hasnt become available, you can move your backorder to another domain.
In my expirience, rarely will you ever see a domain in this status become available.
clientHold just means the domain won't resolve.
You can find now at https://icann.org/epp an explanation of all possible statuses, tailored for end users. It is mostly ok but applies only to gTLDs. ccTLDs may use the same statuses, or others, or with different semantics so it all depends on which TLD you are in.
So back to your questions:
Is there any rule on how long a domain can be held in clientHold status?
No. clientHold is under control of the registrar sponsoring currently the domain name, and which should be put on behalf possibly of end client. So a domain can be in perpetuity in this state for various reasons. There could be also serverHold which has the same consequences but is solely under control of the registry and can be used during disputes or domains confiscation.
Does the "last updated" whois data indicate when the domain was initially put on clientHold?
Maybe, maybe not. There could have been any other updates on the domain (change of contacts, change of nameservers, etc.) so the date really shows the last update without knowing what that update was.
If the site is put up for deletion,
This is unrelated to clientHold, except in the sense that some registrar can put a domain under this status at, or after expiration, as a last attempt to get attention from the registrant that it has to renew the domain at the registrar or else loose it. Make it temporarily not resolvable anymore has, from experience, the consequence of having some registrants, who did get already multiple email notifications of the impending expiration, suddenly realise they do have something to act on quickly.
For the way gTLDs are deleted/expired, refer to ICANN gTLD lifecycle at https://archive.icann.org/en/registrars/gtld-lifecycle.jpg
It is similar, but not identical, in ccTLDs, so again it depends on the TLD you are in.
will it enter a pending deletion status for some time or is it likely to just drop instantly?
Again, depends on the TLD. But in gTLD it is redemptionPeriod (typically 30 days) after the registrar sends the delete command to registry, and then pendingDelete (typically 5 days) after that before the registry really deletes it finally from its database, after which it should come back as generally available for a new registration.