Foro de elhacker.net

Os pongo en contexto con un caso hipotético.

Yo soy el administrador de un servidor al que acceden multiples usuarios socios de la misma empresa e introducen su cuenta bancaria y su PIN.

Yo estes datos quiero guardarlos cifrados en un documento de texto accesible públicamente. Así cualquiera usuario que no esté registrado pero tenga la contraseña puede tener acceso a las cuentas.

Entonces hice un script en PHP con una función cifrado($parámetro1, parámetro2); Esta función cifrado acepta dos parámetros; $arrayBancoPin y $StringContraseña y retorna un string con todos los datos cifrados.

Entonces la función la llamo como:

$UsuarioBancoPin = Unir($UsuarioBanco, $UsuarioPin);
$Contraseña = '123';
 
$DatosCifrados = cifrado($UsuarioBancoPin, $Contraseña);

Finalmente lo guardo en un archivo.

file_put_contents("banco/informacionCifrada.txt", $DatosCifrados, FILE_APPEND);

Hasta aquí todo bien.

El problema surge si alguien hackea el servidor y obtiene el cifrador.php
Este hacker tendría acceso a:
Contraseña en texto plano. Modificar PHP. Imprimir variables o usar funciones. Ver el código del cifrado...

La opción más lógica es usar un cifrado asimétrico para cifrar el contenido del archivo con clave pública. El problema surge en que el propio servidor en otro script .php necesita tener la clave privada para descifrar y hacer transferencias automatizadas. A parte de que varios usuarios también necesitarían acceso a la clave privada. Ya que el servidor no puede descifrar para ellos. Deben ser ellos quienes descifren offline.

Qué se puede hacer al respecto?

---

Mod: OBLIGATORIO EL USO DE ETIQUETAS GESHI.

basicamente nada... por eso se asegura el servidor para evitar un hackeo...

ya en ese punto no hay mas allá donde ocultar, solo te queda la ocultacion por "oscuridad" y eso es lo primero que cae

    Ocultar contraseña en archivo

¡No puedes guardar las contraseñas!

Debe usar un algoritmo de función hash, guarde y use para comparar cuando intente acceder o descifrar.
¡Cifras cualquier documento usando la clave real, no el hash!

De esta manera, la contraseña real nunca se guarda ni se rastrea, ¡ni se puede inyectar u omitir en la rutina de acceso o descifrado!

Saludos.

Bueno, se podría utilizar un nivel más. Aunque no sirve de demasiado, se podría requerir de que alguien metiese la password cada vez que se reinicia el servidor, de manera que en lugar de almacenarse en fichero la password simétrica se almacene en memoria.
No obstante fijarse que el atacante no tendría más que generar un archivo php que obtuviese la variable en memoria y la mostrase en pantalla.

No obstante, igual lo suyo es almacenar las passwords simétricas de cifrado de cada cliente, cifradas con su password. La password de cifrado esta almacenada de forma cifrada, y solo se descifra con la password en limpio del cliente. Que no se almacena en el servidor porque el cliente te la teclea cada vez que quiere acceder y con eso descifras la clave simétrica que permite descifrar los datos de cada cliente.

Aunque esto tiene sus problemas, si un cliente pierde su password, toda su información se pierde. Igual tendrías que hacer otra copia cifrada con una llave maestra que sea la password del admin. Aunque entonces el admin podría acceder a los datos en limpio del cliente. Todo tiene sus problemas y eso implicaría un único punto de fallo.

Por otro lado, nada impide a un atacante que accede fisicamente con suficientes privilegios acceder a la información de al menos aquellos usuarios que esten utilizando en ese momento el sistema.

Qué sentido tiene eso si al cifrar en el archivo .php tengo que poner la contraseña?
Cómo no se guarda la contraseña si cada vez que un usuario mete sus datos, se necesita la misma contraseña para cifrarlos? Se supone que se tiene acceso al PHP.


Claro, si no se pudiese imprimir desde el PHP tampoco se podría usar para cifrar.

Sigo necesitando la contraseña para cifrarla con la contraseña del usuario.

