Ocultar contraseña en archivo PHP?

Iniciado por @XSStringManolo, 1 Octubre 2019, 05:57 AM

0 Miembros y 4 Visitantes están viendo este tema.

Imprimir
Ir Abajo Páginas1 2 3
Acciones del Usuario

@XSStringManolo

1 Octubre 2019, 05:57 AM Ultima modificación: 1 Octubre 2019, 15:34 PM por #!drvy
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:
Código (php) [Seleccionar]
$UsuarioBancoPin = Unir($UsuarioBanco, $UsuarioPin);
$Contraseña = '123';

$DatosCifrados = cifrado($UsuarioBancoPin, $Contraseña);

Finalmente lo guardo en un archivo.
Código (php) [Seleccionar]
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.

engel lex

#1
1 Octubre 2019, 06:04 AM
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
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.

shin-elhacker

#2
1 Octubre 2019, 11:20 AM
   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.

animanegra

#3
1 Octubre 2019, 11:56 AM
Cita de: engel lex en  1 Octubre 2019, 06:04 AM
básicamente 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 ocultación por "oscuridad" y eso es lo primero que cae

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.

42
No contesto mensajes por privado, si tienes alguna pregunta, consulta o petición plantéala en el foro para que se aproveche toda la comunidad.

@XSStringManolo

#4
1 Octubre 2019, 12:48 PM
Cita de: shin-elhacker en  1 Octubre 2019, 11:20 AM
   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.
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.


Cita de: animanegra en  1 Octubre 2019, 11:56 AM
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.
Claro, si no se pudiese imprimir desde el PHP tampoco se podría usar para cifrar.

Cita de: amimanegraNo 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.
Sigo necesitando la contraseña para cifrarla con la contraseña del usuario.

Cita de: animanegraPor 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.
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.

Cita de: engel lexbasicamente 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
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.

engel lex

#5
1 Octubre 2019, 14:49 PM
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
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.

Shell Root

#6
1 Octubre 2019, 15:09 PM
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.
Por eso no duermo, por si tras mi ventana hay un cuervo. Cuelgo de hilos sueltos sabiendo que hay veneno en el aire.

engel lex

#7
1 Octubre 2019, 15:16 PM
Cita de: Shell Root en  1 Octubre 2019, 15:09 PM
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
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.

MinusFour

#8
1 Octubre 2019, 16:01 PM
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.

engel lex

#9
1 Octubre 2019, 16:27 PM Ultima modificación: 1 Octubre 2019, 16:29 PM por engel lex
Cita de: MinusFour en  1 Octubre 2019, 16:01 PMLa ú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 problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
Imprimir
Ir Arriba Páginas1 2 3
Acciones del Usuario