Does a domain alias give any security against hackers?

Question

We have an app which runs off of a private API. We have a server which hosts the API, as well as an admin panel where staff can log in and make changes to the app's content. The API and admin panel run on the same web domain. Let's pretend the domain is appname.com and the URLs are appname.com/api and appname.com/admin

Originally, there were no public web pages on the server or domain. However, we added a password reset page at appname.com/resetpassword so that app users who have forgotten their password can request a password reset email.

Immediately after we added the password reset page, the project head (who is not a technical person) became concerned that putting the password reset page on the same domain as the API and admin site could expose the server to hackers, who might not otherwise be aware of the domain since it has no other public pages. They asked that we put the password reset page on a different domain so that hackers wouldn't know how to find the primary domain.

This logic doesn't make sense to me, for several reasons:

1. I've never seen anyone else do something similar to this, although it's hard to think of direct parallels
2. The domain name of the backend isn't hard to guess even when there aren't any public pages on the site
3. If we add a public web site in the future, it would logically be located at the same domain, at which point the domain would no longer be a secret anyway
4. Any hacker sophisticated enough to break through the security measures on the server could easily find the API URL, and thus the site domain, by following packets sent from the app.

However, the project head is adamant that the password reset page cannot be on the primary domain. What strikes me as the easiest solution is to set up a domain alias, something like appname-passwordreset.com, which points directly and exclusively to the password reset page. However, will this buy us anything? appname.com and appname-passwordreset.com would have the same IP address. Would using the latter alias realistically prevent a hacker from finding or breaking into the server?

Note: I realize that an alternative is to only let the user request a password reset email from within the app. However, the password reset email has to have a link to a webpage, thus taking us back to the original problem

Answer 1

It's absolutely trivial for an attacker (or security researcher, or hacker) to find out what the hostname is for requests going to the API for your app. There's multiple techniques that can be used to figure this out.

1. Decompile the application and look for the hostname in the source. Perhaps you obfuscate the app and all the strings?
2. MITM the traffic between their device and your API and look at the requests. But perhaps you do TLS with certificate pinning?
3. Passively sniff the traffic and look at the SNI value in the ClientHello. Ok, you could configure the SSL library not to use SNI.
4. The hostname is in the certificate that's sent back in the clear. But I guess you could fake that if you're doing your own hostname verification.
5. Passively sniff the DNS traffic when your app starts making a connection.

At this point, you could get silly and use hardcoded IPs, or DNSCrypt, or other techniques, but the attacker can also use a rooted device and dump the memory of your application, or just figure out hostnames from IPs based on the traffic you're sending.

If hiding your hostname is the difference between being compromised and not, you've already lost and just don't know it. Thinking that hiding the hostname is useful is just lulling your project head into a false sense of security.

Answer 2

Your head's point doesn't make much sense to me. Just explain him that given that your app runs off of an API, its server was exposed even when there were no public pages on it. Any attacker could have performed a MITM attack to see where the app is requesting data from, therefore the server would've been exposed anyway. It's not so much of a deal for an attacker to find out where the API is located, whether it's from a public page in the server, or in the app. If a hacker wants to reverse engine it, figuring the API out is almost trivial with the proper tools (see mitmproxy). Rather than focusing security on trying to hide your hostname, which is a waste of time, it'd be much better to design a secure API that can only be used with proper authentication (i.e. OAuth)