Ocultar contraseña en archivo PHP?

[@XSStringManolo]

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 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

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.

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.

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

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.

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.

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.

[engel lex]

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

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...

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

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...

[animanegra]

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

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.

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.

+ 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.

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

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.

[@XSStringManolo]

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.

[animanegra]

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.

[MinusFour]

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.

[@XSStringManolo]

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.

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

Cómo dices tú de hacerlo?

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 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.

[engel lex]

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

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...

[@XSStringManolo]

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.

[engel lex]

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

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...

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.

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