¿Debo cifrar los datos en mi servidor como una capa adicional de protección?

Question

¿Debo cifrar los datos en mi servidor como una capa adicional de protección?

#1 de Polynomial (4 votos)

0

Voy a crear una aplicación cliente-servidor que almacene la información financiera confidencial de un usuario en el servidor. Me gustaría cifrar estos datos para que, incluso si un pirata informático obtiene acceso al servidor, no pueda leer la información financiera del usuario. Los datos serían descifrados por el cliente con la contraseña del usuario.

Para dificultades adicionales, a un usuario se le puede otorgar acceso a los datos de otro usuario.

¿Es esto factible? Si es así, ¿hay una guía en línea que proporcione un ejemplo de los tipos de criptografía a utilizar?

Por ejemplo, estoy pensando que cada usuario debe tener una clave privada derivada de su contraseña y una clave pública correspondiente que se utiliza para cifrar sus datos en el servidor. Esta clave pública también se almacena en el servidor, de modo que si Alice quisiera darle acceso a Bob a sus datos, desencriptaría sus datos usando su clave privada, luego los cifraría nuevamente utilizando tanto la clave pública como la de Bob. Un problema con este enfoque es que si un pirata informático obtiene acceso a los datos cifrados, podría usar la "fuerza bruta" al intentar cada combinación de, por ejemplo, 8 caracteres como contraseñas para ver si esa combinación desencripta los datos. Por lo tanto, quiero hacer que el proceso de desencriptación sea tan lento que no sea práctico usar la fuerza bruta. ¿Existe tal algoritmo de clave pública-privada?

Editar: está bien, después de un poco de investigación se ha encontrado que hay muchos algoritmos hash (como PBKDF2) diseñados para ser lentos porque toman un parámetro de iteración que puede ser tan grande como quieras.

cryptography encryption

pregunta Mark 20.07.2012 - 07:22

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption

Descarga inexplicable Los mejores artículos sobre WPA / WPA2 [cerrado]

score 4 · Answer 1

Veo muchas fallas aquí:

Si una cuenta está comprimida, se revelan los detalles de todas las personas que están protegidas contra su clave privada. Esto pone la seguridad de los usuarios en manos de otros usuarios , que posiblemente sea la peor situación.
Los usuarios eligen contraseñas terribles, de las cuales ninguna función de derivación de contraseña puede guardarlas. Incluso si está utilizando un factor de trabajo en PBKDF2 o bcrypt que garantiza que un atacante no pueda calcular más de un hash por segundo, adivinarán contraseñas débiles como "letmein1" y "a1b2c3" después de menos de un minuto.
No puede cifrar datos de longitud arbitraria con RSA (clave pública / privada), por lo que necesita cifrar los datos con un cifrado de bloque, utilizando una clave sustituta generada aleatoriamente, luego cifrar esa clave con las claves públicas de los usuarios .
Su protocolo no proporciona información de autenticidad. Un atacante podría usar la clave pública de un usuario para cifrar un conjunto de información financiera falsa y luego insertarla nuevamente en la base de datos. Necesitaría combatir esto firmando los datos con la clave privada del usuario, lo que agrega complejidades adicionales cuando permite que otros usuarios también accedan a los datos.
Estás cifrando y descifrando mucho los datos, por lo que te vuelves más susceptible a ataques de canal lateral como DPA y ataques de tiempo . Tendrá que dar cuenta de esto y tomar contramedidas.
Como la información es financiera, tendrá que alojar su servidor en una instalación con cierta seguridad física.
Vas a necesitar usar una fuerte seguridad de transporte. No puede usar un certificado SSL antiguo, probablemente necesitará algo como un certificado EV que ejecute AES de 256 bits.
En general, es una mala práctica almacenar información financiera en una base de datos de cualquier tipo. Una solución más adecuada es un HSM .
No estoy seguro de la situación legal en su país, pero puede verse obligado a cumplir con PCI-DSS , la Ley de protección de datos , o cualquier otro número de reglamentos. La mayoría de estos requieren auditorías, que no son baratas y no son fáciles de aprobar.

Honestamente, todo este esquema parece un accidente esperando a suceder, especialmente porque eres un principiante con criptografía. Mi consejo es no almacenar información financiera confidencial a menos que sea un procesador de pagos o un banco y tenga una sólida experiencia en seguridad . La regla # 1 de seguridad es "la seguridad es difícil". Hacerlo mal pone a sus clientes en peligro y lo prepara para una serie de juicios costosos. Si usted es una empresa que está buscando vender cosas o proporcionar un servicio de pago, utilice una empresa procesadora de pagos que ya se adhiera a los estrictos procedimientos y estándares de seguridad.