Mensajes

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.

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.

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.

una de las primeras cosas que igual debes hacer en un algoritmo de cifrado para evitar esquemas de criptoanálisis es utilizar el efecto avalancha. Introducir una entrada más en cada carácter a cifrar y combinarlo con la salida anterior. El primer carácter cifrado se puede dejar sin tener entrada adicional. de manera que si cifras usando una clave con los mismos caracteres el texto codificado saldrá diferente porque la nueva salida no dependerá sólo del mensaje y la clave, si no del carácter obtenido como texto cifrado del anterior.

Código [Seleccionar] Expandir


abcde
aaaaa

a+a+0=b
b+a+b=e
c+a+e = ...

No se si se entiende.

Por otro lado, también deberías utilizar bloques mas grandes, que tu algoritmo utilice cosas de las que no se pueda terminar obteniendo un diccionario.
Igual estaría bien leer un poco sobre redes de feistel, muy sencillas y potentes para hacer algoritmos de cifrado simétrico.
Si quieres hacer cosas de criptografía, personalmente te recomiendo el Lucena (http://www.grc.upv.es/biblioteca/cripto.pdf) si no tienes mucha fluidez en inglés, o el schneier (https://www.abebooks.com/servlet/BookDetailsPL?bi=30425390127&searchurl=kn%3Dapplied%2Bcryptography%2Bschneier%26sortby%3D17&cm_sp=snippet-_-srp1-_-title2) si no te importa leer texto en inglés (y comprarlo).

fuera de eso, si estás ya dentro de la wpa, conseguir el router es solicitar la ip a la mac con quien negociaste el acceso en capa 2 (paquete ARP)

Pero eso es DHCP y está inhabilitado te está diciendo.Si no he entendido mal, está comentando que él/ella ha ingresado en una red WPA pero no tiene ni idea del direccionamiento interno y como el DHCP esta inhabilitado no puede componer un paquete ARP con ceros para que le de puerta de enlace e IP. Y además al ser WPA, no puede esnifar trafico de otros ordenadores para intentar obtener el direccionamiento de forma pasiva.
O a lo mejor no he entendido bien.

Yo creo que el auge de los teclado mecánicos es un poco moda. Uno de membrana con teclas finas requiere de mucha menos presión y probablemente sea más agradable y te canse mucho menos, al final haces menos presión.
Por tema económico, cuando te falla un poco lo tiras y compras otro, por la diferencia de precios parece que podría ser un punto a favor de los membrana.
Por otro lado, los mecánicos probablemente duren más, seguramente sea mucho más ecológico tener un teclado durante mas tiempo que 3 o 4 durante menos.
No obstante, esto es como los zapatos, intenta optar por un teclado que se adapte a ti. A lo mejor eres mas de teclas gruesos o finas o teclados mas anchos o menos anchos.
Por tema de retraso que hablas por piezas que son algo firmes, probablemente lo notes más en teclados mecánicos que en los de membrana.

Si tienes una entrada dentro de un eval y no tienes cuidado podrían ejecutar código php. Si dejas subir archivos sin tener cuidado con lo que suben, podrían subir un archivo php y ejecutarlo. Si no tienes cuidado con lo que metes en tu base de datos podrían ejecutar código sql o ejecutar comandos remotos en el servidor. Si lo que sale del SQL lo evaluas podrían ejecutar código php. Si no tienes cuidado con los system, podrían ejecutar comandos remotos.

En general, cuidadito (mucho) con todo lo que te dan los usuarios o si no... la lias y gorda. Osea que limpies todo lo que te dan los usuarios desde php aunque lo hayas hecho ya desde html/javascript y acepta sólo los parámetros que esperas o no aceptes lo que te da el cliente. Y cuidado, mucho cuidado con los JSON que los carga el diablo. Hay gente que une una entrada de JSON con un "==" y un hash, y esa combinación suele ser fantástica.

En resumen, ¿Alguien que te de exactamente el programa que quieres para usarlo poniéndole una IP? Pues no lo sé, busca por ahí, servicios de traceroute hay a patadas.
No sé si habrá alguno que ofrezca los resultados agregados de traceroute + Record route + otros métodos de búsqueda de paths, será cuestión de darte un paseo por Google. Yo así a bote pronto no conozco ninguno.

Soy imbécil disculpa, jajaja. Lo entendiera mal. En tu explicación dices que el Record Route es limitado. Te refieres al número máximo de ips que puede almacenar o a que no almacena las ip de entrada?
De todas formas me informaré al respecto que parece más que suficiente para lo que busco.

El campo de opciones de IP se tiene un máximo permitido de bytes (la cabecera IP tiene un máximo, bueno igual que el PAYLOAD, lo que pasa que este último puede ir dividido en varios paquetes). Ergo, solo puede caber un número limitado de direcciones IP en él.

Para mas info https://tools.ietf.org/html/rfc791

Ya como último y tema totalmente a parte no se si por casualidad conoceis ninguna Api que lo haga no? De la misma forma que por ejemplo la Api de google obtiene las coordenadas de la ubicación de tu dispositivo.

Desde html/javascript no tienes control sobre el envío de paquetes ni creación de sockets (En este caso de tipo RAW). De hecho sería un error de seguridad para el navegador.
Asi que la herramienta no puede ser una web local.
Si quieres implementarla tu creo que tendrás que programar en c, java, python, whatever....
Si no, tienes la herramienta hping3 que te permite hacer casi cualquier cosa con paquetes incluido decidir las cabeceras y flags que desees en los paquetes. También tienes librerías de python como scapy o en c que te permiten no tener que trabajar con paquetes a pelo y te dejan tocar los contenidos de las cabeceras de los paquetes que deseas enviar como libnet.

Así podría utilizarla en Front-End sin necesidad de disponer de Back-End para que el código sea portable en un único .html ya sea para hostearlo en cualquier sitio como blogspot o en un hosting gratuito que solo te dejan trabajar con Front-End.

En la parte de necesidad de front-end/back-end me perdido totalmente. Porque no comprendo el querer hacer una aplicación de este tipo con sistema cliente-servidor. Aparte de que parece que no tendría demasiado sentido, ya que los traceroutes se harían siempre desde el mismo sitio. Desde el servidor web donde tengas programado el back-end. Pero vamos que eso tu sabrás.

Ten en cuenta que html/javascript (en navegador) no esta pensado para hacer aplicaciones, esta muy limitado y debe ser así. Se pueden hacer cosas chulas, a veces retorcerlo para conseguir sacar algo de jugo (mucho o poco), pero no es la panacéa. Y está pensado de forma limitada para ser usado como frontend. Osea todo lo que sean operaciones de dibujo en el cliente de forma más o menos potente, se pueden hacer cosas. Lo demás, por regla general olvídate. El sandbox en general debería de proteger de cualquier operación, "rara".

Bueno realmente lo dije desde el principio lo del record route pero paso desapercibido.