2 ms·

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. Th

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.

andrewstuart 12y ago
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.
- danellis 12y ago
  OP called for "a specialized database". I was talking about using the same kind of database.
  - jacquesm 12y ago
    He is the OP.
  - derefr 12y ago
    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.

andrewstuart 12y ago

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.

danellis 12y ago
OP called for "a specialized database". I was talking about using the same kind of database.
- jacquesm 12y ago
  He is the OP.
- derefr 12y ago
  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.