Mensajes

Es por el funcionamiento del software. Obtengo los datos bancarios nada más se conecta el usuario a mi plataforma y los almaceno cifrados. A mi lo que me interesa es que si alguien hackea el server no pueda descifrar los datos bancarios de los usuarios.
El usuario no cifra nada.
Todos los usuarios deben poder acceder a sus datos bancarios y a los datos bancarios del resto de los usuarios de la plataforma.

El tema es que nadie externo a la plataforma que acceda al servidor obtenga los datos bancarios.

Entonces lo que de momento se me ocurre es cifrar todo con clave pública. Y la privada solo tenerla yo. Si cada cliente usa su clave, ni yo ni el resto de usuarios de la plataforma tienen acceso a toda la base de datos.

El tema está en proteger la contraseña, que solo yo la tenga. Asique lo único que se me ocurre es eso.

Mi idea es introducir a mano la contraseña en un liveCD desconectado de toda red para descifrar. Copiar en un pen los datos descifrados. Desconectar el equipo de la red. Volver a conectarla y enviar los datos descifrados de vuelta por otra ruta.
Así no se puede conseguir la contraseña de ninguna forma y yo elijo a que cliente darle que.

Si tu tienes miedo que el servidor se comprometa, considera que toda la información entrante al sistema también es vulnerable. La info guardada en el servidor quizás este cifrada pero la que viene entrando no.

Vamos a ver, que si no confías en el servidor porque no puedes asegurar el servidor entonces lo único que te queda es que el usuario desconfíe del servidor y te envié la información cifrada.

Pero bueno, supongo que ya es algo si guardas la información cifrada. Mejor usa un servicio donde no tengas que manejar la información del cliente en lo absoluto.

El que escribió ese artículo estaba pensando en javascript:

In other words, the initialization of new array is faster, use syntax var first = [] rather while using syntax var first = new Array()

Lo cual es muy diferente en PHP.

No no, cuando dije de cambiar el esquema, me refería a no dejar a los usuarios acceder a la información directamente usando la contraseña privada. Tengo pensado que para que accedan a la información me manden un correo. Yo la descifro offline y la envio descifrada al correo tras validar que sea el correo asociado a la información a la cual hace request.
Así aunque se comprometa el servidor no se puede hacer nada. Yo obtengo  la info en un equipo, desconecto la red, accedo a otro equipo offline que descifre y me devuelva la infofmación. Es un poco rollo, pero me parece más seguro haciendo unas cuantas comprobaciones.

No entiendo que estás ganando con todo esto. Tu cifras y descifras, el usuario cifra y descifra. Tu cifras el contenido de regreso a el usuario (para que lo lea) y descifras la información que te envia el usuario para poder cifrarla de regreso (para que tu puedas leer). Cada vez que el usuario quiera leer la información, tu tienes que descifrar, cifrar y el usuario volver a descifrar.

Si tu cifras la información con una algoritmo simétrico, ambos pueden cifrar y descifrar la información sin necesidad de que la otra persona cifre o descifre. Las llaves no son necesarias que las mantengas en un servidor online, porque el que las ocupa eres tú, no el servidor.

Cambiaré el diseño de la plataforma y ya. Uso asimétrica, cifro con pública, y descifro offline con privada.

Esto no tiene nada de sentido. Si tu generas un par de llaves y usas ese par de llaves para cifrar la información del usuario solo tú puedes descifrar la información y tus usuarios no, especialmente offline. Tu pones la llave privada en el servidor y descifras en el servidor y volvemos al mismo problema. Tu compartes la llave privada con todos tus usuarios y bueno... pro tip, no lo hagas.

Si tu quieres leer la información cifrada por todos tus usuarios tienes dos opciones:

1) Duplicas la información cifrada, un juego con tu llave otra con su llave.
2) Generas una llave para ti y el usuario y usan esa llave para cifrar y descifrar la información.

Lo único que te permite la primera es tener una llave "maestra" para toda la información, con el costo de que... duplicas la información... No lo veo como una buena solución. Encima que tienes un punto de fallo único con esa llave.

La segunda es mucho mejor en mi opinión. No necesitas cifrado asimétrico porque necesitas compartir la llave de todas formas. Si se compromete una llave no se compromete toda la información (por favor no vayas a poner todas las llaves en la misma carpeta, en un mismo host).

