[JOUSSEPH]

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

Estoy trabajando mucho con desarrollo web, visual basic.net y tambien volviendo a usar a mi hermoso gambas que estoy como oxidado , 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.

[jguardon]

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

[JOUSSEPH]

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

[calcena]

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.

[JOUSSEPH]

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.

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.

[tincho]

256 bits (o caracteres)

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

[jguardon]

256 bits (o caracteres)

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

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

Lo corrijo, muchas gracias