| Subject | Security pieces |
|---|---|
| Author | Claudio Valderrama C. |
| Post date | 2001-01-19T06:09:29Z |
I don't know if this helps in some way or not, so feel free to ignore this
posting. It seems that we are discussing at least 3 levels of security in
latest days:
- Network authentication, remote login or choose another name: the server
cannot trust the client without some restrictions. A variety of protocols
have been suggested. Anyway, the pw traveling in clear text or already
encrypted with the IB algorithm is not a great thing. Also, the environment
variables that allow the user and pw to be assumed implicitly in each
connection may be a flexible feature for single user apps or development,
but they stink in C/S applications where it seems possible that every user
can log in by taking advantage of those variables defined in the server
machine. The backdoor supposedly was closed (more on another email) although
I would like to hear comments on how Borland solved the chicken and egg
problem really.
- Data transmission: some people want the whole data communication to happen
encrypted, too. I think we can leave this issue to a third party package.
There's already one that I've linked from my site but I have no experience
with it. At least in a LAN or in a web server requesting data from the db
server, is it mandatory to have encrypted data exchange as a built-in
feature on the server? Personally, I would try by all means to not put the
db engine in direct contact with the Internet, so data scrambling is not my
top priority, since it will be traveling inside an intranet.
- Command verification inside the engine: anyone can declare and call a UDF,
anyone can create databases, anyone can define an external table, anyone can
manipulate with all freedom a generator, etc. I don't know why anyone is
allowed to wipe out rdb$pages and rdb$formats! For example, after making
rdb$pages empty, you can enjoy this msg when you try to validate the db:
Database file appears corrupt () - wrong page type - page 0 is wrong type
(expected 5571640, found 4204452).
C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com
posting. It seems that we are discussing at least 3 levels of security in
latest days:
- Network authentication, remote login or choose another name: the server
cannot trust the client without some restrictions. A variety of protocols
have been suggested. Anyway, the pw traveling in clear text or already
encrypted with the IB algorithm is not a great thing. Also, the environment
variables that allow the user and pw to be assumed implicitly in each
connection may be a flexible feature for single user apps or development,
but they stink in C/S applications where it seems possible that every user
can log in by taking advantage of those variables defined in the server
machine. The backdoor supposedly was closed (more on another email) although
I would like to hear comments on how Borland solved the chicken and egg
problem really.
- Data transmission: some people want the whole data communication to happen
encrypted, too. I think we can leave this issue to a third party package.
There's already one that I've linked from my site but I have no experience
with it. At least in a LAN or in a web server requesting data from the db
server, is it mandatory to have encrypted data exchange as a built-in
feature on the server? Personally, I would try by all means to not put the
db engine in direct contact with the Internet, so data scrambling is not my
top priority, since it will be traveling inside an intranet.
- Command verification inside the engine: anyone can declare and call a UDF,
anyone can create databases, anyone can define an external table, anyone can
manipulate with all freedom a generator, etc. I don't know why anyone is
allowed to wipe out rdb$pages and rdb$formats! For example, after making
rdb$pages empty, you can enjoy this msg when you try to validate the db:
Database file appears corrupt () - wrong page type - page 0 is wrong type
(expected 5571640, found 4204452).
C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com