Seguridad de la base de datos de Firebird 2.5.2

[[Chris]]

Empezado por Delphius

Si la seguridad de la base de datos fuera tan pésima que la comparas con el anticuado Foxpro entonces ¿Cómo me explicas que un hospital de alta complejidad haya decidido emplear Firebird en lugar de Oracle? ¿Cómo me explicas que el gobierno de Brasil deposite tanto su confianza en Firebird? Por mencionar sólo dos ejemplos.

Te invito a leer el paper Firebird File and Metadata Security que puedes encontrar en el sitio de documentación de Firebird y después vienes ¿OK?

Saludos,

A esto le llamo una antipática y odiosa bienvenida.

En pasadas ocaciones que he mencionado mejoras que quería ver en Firebird con respecto a la seguridad fuí criticado. Acá en este Club hay grandiosas personas. Pero también aveces te encuentras con opiniones molestas y ruidosas. Gente que se cierra en sus ideas, que por haberse aprendido todo el manual deja de ver las posibilidades fuera de ese manual.

@Kiranov muchas de tus incetidumbres de seguridad también las padecen otros motores de DB. Para solventarlas, a cómo te han dicho, lo importante es la seguridad fisica y virtual del servidor en dónde esté la DB.

Firebird tiene otras fallas o faltas de seguridad aún no mencionadas:
* En autenticación nativa de Firebird, el servidor solo utiliza los primeros 8 carácteres de la contraseña. Inclusive la contraseña predeterminada masterkey no es evaluada complemente. Esto no es una característica, es un bug que viene desde Interbase (eso creo). El equipo de Firebird no lo ha reparado por temor a romper la retro compatibilidad.

* Firebird no ofrece un protocolo de transmisión de datos por TLS. Los datos viajan en texto plano y la autenticación se hace por medio de una encriptación básica que deja mucho que desear si la comparas con TLS.

Muchos dicen: "Esperen a FB 3.0 y verán!" pero hasta donde recuerdo esa versión está planeada desde hace 5 años más o menos. No lo digo en mal plan. El equipo de desarrollo de Firebird es pequeño y seguramente tendrán muchas cosas por hacer. Lo que quiero decir es que no te creas el cuento de que Firebird 3.0 está por salir y esa versión resolverá tus incertidumbres de seguridad.

Saludos!

[Casimiro Notevi]

Empezado por Chris

Muchos dicen: "Esperen a FB 3.0 y verán!" pero hasta donde recuerdo esa versión está planeada desde hace 5 años más o menos.

Hombre, hace 5 años (si las cuentas no me fallan) estábamos con la versión 1.5 y después han salido la 2.0, 2.1 y 2.5
Ahora mismo la 3 es la siguiente que toca, no hay otra que se intercale, por lo que puede que este mismo año esté. Incluso ahora mismo puedes descargar la versión de prueba para testearla.

Una duda: ¿qué base de datos usa TLS sin "ayuda externa?

[[Chris]]

Empezado por Casimiro Notevi

Una duda: ¿qué base de datos usa TLS sin "ayuda externa?

Talvez me equivoqué en esa. Me parece que fue por el 2008 cuando se anunció por primera vez el roadmap para FB 3.0.

Un ejemplo de DBs que usan TLS/SSL sin intermediarios son PostgreSQL y MySQL

Saludos!

[Casimiro Notevi]

Está bien, aunque supongo que tampoco es un problema para quien quiera más seguridad, puede usar zebedee, por ejemplo.

Personalmente me gusta que la BD esté lo más libre de carga posible, y el cifrar/descifrar información para enviarla por red no me parece que sea algo que deba hacer la BD, pero bueno, que tampoco lo veo mal, aunque no creo que lo usara aunque dispusiera de esa opción.

El caso es que firebird no lo usa para transmisión de datos, aunque para "autenticarse" sí que usa ssl/tls, al menos eso es lo que entiendo de esto:

Firebird has inherited a low security environment from Interbase. There is no means to encrypt connections and client authentication uses weak password based authentication. SSL/TLS could be used to improve both areas. Four levels of use are proposed, controlled through the configuration file and/or on a per user basis:

1. No SSL/TLS i.e. the current situation

2. SSL/TLS used to authenticate the server to the client and encrypt the subsequent connection.This is the typical https mode of use and makes use of X.509 certificate based authentication. A PKI is required. However, this does not have to be a paid for service and in most cases a local PKI based on OpenSSL should suffice.

3. SSL/TLS is additionally used to authenticate a client to the server. The client certificate must be signed by a Certification Authority recognised by the client.

4. In addition to authenticating the client, the common name component of the client certificate is used as the "username" and no password is required. This provides strong certificate based authentication of the client.

Most, if not all, of the above functionality already exists in external libraries and is used in ways, similar to the above proposal, by projects such as Sendmail, Dovecot, MySQL, Apache, Racoon, etc.

[[Al González]]

Empezado por Chris

Acá en este Club hay grandiosas personas. Pero también aveces te encuentras con opiniones molestas y ruidosas. Gente que se cierra en sus ideas, que por haberse aprendido todo el manual deja de ver las posibilidades fuera de ese manual.

Comparto el comentario que le haces al buen Delphius, Chris. Pues sí, podría decirse que ese es el lado "malo" de una comunidad altamente incluyente, participativa, tolerante y libre de expresarse. Lo peor es cuando por unos cuantos buscapleitos, mucha gente de gran valía opta por alejarse.

No pienses que me refiero a ti, Delphius, aunque harías bien en ser más amable con los compañeros.

Creo que debemos seguirle apostando a la madurez y al crecimiento ético de cada integrante del foro. Sólo así mejora cualquier grupo social.

Un cordial saludo.

Al.