How are passwords stored in Firebird v3.0.x?

[Wavey Maple]

Hi all,

In order to respond to a security questionnaire for our product which is using Firebird v3.0.x in a client-server configuration in SuperServer mode, we need to answer how passwords are stored.

Specifically, how are they encrypted in storage (eg AES256)?

Any and all details would be most appreciated.

Best regards,

David

[Attila Molnár]

Passwordsare not stored. Hash of password is stored, no encryption. (Cannot recover password form security3.fdb)

[Wavey Maple]

Thx Attila. I should have been more clear, as I am aware that passwords are not stored but their hash is.

So what I am asking is what is the hashing algorithm (eg SHA-256) used in Firebird v3.0.x?

David

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/08cd9b5e-5f58-49d4-b529-4df8735016f1n%40googlegroups.com.

[liviuslivius]

Hi

It depend on your plugins configuration.

1. Legacy

2. SRP

3. SRP256

Look at link:

https://firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-new-authentication.html

Regards,

Karol Bieniaszewski

-------- Oryginalna wiadomość --------

Od: Wavey Maple <wavey...@gmail.com>

Data: 09.09.2022 08:21 (GMT+01:00)

Do: firebird...@googlegroups.com

Temat: Re: [firebird-support] Re: How are passwords stored in Firebird v3.0.x?

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/CANNHrU6XuNLjhcpJgADku-0XL4jyOpzqNyzha4W1mYsL6R9%2B7g%40mail.gmail.com.

[Dmitry Yemanov]

09.09.2022 09:43, liviuslivius wrote:
>
> It depend on your plugins configuration.
> 1. Legacy
> 2. SRP
> 3. SRP256

IIRC, SRP always uses SHA-1 for password hashing, but may use either
SHA-1 or SHA-256 (3.0.4 and onwards) for the client proof calculation.


Dmitry

[Mark Rotteveel]

That is an oversimplification. The server stores a verifier derived from
the password using SHA-1, but this is not a direct hash of the password.
Instead, a salt + password is hashed, and a verifier is calculated using
a generator to the power of the password hash, modulo a large prime.

This verifier is then used as part of the authentication in a way where
the client does not need to send the password as part of authentication,
but uses modular arithmetic so both server and client arrive at the same
session key, which they then verify by exchanging a proof.

See also http://srp.stanford.edu/design.html

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Mark Rotteveel wrote 09.09.2022 13:28:
> That is an oversimplification. The server stores a verifier derived from the
> password using SHA-1, but this is not a direct hash of the password. Instead, a
> salt + password is hashed, and a verifier is calculated using a generator to the
> power of the password hash, modulo a large prime.

But the salt is stored right next field so there is no significant
difference: the brute force attack on the password is not more costly than with
an ordinary hash.

--
WBR, SD.

[Mark Rotteveel]

You're missing a step there. The verifier is *not* the hash of salt +
password. The verifier is a modular exponentiation, using the hash as an
exponent, which is a relatively costly operation.

As an aside, Firebird uses H(salt, H(user, password)), where H is SHA-1.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Mark Rotteveel wrote 09.09.2022 15:02:
>
> You're missing a step there. The verifier is *not* the hash of salt + password.
> The verifier is a modular exponentiation, using the hash as an exponent, which
> is a relatively costly operation.

Yes, but g is constant so calculation of logarithm is needed only once. After
that you can directly brute-force x that as you said is just a double SHA-1
which is hardware-accelerated. I.e. the overall security is still defined by
length of the password only.
SPR is good not because of secure storage of credential but because of
invulnerability to MitM attack.

--
WBR, SD.

[Mark Rotteveel]

Correction: H(salt, H(user, ':', password))

This is similar to the use of SRP in RFC-5054, which states the
following regarding the use of SHA-1:
https://datatracker.ietf.org/doc/html/rfc5054#section-3.4

"""
3.4. Hash Function Considerations

This protocol uses SHA-1 to derive several values:

o u prevents an attacker who learns a user's verifier from being
able to authenticate as that user (see [SRP-6]).

o k prevents an attacker who can select group parameters from being
able to launch a 2-for-1 guessing attack (see [SRP-6]).

o x contains the user's password mixed with a salt.

Cryptanalytic attacks against SHA-1 that only affect its collision-
resistance do not compromise these uses. If attacks against SHA-1
are discovered that do compromise these uses, new cipher suites
should be specified to use a different hash algorithm.

In this situation, clients could send a Client Hello message
containing new and/or old SRP cipher suites along with a single SRP
extension. The server could then select the appropriate cipher suite
based on the type of verifier it has stored for this user.
"""

And https://datatracker.ietf.org/doc/html/rfc2945#section-4 (the RFC
describing SRP-3, Firebird uses SRP-6a) states:

"""
4. Security Considerations

[..]

SRP has been designed not only to counter the threat of casual
password-sniffing, but also to prevent a determined attacker equipped
with a dictionary of passwords from guessing at passwords using
captured network traffic. The SRP protocol itself also resists
active network attacks, and implementations can use the securely
exchanged keys to protect the session against hijacking and provide
confidentiality.

SRP also has the added advantage of permitting the host to store
passwords in a form that is not directly useful to an attacker. Even
if the host's password database were publicly revealed, the attacker
would still need an expensive dictionary search to obtain any
passwords. The exponential computation required to validate a guess
in this case is much more time-consuming than the hash currently used
by most UNIX systems. Hosts are still advised, though, to try their
best to keep their password files secure.
"""

(though keep in mind that was written 2000)
--
Mark Rotteveel

[Mark Rotteveel]

I think you're underestimating the computational cost of generating the
rainbow table for the modular exponentiation.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

That said, replacing the user hash with PBKDF2, scrypt or bcrypt, with a
high iteration count would probably improve that, but that would require
a new user manager, authentication plugin, etc.

Mark
--
Mark Rotteveel