Guardar información personal (nombre, dirección, teléfono, correo electrónico) en la base de datos MySQL

Lamento decepcionarte, pero tu modelo de seguridad no funciona en la realidad. Permítame explicarlo usando un flujo de trabajo de ejemplo de un usuario que edita su perfil.

1. El usuario inicia sesión, navega a su página de perfil e ingresa sus datos para guardarlos.
2. Al guardar, necesita su clave simétrica para AES. Esto puede ser ya sea una contraseña global, en uso para todos los datos privados en su servidor o una contraseña propiedad del usuario que contiene su contraseña en algún momento (ya que todos los demás datos están disponibles / almacenados públicamente)

2a: Contraseña global

Siempre será fácil comprometer el uso de una contraseña global, sin importar dónde la almacenes. Supongamos que su servidor solicita la contraseña global de un segundo servidor (que también puede ser comprometido) siempre que un usuario (administrador o no) acceda a ella. Esto se puede detectar fácilmente ya que un atacante conoce su punto final interno. Si lo codificas, puedes leerlo fácilmente.

2b: Contraseña propiedad del usuario

Esto debe contener una información tan secreta que nadie con acceso al servidor puede leerla, como la contraseña (ya que se supone que solo se almacena dentro de un hash). De esta manera el usuario podría leer & guarde sus datos privados, pero usted, como administrador, tendrá la misma oportunidad que un atacante y no podrá leerlos ni editarlos.

¿Y ahora qué?

Es tan simple como decepcionante: un atacante siempre tiene la misma cantidad de posibilidades que usted (el administrador), por lo que no hay manera de guardar los datos perfectamente guardados en cualquiera de ellos. Lo que se debe hacer como una práctica recomendada es el concepto de necesidad de saber : solo guarde los datos que realmente necesita que su servicio esté disponible en todo momento, como su correo electrónico, nombre y fecha de nacimiento. Todos los demás datos pueden guardarse y cifrarse con un token de propiedad del usuario y usarse en tiempo de ejecución (¡solo!) Para descifrar los datos para ofrecerlos al usuario como su dirección para un proceso de compra. Esto reducirá sus posibilidades con respecto al análisis de datos, pero la seguridad de los datos y el análisis amplio nunca se agradarán entre sí de todos modos.

Si almacena Información confidencial del cliente, asegúrese de mantener el posible Riesgo de perder a muchos Informaciónes confidenciales a la vez bastante bajos. En general, es una buena idea consultar las Reglas de normalización de la base de datos, por ejemplo, en su caso, crearía una Base de datos con una ID y un Nombre como clave principal y agregaría las ID de las Tablas Correo, Dirección y Teléfono, y también el Tipo de membresía como clave extranjera.

Ejemplo:

TBL_Customerdata Nombre de ID FK_ID_Mail FK_ID_Address FK_ID_Phone FK_ID_Membership

TBL_Membership FK_ID_Membership Type Amount

TBL_Phone Número de teléfono FK_ID

TBL_Address FK_ID_Address Street House Housepart FK_ID_PoSt País

TBL_Post FK_ID_PoSt Ciudad del código postal

TBL_Mail FK_ID_Mail Adress FK_ID_Provider

TBL_Provider

FK_ID_Provider Provider

Si usa el Esquema anterior, evitaría que un atacante acceda a muchos Datapieces a la vez. AES parece estar bien para el cifrado.

Espero que esto ayude.