If it's "Whats your mother's maiden name?" and they let you reset it in the browser, it's a bug.
But if they send you an email (in my case to Gmail, that has 2FA turned on), then it is a feature, because then you'd be required to either 1) intercept the recovery email (and get the password reset URL) or 2) know the format of the password reset URL and just happen to guess mine after brute-forcing every possible link (assuming there is no timeout for the URL or anything else like that).
Have the customer provide an SSH/GPG public key, and store it with the account.
When a password reset is requested, encrypt a random string using said public key, and email it to the email for the account.
An attacker who may have breached your webmail is then reasonably unlikely to also have your private key to decrypt the string.
Follow the link (which didn't necessarily need to be encrypted) and enter the string you decrypted to reset the password.
On a related note: do any/many sites with 2FA, require the 2FA code to do a password reset?
With a 2FA code, you either a) use the same code they use for regular logins, or b) require them to find a way to securely store the (T|H)OTP secret and then add that information to a 2FA app when they want to do a password reset.
I realise the pubkey concept is more than most people would bother with (or even be able to get through on their own), and I think the first 2FA option is definitely better than no extra security at all on password resets, but my thought was about increased security for those who are particularly paranoid/security conscious.
Doesn't this just move the problem from "I forgot my password" to "I lost my private key"?
If you enable 2FA on an account with a service, and subsequently lose access to 2FA otp's (e.g. phone lost/wiped/etc) and lose access to (or never kept) the recovery codes, you generally lose access to the account.
This is similar, but with the benefit that you can keep the key secure by default - i.e. put a passphrase on the key and then store it wherever you like.
In reality, if you fail this "recovery" method, my next suggestion would be a billing based one (i.e. talk to a human, get confirmation of previous invoice details, what is being billed for, how it's paid for, etc)