También tienes que considerar la mejor forma de compartir la llave simétrica. Aquí si puedes usar cifrado asimétrico. Le dices al usuario que necesitas una llave pública para cifrar la llave simétrica y listo.

Si tu necesitas leer la información, no hay más remedio que expandir la superficie de ataque (donde ahora tenían que atacar a usuarios en específico, ahora tu te vuelves un punto de ataque también) y tu incrementas la superficie por mucho dependiendo de tus prácticas.

Todo esto me imagino porque gira en cuestión a los hashes. Para hacer un ataque de diccionario tan complejo como ese una persona tendría que saber que la contraseña está basado en una oración (y en un determinado lenguaje). Lo común son las rainbow tables de X charset con longitud Y y con salt Z. Me imagino que habrá rainbow tables que se generen con NLP pero yo creo que estos deben ser ordenes de magnitud más lentos que los diccionarios que se escupen normalmente (de GPUs, FPGAs, etc). Tampoco creo que sean muy comunes.

Es una pregunta compleja la verdad. A simple vista muchas combinaciones se pierden por palabras. Porque no hay una palabra por cada combinación de letras. Tiene sus ventajas y desventajas.

Lo mejor sería que las personas que están almacenando las contraseñas se deshagan de hashes que pueden ser vulnerables (hoy en día debería ser regla usar KDFs para almacenar las contraseñas), solicitar a sus usuarios nuevas contraseñas en caso de que tengan que remplazar los hashes y ofrecer autenticación de dos factores. Como usuario, nunca usar la misma contraseña para otros sitios. Si te comprometen la contraseña, no la pueden usar en ningún otro lado y si el proveedor del servicio fue lo suficientemente listo para proteger tu cuenta usando otros factores no pierdes nada más que esa contraseña.

Las contraseñas de texto creo que eventualmente van a morir y vamos a tener que buscarnos otros métodos de aunteticación.

Personalmente, yo creo que si la información se puede descifrar del lado del servidor y una persona tiene acceso total al servidor entonces no hay forma de garantizar que la información no se puede descifrar por esa persona. Solo tendrías que estar escuchando las respuestas del servidor para obtener la información descifrada.

La única forma de garantizar que la información no se pueda descifrar si te comprometen el servidor, es que no se descifre la información del lado del servidor. Tendrías que almacenar la información cifrada solamente y dejar que el cliente descifre (y quizás hasta dejarle cifrar) la información.

Lubuntu es LXDE + Ubuntu. Linux Mint es prácticamente Cinnamon + Ubuntu. Ahora si instalas LXDE en lugar de Cinammon...

No te vas a encontrar gran diferencia.

Muchas gracias la verdad si mejoro.
Pero me podrían recomendar una distribución linux que mi pc la pueda llevar sin mucho esfuerzo?

Son asuntos de configuraciones y programas que uses lo que va a mejorar el rendimiento de tu equipo. Quizás una distro en la que tengas que compilar los paquetes te puede ir mejor (como gentoo) pero con ese equipo quien sabe cuanto te vayas a tardar en compilar. Mi i7 de tercera generación (a 3.6ghz) tardo cerca de 3-4 horas en compilar un kernel 4.x, quiero creer que el tuyo tardaría más del doble pero no estoy seguro. Encima, dices que si el procesador va al 100% se apaga.

Yo creo que ni para navegar recomendaría ese equipo.

Xorg, es el servidor de las X, Cinnamon es el DE de Linux Mint. No te preocupes por Top ocupando un % alto. Es como te lo había comentado, tu DE está ocupando algunos de tus recursos. Puedes probar algún DE que use pocos recursos como LXDE:

Código (bash) [Seleccionar] Expandir


sudo apt-get install lxde

Reinicia tu PC y a la hora de iniciar session seleccionas la opción de LXDE (no estoy muy seguro de donde este en LightDM, que creo es el DM de Linux Mint, quizás sea GDM...)

Porque no te pones a ver en la lista de procesos que es lo que te consume, usa el programa:

Código (bash) [Seleccionar] Expandir


top

Lo más probable es que sea la shell del DE que estes usando.