liviusliv...@poczta.onet.pl wrote:
> Hi,
> what security risk do you see with context vars?
> Context vars are stored on server side - what i am missing
> here?
> This so secure as secure is sending password at conection
> start time ;-)
> I you secure transmision what problem?
> regards,
> Karol Bieniaszewski
As Alex pointed out, passwords aren't normally sent at
connection time.
If the security of this depends on secure transmission of
normal data then the approach adds a not-insignificant burden,
and suddenly it's not simple any more. Will this requirement
be remembered with every change that might compromise it?
Anyone monitoring the server (MON$) can read the context
variables of all users. And while this should only be admin
there are issues even here:
* administrators should not know users passwords
I know that in the real world of lax security - and the
ability to trace ALTER USER commands - this is not a
completely realistic expectation with Firebird.
But it should be!
When an administrator changes a user's password the user
should be strongly encouraged to reset it to something new.
Yes, the admin can change it to something they know and
pretend to be that user, but if they don't know the
original password they can't set it back again, so they
leave a trail.
* administrators monitoring the database may be showing
other people certain things on the screen, do we really
want users passwords sitting up there next to everything
else, for anyone walking past to see? It might even be
the admin password! (If we assume you want the admin to
be able to run the same procedure.)
* the password becomes something readable by query from
the user, which leaves various forms of abuse or accident
possible depending on the application and environment.
* while we know that no developer ever accidentally makes
mistakes that gives unexpected access to a system, there
being a long history that proves this conclusively, if
this should even happen then having passwords (even
possibly even the admin password) in context variables
becomes a big potential exposure.
But, put most simply, it all comes down to this: The more
redundant copies and transfer of secure information that a
system makes, the more it opens itself to error, accident and
abuse. As such, any requirement to do this should be looked
on with suspicion.
--
Geoff Worboys
Telesis Computing Pty Ltd
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
