Alex Peshkov wrote:

>
> Used by you to hold message repository fb1.5 is an awful thing from
> security POV. To get this table I've needed IbExpert and 5 minutes due
> to relatively slow connection.
>
> USER_NAME SYS_USER_NAME GROUP_NAME UID GID PASSWD

<details snipped>

> Certainly, *I* don't want to really break shared messages repository.
> But it's only techical problem to start DES-cracker against this list.
> How will we look, if our repository will be broken by hackers?
> I hope (don't want to test) that you use classic, not super, which may
> be easily killed by known BOF.
>
> May be it's better to use 2.0 for this purpose? At least you will not
> get this table from it and there are no *known* BOFs in it.
>

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

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.

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). Making the user/password table
inaccessible would be a help, but hiding it isn't worth the effort.

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.

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.

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.
2. Passwords must be transmitted with one-time session keys
distributed with public key encryption
3. The system must recognize when it is under attack, take defensive
measure, and call for help.

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.

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.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376