Jim Starkey wrote:

>
> Alex, I hope you don't mind if I moved this back to the devel list.
>

You've moved to architect:), and without snipped details this is OK.

> Let's do a little analysis of the problem and potential solutions.
>
> It's reasonably well known that DES has been cracked in approximately 24
> hours with more or less off the shelf hardware. On the other hand, the
> hardware is exotic, expensive, and would require a great deal of
> expertise to program. Running on even very fast off the shelf PCs,
> cracking DES would probably take a couple of weeks. However, the 24
> hours is based on a 56 bit key. Firebird passwords are a maximum of 8
> characters and each character is almost always a letter, a digit, a
> hyphen or a blank, for an effective character set of 6 bits. So that
> gives us an effective key size of 48 bits, max. That reduces the amount
> of time for the specialized hardware to about six minutes and an
> ordinary PC to about three days. But any moron trying to crack a
> password is going to work by password length, so a seven character
> password will probably take the specialized hardware about 5 seconds and
> the PC a little more than an hour.
>
> The weakness is in the password length, not the hash. The fact that
> Firebird 2 computes the hash with SHA has at most a tiny linear effect
> on the computation required to crack a password.
>

Understood. It's becoming really interesting to compare SHA/DES from
this point of view - how many times longer will it take to crack SHA
than DES? I'l make an experiment and report results.

> If there were a mechanism in place to detect systematic attacks, things
> would be marginally better, but to the best of my knowledge, no version
> of Firebird detects or reports when it is under attack (please tell me
> if Firebird 2 has changed this).

If I've understood correctly, what you mean by systematic attacks, fb2
has half of such mechanism. It detects users/IPs, that cause too many
login failures. It blocks temporarily any logins for such users / from
such IPs. Nothing configured (i.e. number of bad attempts, blocked
period - all are constants set in source code). And nothing logged. I'm
open to any ideas concerning how should system under attack call for help.

> Making the user/password table
> inaccessible would be a help, but hiding it isn't worth the effort.
>

Why not worth? Even if we remove from fb2.0 code, preventing direct
access to security database, non-SYSDBA user will see nothing except his
own hash. But I suppose this particular hash is not very interesting for
him.

> The fact that the password hashes are available is certainly a problem,
> but if the system doesn't detect or report attacks, it doesn't make a
> lot of difference.
>

Should we treat an attempt to access remotely to user/password table as
an attack? If yes, may be it's better make it impossible once and
forever than call for help each time it happens?

> Now, putting that aside temporarily, it has been reported that there are
> somewhere between 4 million and 40 million compromised PCs on the net,
> inside and outside of firewalls. Any (or all!) of these could be
> running a password sniffer with an ethernet board running in promiscuous
> mode. Since Firebird, all versions, send passwords in clear or
> trivially obfuscated, it is easy game.
>

Not sure that things are really looking so bad. For example, PC on which
I'm typing this letter, is connected to switch, not hub. Therefore any
packet, send from it, can't be caught by sniffer, even if it is present
in my LAN on some box, sitting in the hub. During last 5 years dumb hubs
became mush less popular even in Russia. So if one thinks about
protecting from sniffers, he should simply replace hubs with switches.

Though, certainly, it doesn't solve a problem, when a packet with
pseudo-crypted password travels over public network.

> I don't think Firebird database security is any worse than other
> database products, but it is, well, pathetic.
>
> Here is the minimum that must be done:
>
> 1. The password table must be inaccessible to non-trusted users.

Done in fb2.0 except record about user himself.

> 2. Passwords must be transmitted with one-time session keys
> distributed with public key encryption

Requires protocol change, therefore, suppose, should not go into 2.0.
But for firebird 3.0 this is necessary. I remember your old suggestion
how it may be done without enlarging number of packets, needed for
initial client/server handshake.

> 3. The system must recognize when it is under attack, take defensive
> measure, and call for help.
>

I think this may be done in 2.0, but I have no idea - how does it call
for help? Should we add mobile phone number of SYSDBA to firebird.conf?

> Passwords are lousy security, and until a better technology is accepted,
> will always be the weak link. Given that we are obligated to support
> passwords for the indefinite future, we have to recognize and compensate
> for their weaknesses. A more secure hash of an insecure password isn't
> the answer.
>

Agreed.

> A short term easy to implement fix is to anchor accounts to what I call
> coteries -- sets of IP addresses from which a given account is valid.
> This won't stop your roommate, co-worker, or kid from attacking your
> account, but it will stop other remaining 99.9999% of the hackers.
>

It's really easy to implement. Do you think it's worth adding it to 2.0?