Ask HN: Dividing auth factors into separate internal services Thoughts?

One of the most likely to be hacked and most vulnerable portions of any web application is the attack surface that is directly exposed to the internet. This little idea came to mind because there are [sadly] regular issues with developers pushing potential security flaws into production. No software is perfect and the larger the project is, the more security holes are likely to appear.

So I was thinking of building single factor, physically separated authentication services on the assumption that even if a security flaw occurs on the webserver [e.g. Sql injection or the server just gets outright hacked in some fashion] the authentication servers will be intact. Obviously, they'll be able to attempt a brute force from the compromised webservers against the authentication nodes to attempt to guess password but I am figuring the odds of a very simple service having an easily exploited flaw if it sits physically separate from the webserver is worth the effort. Especially if I open source the services and get some people to look at them. General user data is still stored in the web application (e.g. everything but the email/password/otp)

Retains the Salt as each user will have a unique salt [for password hash, etc] and it'll be used to identify the user to the other services.

Emails are stored separately as they are an authentication factor and used in account recovery:

GET service/:salt/:email [pass/fail if email exists] POST service/:salt/:email [upserts a new hash/email combination]

Passwords are to be stored in a separate database cluster which responds to a very simple service:

GET service/:salt/:password [pass/fail if combination exists] POST service/:salt/:password [upserts a new hash/otp combination]

2nd Factor Authentication [ OTP ] will function similarly but stored in a separate database cluster.

GET service/:salt/:otp [pass/fail if combination exists] POST service/:salt/:otp [upserts a new hash/otp combination]