SecureDrop (and former Firefox) dev here. A few months ago I started working on a patch to support prompting users for an authenticated hidden service cookie in the manner of HTTP Basic Auth. [0] We require journalists who use SecureDrop to download submissions from an authenticated Tor hidden service, and bootstrapping that for them is currently a major UX pain point. [1]
The main difficulty was that there was not a clear way to communicate the HidServAuth info to the Tor Browser's running Tor process. AFAICT, that is not currently supported in the Tor control protocol. So an extension to the Tor control would be useful here. It would also be possible to edit the torrc, reload Tor, and have the TB wait for that, but that is a) incredibly ugly and b) probably prone to causing all kinds of fun problems. Haven't tried it yet.
How would Tor Browser learn about this reason for not being able to
connect/
tell Tor the authentication info? This is starting to sound like wanting SOCKS5 extensions to indicate different causes for connection failures in #6031 did.
My current patch waits for a connection timeout on a .onion, then offers a tab-modal prompt that says "A connection to a Tor Hidden Service failed. If you are trying to connect to an authenticated Tor hidden service, enter your authentication string below:". A SOCKS5 extension would be even better, to avoid annoying users who mistype onion's or who are trying to access an onion that is down. I included a "Don't ask again" checkbox but it would probably still be annoying.
Would be interested in hearing ideas about how hard it would be to extend the control protocol and add a SOCKS5 extension for connection failures, and if anybody is already working in those directions. I'll try to return to this patch when I have time in the coming weeks.
[0] https://trac.torproject.org/projects/tor/ticket/8000 [1] https://github.com/freedomofpress/securedrop/blob/develop/tails_files/README...