Sí,esto ya lo daba por hecho. Se tendría acceso a toda la nueva info antes de ser cifrada. Esto sí se como solventarlo.

Igual es la única opción. Una ofuscación muy hardcore que me diese tiempo a apagar el sistema. Pero de todas formas si me hacen backup del server da igual que lo apage. Ya tendrán toda la info necesaria para descifrar la base de datos. Igual puedo hacer una guarrería muy poco obvia, tipo utilizar la contraseña almacenada en otro sitio en un formato poco previsible. Algo como obtener la contraseña por OCR de una imagen donde R255 sea un 0 y R254 sea un 1.
Entonces podría substituir la imagen por otra cualquiera en caso de recibir un ataque. Podría dibujar la imagen dinámcamente para que no se guarde en cache y obtener logs para saber si el atacante accedio. Al menos me daría tiempo a avisar para que se cambiasen los Pins.

Pero vaya coñazo tener que implementar algo así.
A ver si alguien tiene una idea mejor.

el problema es que estás pensando en un caso absurdo... no porque no pueda pasar, sino porque ya saltaron tu seguridad, es decir, ya perdiste el juego... es mentira que vas a revisar el codigo cada 5 minutos, incluso podrían a lo que sea que hagas agregar codigo para enviar todo a otro lugar y sacar tu contraseña sea como sea...

no deben entrar a tu servidor, ese caso implica que ya perdiste, debes invertir tiempo, conocimiento y tecnología en defender el status del servidor

En primer lugar esta malo todo, xD se supone que el banco dice que no debes entregar información de ninguna clase y menos ingresarla en sitios web que no sea el banco.

Así que no entiendo el motivo por el cual deban agregar su informacion bancarea en el sitio web.

para automatizar pagos por lo que entiendo... como paypal... aun cuando paypal usará una api, sin embargo una api lleva un token que hace lo mismo que una contraseña XD

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.

esto es la opción mas apropiada, tal cual funciona mega (según ellos XD)...

también puedes usar tokens de accesos únicos... es decir, cada vez que se use, se vuelve a cifrar la información con una nueva contraseña y se le da al usuario.... eso si, si la pierde (o falla la red o por alguna razón la información no llega al usuario), pierde la data de manera permanente

El tema es que hay demasiadas fallas de seguridad para garantizar seguridad al 100% en el servidor y necesito manejar información sensible online. Podría tener el procesador un fallo de seguridad independientemente de la seguridad que yo implemente e irse todo a tomar por culo. XD

Porque no pueden asegurar la seguridad de un sitio externo. Eso no implica que los datos vayan a estar menos seguros que en el banco.

Porque quieres y estás de acuerdo con el uso que se va a hacer de tu cuenta. Puede tener solo 10$ y dar el PIN para que el sitio haga inversiones por ti con tu dinero automáticamente.


Me parece peor el remedio que la enfermedad jeje. Más vectores de ataque abiertos.

Haré obscuración muy muy basta. Lleno todo el server de scripts, archivos funciones y variables sin nombres.

en realidad crees que tienes informacion mas sensible que una organizacion del estado, un banco, tiendas online u otros? XD muchos de ellos usan php y alli esta todo...

tu problema es que estás tratando de hacer una caja fuerte tan dificil de abrir que sea imposible... el asunto es que en la caja fuerte no está la seguridad, esa es la ultima barrera, está en el lugar donde se haya la caja fuerte, el como se accede, quien la cuide, etc...


si tienes dinero nada que no puedan resolver en unos minutos haciendo debug XD

tu te tiras un debugger de php y ni si quieras tendrás que analizarlo tu, solo tendrás que correr el debugger y verse como se resuelve el laberinto... o mejor aun... corres el programa en un php aislado y lees los datos salientes! XD

tu problema en todos lo que he visto que has publicado hasta ahora es que estás lleno de informacion mal comprendida y muchos mitos...

analiza sobre seguridad bien, ve los casos, ve que son sistemas de prevencion temprana, ve que son subsistemas de analisis, etc...

en tal caso que tengas suficiente recursos, usa un pre sistema que analize los paquetes antes de enviarlos al apache... es decir, nada que no tengas las variables get o post que tu usas deberia pasar, el contenido de las variables deben cumplir condiciones (por ejemplo prevalidar el correo, que cabeceras son admitidas y usadas, etc)

