Re: [Firebird-devel] crypt plugins

[Aleksey K. <kar...@cm...>]

"Alex Peshkov" <pe...@in...> wrote in message
news:415...@in......
>
> The reason is simple. It's easy to protect your network connection from
> sniffers using any tool you like. But currently it's impossible to
> protect from 'select user_name, password from users;', no 3-rd party
> software will help you. Any user can read hashes of all others. We can
> solve this problem only inside firebird, for example, making hashes
> harder to brutforce.

As always, there is no need to reinvent the wheel. The problem of secure
authentication has been addressed by security protocols such as Kerberos or
NTLM. Using such a protocol will completely hide the details of password
hashing algorithm, data encryption, etc.

The work on using OS-integrated security protocols was planned to develop in
Yaffil, but due to some reasons, both objective and subjective, only the
initial research was done.

Secure authentication will require the following development:

1. Modification of network protocol to allow transmission of authentacation
handshake packets both with sealed/encrypted data packets and negotiating
security capabilities supported.
2. Interface to OS-provided (or external librarires) security components.
3. The format of user identity information and mapping to database users.
4. Handling of group membership and mapping it to the existing authorization
method (SQL roles) or developing a new group authorization model.
5. Configuration, both on client on server.

It is should be clear that the problem of "stealing the security database"
has no software solution. If an attacker can steal the security database, it
is likely he can steal any other file as well, including the database files
itself. Which hashing algorithm is used is therefore irrelevant. For secure
database there should be the physical security arranged on the database
server.

Thus, there are two subjects in the network conversation : the client and
the server. The authentication (establising of trust relationship) is
performed between them (mutual authentication is reasonable), but not
between the client and the database. Thus, it seems that controlling
security on per-database basis seems questionable.

> >
> > Vulcan supports any number of security databases.  Your scheme is
> > useless in version 3.  But since there is no reliable way to compare
> > two Windows filenames (which is the source of endless database
> > corruptions), your scheme doesn't even work in version 2.
>
> Current isc_expand() seems to give reliable results for existing files.

There is, actually, a reliable method to check if two files are the same on
Windows, at least on the local disks.
However, it has little sense in the described situation because you address
the effect but not the cause.

Regards,
Aleksey Karyakin