Support

You can't create an entire temporary backend URL for the same reason we decided to call the rename admin directory option forever beta and unsupported. We know it can work, except for a small minority of hosts where it's impossible and outside our control. Since this would be the same feature by another name we can't offer it for the same reason: it wouldn't work on all of the environments in which we want to support Admin Tools.

Regarding a temporary secret word... it's feasible but it may not be quite what you bargained for. The secret word is there to protect the backend login page from arbitrary access. Knowing the secret word doesn't guarantee that you are an authorized user. It is, however, a requirement to prove that you are an authorized user. Knowing where the Batcave entrance is doesn't make you Batman, Robin or Alfred. You also need the bat remote to open the secret passage. Likewise, just having the bat remote won't let you into the Batcave unless you know where its entrance is. I hope that makes sense; it did in my head as I was writing it :D The implied effect is that it's not a major problem if someone knows the secret URL but they don't have a valid username and password; they'll simply be locked out.

There is, however, a major security implication if we start making the secret URL tied to a user. Then the secret URL replaces the username and password for authentication. However, being a URL parameter, it needs to be fairly simple to avoid having it ignored by the server or triggering the server's protection. Therefore we'd end up with a feature that translates the problem of brute forcing a username and a complex password into the much simpler domain of brute forcing a relatively short code with a much more limited search space. This would take hacking a site from trillions of years (with a good, random, 64 character password comprised of lowercase, uppercase letters, numbers and all special characters available on your keyboard layout)  to something that can be exhausted within a few dozen years. Moreover, it'd be something stored in plaintext in the database. These implications are a big no-no.

Sort of inventing a parallel authentication method that involves a really long, random token there's not much we can do. Regarding the token, sure, it's on my radar – for Joomla 4. I contributed the Joomla API Token feature based on preliminary work I was doing on FOF 3 and it got accepted. Once we move to full Joomla 4 support, once Joomla 4 stable is released presumably at the end of 2020, I will indeed refactor the temporary Super User feature so it no longer gives you a username and password but a special URL with a token that's not to be found unencrypted in the database. I can even make it so that username and password authentication for that temporary user is actively disallowed. But, as I said, this requires a bit of support in the core which was thankfully merged in Joomla 4.0. Stay tuned – it will be another year or so before we can ship this kind of feature.