cierra todos los puertos de tu servidor excepto los extremamente necesarios, y por ejemplo para ell ssh abrelo solo sobre ip fija, no admitras contraseña sino solo autenticacion por llave, nada de ftp (como la gente aun usa eso?) etc...

Pero el usuario introduce ell pass en limpio que es cuando la necesitas descifrar para acceder a la passphrase de cifrado simétrico que cifra la info del usuario y cuando se almacena en memoria para descifrar. El resto del tiempo esta cifrada con esa contraseña que sólo está en la cabeza del usuario y en forma de hash en tu base de datos.

El atacante que entre no podrá mas que acceder a las contraseñas en uso si hace el volcado de memoria. No al resto que estan cifradas con la password de cada usuario.


+ 10000 puntos de carisma a lo que comenta engel. Tu pasas la información cifrada al cliente y que él la descifre. Si no tienes la información descifrada en el lado del servidor aunque hackeen el servidor no pueden acceder a la información.


En realidad menos. porque si a un cliente le hackean es su culpa no tuya. Y si hackean al cliente, tengas tu la informacion descifrada o sólo la cifrada van a poder acceder a dicha información. Solo que en el caso que describe engel si te hackean sólo a ti no acceden a ninguna información.

Si utilizo este método el problema está en si quiero acceder YO a la información, ya que no tengo la contraseña del usuario para descifrar la inormación. Y yo necesito proporcionar una contraseña para que el servidor vaya cifrando los datos que envian los usuarios.

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

Puedes optar como te decía a replicar el cifrado de la contraseña mediante la pass del usuario y tu password. La creación de usuarios pasaría por la aceptación por tu parte de la cuenta de usuario momento en el que generas una pass aleatorioa para el usuario y una simetrica cifrada con la pass aleatorioa y la tuya. Cuando el usuario entra cambia la password y se vuelve a cifrar la simetrica con la nueva pass del usuario. Con lo que cada usuario podría acceder a sus datos y tu a los de todos (como Dios ^^).
Eso tiene el problema de que tienes que hacer tu los usuarios o exigir al usuario a que espere el check tuyo y que si te roban tu pass maestra tienen acceso a todo, como tu. Pero así ninguna password ni dato se almacena físicamente en limpio en el servidor.

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.

No te estoy entendiendo, podrías poner un ejemplo con contraseñas?
Haré:
Cifrado(TextoPlano, MiContraseñaPública);

Cómo dices tú de hacerlo?


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.

esto es en joda? XD esto es lo mas inseguro que hay, principio de seguridad JAMAS se envian contraseñas o datos altamente sensibles por correo... el correo no es un protocolo cifrado y es probablemente uno de los segmentos de seguridad mas vulnerados...

Es en joda tu comentario? Tu dices:"Te mando un whatsapp" o "Te mando un whatsapp cifrado de punto a punto"?

Es información implícita en "Mando un correo" que voy a cifrar las comunicaciones.
También es información implícita que una vez en el correo es trabajo del usuario acceder, enviar y descargar correos de forma segura.

hay una diferencia, el wa para el texto plano lo hace por defecto, el correo no, en hecho ningun standard de comunicacion segura sobre email es comun...


XD dale! sigue confiando en el usuario para eso! que alguien aquí que tenga servicios aclare cuantos usuarios han configurado metodos seguros!

estoy seguro que ni el 1% lo hará, especialmente porque está fuera de su control en buena parte, el resto sería usar pgp (o similar) sobre correo que es lo unico que puede controlar...

el email por defecto para seguridad se considera un medio vulnerable, siempre, eso te puede decir cualquier persona que trabaje como sysadmin o similar... así que la comparación de <<"Te mando un whatsapp" o "Te mando un whatsapp cifrado de punto a punto"?>> está totalmente fuera de contexto en situacion normal

---

insisto muchas de las cosas que que dices cada vez mas las dices sin base de conocimiento, no voy a negar que tienes capacidad para analizar, razonar y desarrollar, pero muchas de tus bases son mitos

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.

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.

