Este foro usa cookies
Este foro utiliza cookies para almacenar su información de inicio de sesión si está registrado y su última visita si no lo está. Las cookies son pequeños documentos de texto almacenados en su computadora; las cookies establecidas por este foro solo se pueden usar en este sitio web y no representan ningún riesgo de seguridad. Las cookies en este foro también rastrean los temas específicos que ha leído y la última vez que los leyó. Si Ud. continúa navegando, entenderemos que acepta todas las cookies.

Se almacenará una cookie en su navegador, independientemente de la elección, para evitar que se le vuelva a hacer esta pregunta. Podrá cambiar la configuración de sus cookies en cualquier momento utilizando el enlace en el pie de página.

El foro antiguo se encuentra accesible desde https://foro.gambas-es.org en modo de solo lectura.

Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5

Sobre el uso de cifrado de datos en mysql y tipo de campo en la mísma.
#1

Hola buenas, como estan todos los grandes compañeros de Gambas, espero que esten bien, tanto tiempo sin verlos, estoy sorprendido con esta nueva web!, esta bien pava Wink

Estoy trabajando mucho con desarrollo web, visual basic.net y tambien volviendo a usar a mi hermoso gambas que estoy como oxidado Big Grin , quisiera consultar algo compañeros, y es con el cifrado de base de datos en mysql o digamos mariadb, el tema es, si es necesario cifrar todos los datos de los usuarios en la web? o solo los datos mas delicados?, por qué pregunto esto, bueno porque pienso que dependiendo del uso de un algoritmo de cifrado como AES este necesite usar en sus campos de cifrado del tipo BLOB y esto podría volver la base de datos muy pesada y lenta.

También quiero aprovechar a preguntar a ustedes que son los que mas experimentados es qué tipo de algoritmo de cifrado es el mas recomendable y que permita trabajar eficientemente a una base de datos, de verdad muchas gracias por sus ayudas y abrazos.

El conocimiento te hace libre, fomenta el desarrollo, la expansión y el poder.
    ¡Gracias!
#2

Hola, Jousseph y bienvenido de nuevo

Dependiendo del tipo de aplicación y de los datos con los que vayas a trabajar, así será necesario encriptar sólo la contraseña de autenticación del usuario o algún dato sensible adicional, por ejemplo la numeración de una tarjeta de crédito, etc. Generalmente, solo se suele encriptar la contraseña, ya que suponemos que sin ella no se podrá acceder a los datos almacenados en la base de datos (siempre que el acceso a la propia base de datos sea seguro).

Dicho esto, para usar AES por ejemplo con 256 bits de encriptación, no se requiere nada más que un campo de texto de longitud que podría variar de tamaño según la complejidad y longitud de las contraseñas, pero que no creo que supere en ningún caso los 256 Bytes (o caracteres). Usar campo de texto o blob ya es a tu elección y no creo que ralentice la base de datos para el tamaño que va a tener ese campo.

En cuanto a la elección del algoritmo de cifrado, yo creo que AES es el más seguro que puedes encontrar dentro de mysql/mariadb y la única precaución que debes tener es que la "llave" o password de encriptación esté siempre segura cuando la vayas a usar o por ejemplo que sea generada automáticamente en cada uso, aunque eso implicaría guardarla de algún modo para poder desencriptar después.

Saludos

Por favor, usa el corrector ortográfico antes de pulsar el botón 'Enviar'
    ¡Gracias!
#3

Esta bien, muchísimas gracias señor jguardon, un gusto volverlo a ver.

El conocimiento te hace libre, fomenta el desarrollo, la expansión y el poder.
    ¡Gracias!
#4

