It's a completely misguided concept. Database security doesn't mean having a completely different database implementation for each type of data you're using. There are already plenty of things you can do without going crazy like that:

* Put the user database behind a microservice

* Use a different connection with different credentials and put appropriate permissions on the tables

* Store password hashes using bcrypt, scrypt or PBKDF2

Not to mention that if you write a new database, what you're actually writing is brand new exploitable bugs.

Misguided? The microservice you suggest is precisely what the post suggests. The post suggests that the code of the microservice ensures that the correct hashing is used and that the data is stored correctly.

It's puzzling that you say this is "completely misguided" and describe exactly the same thing.

OP called for "a specialized database". I was talking about using the same kind of database.

I don't know if you're really thought about it, but a microservice API is a database.

A Postgres database, for example, with correctly-limited user permissions set, and a good set of views and triggers and stored procedures, is exactly equivalent in power and flexibility to putting some blobs of Sinatra API-routing and model code in front of Postgres-used-as-a-dumb-object-store.

RDBMSes were always meant to do, on their own, exactly what microservices are doing now. That's why they're so much more complicated than just being dumb object stores: you can encode within a RDBMS schema the constraints of the model, and the valid transformations you can make to any given piece of data, to create an API exactly as narrow and high-level as a given user needs.

I think it was just some quirk of their use in mainframe contexts which lead to their auth protocols never being hardened to work on the public Internet, which meant people started to believe there was something inherently insecure about letting users talk to an RDBMS.

There's not; a database, a real database, is a persistent micoservice server.

And now we're all the way around to reinventing them on top of themselves, but this time they're three separate process-spaces, random custom languages are required, and they don't understand questions phrased as relational algebra.

He is the OP.

The article is pretty unclear on some basic concepts, such as salting and hashing wrong. This is a pretty well solved problem with bcrypt and other framework-driven identity mechanisms.

And It should encrypt data internally really gives no protection other than physical theft of the disk drive, as in if the portion of the application is compromised that can access the data, the key is available at that point, and the attacker has free run of that corner of the universe.

My beta-quality Golang version of this with pluggable backends, including S3: https://github.com/nmcclain/glauth I would love suggestions/help.

Ned - would you mind replying to this with a list of the features specified in the blog post and a YES/NO to confirm which are supported by your code?

thanks

It should be accessible only via its specialised API which is designed to constrain the ways that it is accessed. YES - API is LDAPS.

It should not provide generalised database query functionality. YES - it only proivdes the subset of LDAP functionality necessary for authentication.

Its API should have password salting and hashing built in. NO - hashed but needs salting&scrypt.

Its API should throttle access with some sort of algorithm designed to prevent downloads of large quantities of user data. NO - todo.

It should encrypt data internally. YES (hashed not encrypted).

It should communicate only over encrypted connections. YES.

It should be distributed. YES.

It should not be run on any web server, should run "behind the scenes" and be accessible only via its API. YES.

It should include triggers and alerts based on uncommon access patterns or recognised nefarious access patterns. NO - todo.

It should have no other purpose. YES.