(https://media.giphy.com/media/Fu9EXNUgJBRBe/giphy.gif)


Saludos

Me refiero a desconectar de la red ELÉCTRICA para borrar la contraseña de la RAM al utilizarla en el LiveCD para descifrar. Después volver a enchufar, arrancar el equipo en LiveCD, conectar a internet y enviar el contenido descifrado.
Así en el caso que se infecte el equipo con malware si se introduce la contraseña, el malware no puede enviarla a ningún sitio. Lo máximo que puede conseguir es obtener el contenido descifrado. Pero no la clave privada que le permitiría descifrar toda la base de datos.

Es que no tiene ningún sentido lo que dices. Vuelve a leer lo que has puesto...


Saludos

Por qué no tiene sentido?

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.

Estas planteando un caso en el que quieres automatizar el guardado y la "lectura" de información  pero en realidad estas "manualizando" todo el proceso utilizando métodos "primitivos" para el supuesto tratado de datos. (con primitivos me refiero a no automatizados, lentos y que están enfocados a ataques poco probables (véase, que te infecten por descifrar un archivo el cual has poblado tu, dado que lo has tenido que cifrar tu..).

Imaginate que 50 clientes te piden sus datos... si tardas un promedio de 5 minutos en arrancar una distro y descifrar, para luego tardar otros 5 minutos (siendo generosos) en arrancarla otra vez y enviar los datos, tardarias 500 minutos (es decir, 8 horas).

Un método que por cierto no previene de ninguna forma el hecho de que si obtienen acceso a tu servidor, pueden interceptar los datos que los clientes meten, es decir, ya tendrían los datos antes de que tu siquiera empieces a "salvaguardarlos".

¿Y todo esto para que? ¿Para que tu seas el único que pueda acceder a dicho archivo? Y qué pasa si te olvidas de la clave, o la apuntas en algún sitio y te roban en casa o te mueres o si simplemente se te rompe el PC.. los clientes se quedan sin poder acceder a la información porque todo el proceso se centra en un único ser vivo...


Saludos

No está basado solo en que me infecten utilizando un archivo que genero yo. Puedes hacer MITM para modificar el archivo, atacar la red físicamente, explotar vulns, etc. Poco probables? Después de la IngSocial con dbd va el MITM en frecuecia de ataques.

Nada me prohibe tratar la información de forma automatizada una vez se descifra a mano. A mi lo que me interesa es utilizarla de forma autónoma. No que todo el proceso tenga que ser como tal.

El coche "anda solo" pero tienes que abrir la puerta, meter la llave, encenderlo, apagarlo para repostar, volver a encenderlo...

Si 50 clientes me piden sus datos descifro los 50 a la vez porque usan todos la misma clave. Hago una función para que se obtengan los datos de cada cliente por separado y se envien a cada correo. Solo tengo que poner la contraseña a mano. (Ya tengo una función creada que no ocupa ni 20 lineas que prácticamente ya lo hace para otra parte del software.)

Pueden obtener los datos de los nuevos clientes sin cifrar. Pero esto no les serviría para obtener toda la base de datos.

Su cuentas siguen siendo sus cuentas. Disponen de su PIN asique no perderían acceso a sus cuentas en ningún momento. Si me muero me preocupa poco que el servicio quede offline :xD

Me interesa automatizar por 2 motivos:
1) Porque no puedo estar activo cuando llegue un nuevo cliente con su cuenta bancaria y no es buena idea dejar los datos en el servidor sin cifrar.

2) Para no tener que clasificar y operar con la información a mano porque me daría trabajo.

Me da igual que las operaciones se realicen hoy, o dentro de 1 mes mientras se siga el procedimiento en base a unas pautas.

Precisamente he dicho poco probables porque el MITM lo pueden hacer en cualquier punto menos en en el que usas una distro live para descifrar el archivo... por tanto no lo considero un ataque poco probable y tampoco es que te estés protegiendo de el. Lo único que intentas proteger es una contraseña maestra. No proteges ni la entrada ni la salida de datos.

De que te sirve proteger al actor si pueden pillar el guion y las escenas...


Saludos