--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@n...>
wrote:

>snip<
> both the existing scheme and something useable. Any thoughts on
> requirements or ideas on an API would be appreciated.
>
> My personal feelings are that security information belongs in a
> database, and that storing a SHA hash of passwords makes the most
> sense. There are other secure hashes. Does anyone has strong
>feelings on the subject?

I'm in agreement with eumir_camara- I'd like to be able to put users
and passwords into each database. But I want to allow them in the
central file as well (which is necessary anyway to have users who can
work with any database on that server and create new ones.)

Even better would be the ability to declare to the database which
table I'm putting my users in, and which fields are Name, Role and
Password (optional- it would be fine if it were the first three.)
Alternatively, I'd want to make it easy to add fields to
the "official" user table. But the goal is to have one table where I
can edit the list of users using the database, where I can associate
them with related records as well as edit their passwords through my
own code, using normal tools rather than API calls.

I would have the users in the database's local table have precidence
over the users in the system's security table, so that if I don't
have a "SYSDBA" user in my local table, the one in the system will
work, but if I do, and the local one has a different password than
the system's SYSDBA, then my database would be secured even if copied
over to a different machine with its own SYSDBA.