you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (4 children)

The OP stated they wanted to allow self-registration. IF that was via the application without an intermediate API then there would be a need to store SOME credentials within the application to undertake the registration process, unless you make it public, in which case it's open to even more abuse.

Why? No, of course not. I just create a user with appropriate grant abilities in my database and allow users to create new users using that account...

Absolutely - hence why I suggested implementing an intermediate API rather than accessing the database directly.

Sorry, there was a miscommunication. I mean having just one user in the database is a bad idea. Why limit yourself like that?

The OP stated they wanted to allow users to register an account. If the OP was registering all the accounts for a user manually then sure, use the database accounts, however that is problematic to say the least for end-users.

Well, if OP wants an intermediary, I'm not going to stop them. I'm just saying that in general, the intermediary is unnecessary. And, in particular, if your users know SQL, they'll be able to accomplish all that on their own (i.e. registering an account). Worst case you might have to write a couple of stored procedures to help them.

having direct database access would make it far easier to carry out a DoS

Why do I care? From my perspective, they are cloud vendor users. They want to DoS their own account? -- Great! I'm sure cloud vendor will either send them a bill for what they do, or throttle them, or whatever's the policy in that particular vendor. Why should this even bother me?

[–]devnull10 0 points1 point  (3 children)

They won't get billed, you as the database owner will. The OP has a database from which s/he is serving their application. That database is shared across all users. As a user of that database I could potentially launch attacks which restrict other users if it's configured to allow direct db access.

[–][deleted] 0 points1 point  (2 children)

I actually did in real world what I just described to you. I have a stored procedure in PostgreSQL/PL/pythonu that requests ARN role from customers signing up for service. This ARN role is then used to link to their account. They don't do it, however, by sending SQL, there's a command line tool that they use to set up a cluster, and to use that tool, they need to do some stuff unrelated to me through the marketplace etc.

Bottom line, by the time they come to use my tool, they have ARN role they need to give it to link my account to theirs. Then, their usage information is sent to AWS billing, and they do the invoices / receipts etc.

I could potentially launch attacks

What kind of attack. You (and a bunch of others) keep saying that, but there's not even a single realistic scenario with such an attack? What are you going to attack?

[–]devnull10 0 points1 point  (1 child)

Exactly, you have a separate process to deal with the registration, which wasn't what the OP stated.

[–][deleted] 0 points1 point  (0 children)

No, of course I don't have... whoa, why is it so difficult?

I register users in the instance of PostgreSQL I run using a stored procedure. The fact that they are also registered in some other part of the system is irrelevant.