[eluser]jedd[/eluser]
It's a nice idea, and it lets you store your security-related tables on a separate machine. Good for performance, but also particularly good for security, as you can impose stricter limits on that machine - limit by IP who can access it (your various VM's, say, that run the different user-facing apps), and also limit the interface down to a very tight set of API calls (if you want to go the stored procedure approach). Or just have an app running on that box that negotiates the updating and handing over of credentials.
You only hit the machine once per login or password change, so I don't see any performance issues to be concerned with.
I'd have a minor concern about the durability of your ACL to deal with all future applications. It'd presumably need to be painfully generic. Any changes required in the future would necessitate huge sociability testing against your extant apps.
The biggest problem - a corollary of the previous comment I guess - is that you now have a fabulously precarious single point of failure for your entire suite of apps. You'd probably want to look at a cluster of databases to serve this. VM's are cheap, though, so this is more a time & operations problem than a space or power one.
