Re: dumb++ security

From: Ross Oliver (reo@roscoe.airaffair.com)
Date: 02/21/02 

From: reo@roscoe.airaffair.com (Ross Oliver)
Date: 20 Feb 2002 23:14:20 GMT

Buffy The Cache Coder <buffcoder@hotmail.com> wrote:
>These programs read username/password from a text file in a
>user's home directory. This information is used into Oracle
>or Sybase database. If the user doesn't have permission
>to connect to either database, the program doesn't run.
>
>The powers-that-be will be satisfied if I can have something
>slightly better than looking up a username and password from
>file. They want something in house for now and can
>be run on NT too. So what I need is a simple solution,
>but I'm lost for ideas. Anyhelp?

I assume your product is some sort of report generator, and you
want to allow your batch programs access to the database, but
assure that the user who runs the batch jobs can't use the
username and password to perform unauthorized database actions.

The need to grant batch jobs access to a database is a fairly common,
and is frequently "solved" in just the way you described: hide the
username and password in some file, and hope no one notices.
As you have surmized, this is a Bad Idea.

Here is a method I have used to address this problem:

1. Create a new database user "a" whose sole purpose is to
   submit requests to run your batch programs.

2. Create a table "b" and grant the user "a" access to that table,
   and nothing else.

3. Create a trigger and a stored procedure to invoke your batch
   jobs whenever a record is inserted into the table "b".

4. Create a new batch job "c" that uses the user "a" username and
   password to insert a record into table "b". A user can then
   run your batch jobs by executing job "c".

You will still have to store the username and password for user
"a" in clear text somewhere for batch job "c" to use it , but the only
access this username and password will provide is the ability to
invoke your batch jobs. Denial-of-service protection is left as
an exercise for the reader ;-)

Ross Oliver
reo@tech-mavens.com

Relevant Pages

  • Re: dumb++ security
    ... >to connect to either database, ... username and password to perform unauthorized database actions. ... The need to grant batch jobs access to a database is a fairly common, ... Create a trigger and a stored procedure to invoke your batch ...
    (comp.security.misc)
  • Re: Pathname to access and usernames in shortcut
    ... >> network drive (for maintenance reasons initially, ... >> using usernames but no passwords. ... change their passwords within the access database (they won't know how ... >> gets the current username from the system and then calls access (via the ...
    (microsoft.public.access.security)
  • Re: Getting NT User Login Names from Access 2000 or 2003
    ... time, i can recreate it in the blank database, per all your other thoughts. ... In the table setup and adding the bound SomeOtherField field to the ... >> form, plus binding the orig MyUserName field, defaulted to fOSUsername, to ... using the username field as ...
    (microsoft.public.access.formscoding)
  • Re: hashed password and UsernameTokenManager
    ... Sami ... > The reason for further hashing and salting the already hashed password is ... > you have the database. ... >>> to also use hashed password text to construct the username token... ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Login issues
    ... Depending on the computer or username, ... There is not way to enter to the database using ... If I enter as usual from my computer, the FM server automatically ... Perhaps someone changed your script, or the user name on your computer, or the default account in File Options. ...
    (comp.databases.filemaker)