Buenas, al margen de lo que ha comentado @jguardon, que es correctísimo, comentarte que si estás realizando desarrollo web, como nuevas implementaciones la DB ya no tiene la responsabilidad de encriptación de contraseñas y usuarios (bueno creo que ni en web ni en escritorio) pero bueno eso siempre irá a gustos.
La postestad de la encriptación y/o seguridad repercute siempre en una clase de Backend, dependiendo de la arquitectura que estés utilizando (DDD, TDD, MVC, Hexagonal, Onion Layer o N-Layers). Para web al margen de dicha encriptación se realiza una doble validación entre cliente-servidor-peticion, viajando en la misma el Bearer Token que se genera al pasar usuario y pass, de forma que cada solicitud va acompañada de este token que te identifica unívocamente en la sesión.
Y como ha dicho Jguardon el peso no será problema, una DB se hace más pesada o con cuello de botella por una mala sentencia antes que por número de registros.
A modo de ejemplo, si analizas el timming entre una query con subquery que tenga un LIKE sin indice verás que tardas mucho más que en hacer una select bien indexada con un = en 5 veces más registros.
Debes analizar la escalabilidad de tu proyecto web, si va a ser exponencial el nº de registros entonces quizás deberías descentralizar, utilizar broker de comunicación, realizar microservicios y no proyecto monolitico. Existen muchas soluciones antes de que la DB se vea afectada.
Saludos.
    ¡Gracias!
#5

Buenas, al margen de lo que ha comentado @jguardon, que es correctísimo, comentarte que si estás realizando desarrollo web, como nuevas implementaciones la DB ya no tiene la responsabilidad de encriptación de contraseñas y usuarios (bueno creo que ni en web ni en escritorio) pero bueno eso siempre irá a gustos.
(26-01-2021, 11:38)calcena escribió:  La postestad de la encriptación y/o seguridad repercute siempre en una clase de Backend, dependiendo de la arquitectura que estés utilizando (DDD, TDD, MVC, Hexagonal, Onion Layer o N-Layers). Para web al margen de dicha encriptación se realiza una doble validación entre cliente-servidor-peticion, viajando en la misma el Bearer Token que se genera al pasar usuario y pass, de forma que cada solicitud va acompañada de este token que te identifica unívocamente en la sesión.
Y como ha dicho Jguardon el peso no será problema, una DB se hace más pesada o con cuello de botella por una mala sentencia antes que por número de registros.
A modo de ejemplo, si analizas el timming entre una query con subquery que tenga un LIKE sin indice verás que tardas mucho más que en hacer una select bien indexada con un = en 5 veces más registros.
Debes analizar la escalabilidad de tu proyecto web, si va a ser exponencial el nº de registros entonces quizás deberías descentralizar, utilizar broker de comunicación, realizar microservicios y no proyecto monolitico. Existen muchas soluciones antes de que la DB se vea afectada.
Saludos.

Hola un gusto señor Calcena, como esta, el proyecto lo estoy desarrollando sin frameworks, estoy trabajando con php, jquery y bootstrap y por supuesto con mis css a lo normal clásico, la web como va a ser un servicio a clientes, pienso que si debe ír cifrada!, o quizá sólo los datos sensibles, estoy agregándoles lo que es el filtrado de información en el servidor para evitar la inyección sql y los posibles ataques con csrf utilizando token con cifrado aes en php para identificar si la información enviada son propias de mis formularios, es primera ves que voy a implementar una web ya que como de costumbre las desarrollaba solo para red interna con su sistema de escritorio, por ello me centro en la seguridad buscando información en algunos sitios para captar que mas puedo agregarle, si usted sabe de que mas debo cuidar mi web, se lo agradecería, ante todo, muchas gracias por su consejo.

El conocimiento te hace libre, fomenta el desarrollo, la expansión y el poder.
    ¡Gracias!
#6

(23-01-2021, 13:34)jguardon escribió:  256 bits (o caracteres)

Creo que te referís a Bytes no a bits.
    ¡Gracias!
#7

(29-01-2021, 10:19)tincho escribió:  
(23-01-2021, 13:34)jguardon escribió:  256 bits (o caracteres)

Creo que te referís a Bytes no a bits.

Correcto, ha sido un desliz  Confused . Un caracter tiene 8 bits, que corresponde a un Byte.

Lo corrijo, muchas gracias

Por favor, usa el corrector ortográfico antes de pulsar el botón 'Enviar'
    ¡Gracias!


Posibles temas similares…
Tema / Autor Respuestas Vistas Último mensaje

Salto de foro:


Usuarios navegando en este tema: 1 invitado(s)