Based on your description, I'm guessing your users would supply a username/password you give them,
but then the application would access the database as some single username? Having done this (it's
a bit late for us to turn back now on this project) ...

a) using the unix 'strings' command, someone could pull the default username/password out of your
application. assuming that were the sysdba username, then any client could be used to access the
database, change constraints/tables, drop the database, etc. (may also be possible to intercept
enough information via 'tcpdump' to do the same, even without the executable?)
b) if you ever code your application incorrectly, it's an extra security blanket to know your app
won't be running as a user with more privileges than absolutely needed. there's still a risk of
doing something you didn't intend to (but that is still allowed by constraints, such as inserting
way too much data or delete a whole lot) ... but nothing "too" serious.

We defined a second user for our app to 'be', without ownership of tables or metadata-changing
access of any sort. We're still vulnerable to someone pulling -that- username/password out of the
application, and just playing with the data as they see fit. None of our users are that bright, and
our app is purely for in-house use. Still, it's something to consider.

I'd recommend using the database's security to its fullest extent, filling in the gaps as needed.
Use actual users defined in the database, don't hard-code anything, and if you need extra per-user
information, create your own tables for that inside the database. But first try to use database
security for table-level access, and anything you can think of. And constraints. Lots and lots of
them. (Did I mention we were lazy about those too?)

I hear you can write your own security plugins, though I'm not sure how easy that is, how much
access you get (granularity) nor where the documentation is. The idea here would be (if un-lazy
enough) to make the database server actually do absolutely all the security checking you'd
otherwise use your application for. That makes sure that even if someone can log in with their own
credentials, using random software, they still can't do more than they usually could (and to boot,
it'd be less easy.) You might be able to use constraints/triggers for security-ish stuff. I haven't
seen much in the way of examples that might check to see who you are in a trigger, then throwing an
exception if you don't have privs. If anybody could contribute such an example, that'd be nice.

Yes, we did it all wrong, but you don't have to.

-Philip

---------- Original Message -----------
From: Ray Jenkins <reofax@...>

> I know I must have left my senses, but I am wondering why use
> something besides the username SYSDBA in our software.
>
> I can see why you wouldn't want the users to be using SYSDBA all the
> time and can definately see the reason to change the password.
>
> But, I am having trouble seeing any reason for the software to use a
> different username to access the database.
>
> feeling like a newb already,
> Ray

------- End of Original Message -------