You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
For example, we have many databases on different servers.
Some procedures could get data from other database by "execute statement on external data source".
We have the same password for the same user in all databases.
But we have to store passwords in plain text because we must set parameter "password" for remote execution.
Will be useful to have an ability to authenticate user by password hash (for example, MD5 or SHA1), and to access current password hash through "current_password" context variable.
====== Test Details ======
Have questions related to Windows. Sent letter to Alex, 23.04.2020 10:00. Waiting for reply.
The text was updated successfully, but these errors were encountered:
Execute statement does not do magic, it works via the public Firebird API. So if this feature is going to be implemented, then anyone can steal the stored hash and use it to connect to the database instead of using the password. So what's the point?
If one can steal stored hash from the firebird server address space, he can steal a lot of other interesting things. So keeping passsword or it's hash in RAM on server is not security problem. But in FB3 there is no user password on server present in any form available for further auth - it's just not transfered from client, instead pair of session keys are generated on client and server, and that key's hashes are compared by server to check password correctness. I see the following ways to solve a problem with keeping plain passwords in SP:
- organize callback to client when execute statement is issued, letting secondary server validate password
- have a kind of trusted servers' group, in which security context from some server is trusted by others
But certainly not in 2.5 and sooner of all not in 3.0.
But after you connect to server you can store from client app info about user, pass and role in context vars
and retrive it in any place you want for execute external statment
And you do not need to store it as plain text then in procedurę body :)
But it would be insecure -- it assumes that password value would not be exposed by the trace logging of database context variable values (I believe this is already supported or an pending feature request)
Not exactly like was requested by Vladimir - but the problem raised by him is solved.
Added recently sample of plugin ExtAuth makes it not needed to pass login/password in execute statement on external if this authentication plugin is installed on all servers involved in data exchange and key specific for that group of servers is set on all them. See ~/examples/extauth/INSTALL for further details.