Mensajes

¿Cómo "por fortuna"?, el mensaje siempre se conserva si le das a 'retroceder' en el navegador,

A lo mejor no me expliqué bien... a veces abres otra venta y luego cerraste esa ventana y ya no tienes acceso, cuando te das cuenta es tarde (a veces digo).

...Además, solo se pierden 5 segundos en hacer CTRL+A, CTRL+C, 'Actualizar' (la página, para que se renueve el token de usuario), CTRL+V y enviar.

No me creo que SIEMPRE cada vez que envíes un mensaje antes de nada, lo copies por si acaso... además, eso demuestraría que tengo toda la razón. Las máquinas y la programación están para facilitar la vida al ser humano... no para hacelro esclavo d elas máquinas.

Si siempre (por evitarlo), tienes que copiar previamente el mensaje antes de enviarlo, es señal de que hay algo a medias en la programación... ¿no te parece?.

Justamente por eso, titulo 'comportamiento inadecuado' y no error... porque se puede (y debería) mejorar...

Olvida un programa que te muestra publicidad en las imágenes...

"Guglea" algún ejemplo que utilice la api de GDI+ : GdipSaveImageToFile
te permite guardar en jpg definiendo el nivel de calidad y también en png o tiff...

Es absurdo...

...el médico a la medicina, el político a la política, el zapatero a sus zapatos...

A quien toca hablar de tecnología es al personal y empresas tecnologícas, ni médicos, ni políticos, ni zapateros... cada uno a lo suyo.

Claro... Google tiene como 200 años de experiencia en estas lides de los negocios y la informática frente a los solo 108 que tiene IBM...

Y tanto. ...antes de cambiarse el nombre a IBM, ya llevaban un chorro de años fabricando máquinas de escribir...

El bloqueo de licencia es por valores de número de hardware
Que en este caso debe ser USB serie!

Eso venía a decir... cuando clonas el software y no funciona es porque utiliza algún valor del hardware del dispositivo original... toca desemsamblar para buscar el punto concreto de validación...

Seguramente antes de instalar el software sobre el dispositivo, leen algún atributo del hardware y luego lo aplican al software (seguramente ya compilado), y así cada copia es única... si dispones de varios, prueba hashear el ejecutable/instalador de varios y verificar que aunque sean la misma versión y seguramente mismo tamaño (y quizás fecha original) tienen diferente hash...

Si fuera simplemente el número de serie, hay herramientas que permiten cambiar el número de serie de la unidad.

Quién es esa?

Ídem....

...pués yo recuerdo vivamente, allá a comienzos de milenio cuando Gooogle, tenía chupete, que dijeron que siempre forever serían gratis... claro que entonces eran poco más que un buscador.

En realidad, las promesas verbales, pueden ser llevadas a juicio, para exigir su cumplimiento... pero claro a ver quien encuentra ahora aquellos vídeos donde lo cacareaban más que con orgullo hasta con soberbia, cuando son ellos mismos los 'guardianes' de las búsquedas... Archive.org empezó a funcionar creo recordar que tiempo despues así que posiblemente no estén indexados esos vídeos en alguna parte 'recatable', para traer a la memoria las promesas (que al final acaban siendo mentira, igual las de los políticos)... como reza nuestro refranero: "donde dije 'digo', digo 'Diego'."

Una cosa NEBIRE; cuando te logueas al foro, este te da la posibilidad de mantener la sesión iniciada indefinidamente (incluso después de cerrar el navegador).

si, claro... esa e sla solución conocida, para mi inaceptable.

Yo tengo marcado en mi navegador que borre datos de sesión al cerrar el navegador y cada x días todo el historial...

Las opciones de recordar, son aptas para vagos, inconscientes y desmemoriados. No cuesta nada poner tu alias y contraseña. De hecho responder un mensaje como este lleva el equivalente a registrarse 20 veces... luego pereza ninguna.

Si el fichero fue eliminado hace 1 año, el disco duro tiene una alta ocupación y se ha seguido usando el equipo desde entonces, hay una alta probabilidad de que no quede ni rastro del mismo.
En otras condiciones, tampoco se garantiza, pero las dadas son extremas.

Hay utilidades para borrar físicamente el contenido del fichero antes de 'eliminarlo', para que no sea recuperable, algo necesario cuando el fichero a eliminar contiene información sensible, como datos bancarios, fotos personales, etc...

Los nombres no suelen ser recuperados por una simple cuestión: Contenido y nombre del fichero, no se almacenan juntos...
Es como si tienes una lista de invitados a una boda y una lista de fotos de los mismos, en el mismo orden, ahora pierdes la lista d elos nombre so desordenas las fotos... qué tienes ahora para identificar el nombre de cada foto?. Nada... pasa igual con los ficheros.
Ficheros del sistema todavía podrían se rprovistos a un alto coste, hasheando el contenido recuperado y ver si en alguna parte constan pares de hashes <---> nombre de fichero, pero de tus propios ficheros, no...
Algunos tipos de documentos, incluyen en el contenido del fichero el nombre original del mismo, en tal caso algún programa puede intentarlo para los formatos que reconozca... aunque lo mínimo que deberían intentar dichos programas de recuperacón es como mínimo restablecer la extensión original, para tipos ampliamente conocidos... algunos suelen hacerlo para .exe, .dll, .jpg y pocos más...

[Resistencia a la contribución de bits:]

En lo primero quería decir que no eras específico y resultaba ambiguo saber si no eras capaz de hacer que tus pruebas hicieran lo que quieres o que daban error en alguna parte y no lograbas encontrar dónde. Es lo que diferencia errores semánticos de errores sintácticos...

Si las 2 primeras pruebas las cumples correctamente, pasamos a las siguientes.., esencialmente son lo mismo con una simple connotación, pero si sabes librar una de ellas, la misma solución (salvo grave omisión, alivia también la siguiente)...

Resistencia a la contribución de bits: Se asocia a un 'ataque de extensión por longitud'  y que pretende evitar que H(mensaje), donde no se conoce el mensaje pero si su longitud, podría dar lugar a que H(mensaje) + mensaje2 dé resultados para un hash del mensaje2, sin siquiera conocer el mensaje1 (mensaje).
Una forma simple de resumirlo es que, la diferenciación entre los hashes de mensajes, no sea proporcional a la longitud de los mismos... más aclaratorio, supongamos un mensaje dado desconocido, si se reconstruye el estado de la función hash a la salida y se añade, una supuesta información extra al mensaje desconocido, ¿puede proporcionar un hash válido para el mismo mensaje + el contenido añadido sin conocer la key usada?. No es un fallo en sí de la función hash, si no una estrategia bien pensada para lograr que la función arroje un hash deseado.

Un modo simple de evitar esto, es utilizar en un estadio temprano (no al final, para que no sea retirada dicha info), la longitud del mensaje como parte del mismo mensaje, así el nuevo cálculo del mensaje al ser variado en su longitud, viene variado a su vez desde el comienzo (en base a las dos condiciones previas de 'preimagen')...

Un ejemplo ficticio, para propósitos aclaratorios (ficticio, en el sentido de que sólo es simbólico).
    H("hola, Buenos días...") = "EF6A9B"
Si quiero que el hash fuere otro conocido y precalculado, pongamos "D56BC12"
podría obtenerse en la forma?:
    H("hola, Buenos días..." + loquesea) =  "D56BC12"

Ese 'loquesea', no es cualquier cosa al azar, sino algo bien meditado, la longitud se precisa conocer, porque habitualmente una función hash opera en 'paquetes' de tamaño dado, y suele ser preciso un padding para completar bloques.

Esto: H("hola, Buenos días..." + loquesea) =  "D56BC12" puede funcionar con algunas funciones, desde el momento en que H("hola, Buenos días..."= "EF6A9B", sabemos que lo genera ya la función luego la parte atacante debe considerar si el saliente + loquesea) puede lograr que sea =  "D56BC12".
Ya te digo que una forma muy simple de evitarlo es considerar el tamaño del mensaje como parte del propio mensaje, esto hará que si inicialmente era:
    H("hola, Buenos días...") = "EF6A9B"
ahora con la longitud podría ser (concedamos que por comodidad fuere el mismo hash resultante que el previo):
    H("hola,020 Buenos días...") = "EF6A9B"
entonces ahora:
    H("hola,020 Buenos días..." + loquesea) ya no podrá dar =  "D56BC12"
porque como el mensaje original se desconoce, al añadir loquesea (supongamos que 'loquesea' fuera exactamente ese mismo texto), se computaría como:
    H("hola,028 Buenos días..." + "loquesea") =  "35B88A"
Nota ahora la longitud '028',  como parte del mensaje original que haría que ahora a la salida de (una etapa que acaba en):
    H("hola,028 Buenos días..." ya no generará lo mismo que  H("hola,020 Buenos días..." que es lo que el atacante esperaría...

Algo más sofisticado, sería no considerar la longitud en el propio mensaje pero sí considerar operar con variación en función de la longitud del mensaje... es decir que no opere secuencialmente del modo que siempre se tenga el mismo hash si el contendo previo es el mismo:
    H("h") = ???
    H("ho") = lo previo + considerar lo nuevo que es "o"
    H("hol") = lo previo + considerar lo nuevo que es "l"
    H("hola") = lo previo + considerar lo nuevo que es "a"
    ...
    H("hola, Buenos dí"  = lo previo + considerar lo nuevo que es "í"
(esto es válido también para el 4º caso, resistencia a la resta de bits, ya que es básicamente lo mismo...)

Considera que si el hash, empezara operando por ejemplo desde la mitad del contenido y al término continuar con el comienzo del contenido...
    H("os días...hola, Buen") = "EF6A9B"
Cualquier añadido (al final o al comienzo), variaría el hash, porque no es depeendiente de una alineación izquierda en el cálculo.
    H("ías...loqueseahola, Buenos d" ) =  "4465B0"
Otra forma es en vez de partir por el medio, considerar el módulo de un primo basado en el tamaño del mensaje...
así para el mensaje original: x = (20 modulo 17) = 3
y para el nuevo mensaje: x = (28 modulo 17) = 11
Todavía podría calcularse un 'loquesea' para que tuviere en cuenta esto mismo, por lo que procede mejor duplicalro, primero en cantidad de paquetes y luego el resto de un paquete....
    x = (((size(mensaje) modulo 17) * 7) +  (size(mensaje) modulo 7))
Como hab´ra mensajes largos y mensajes cortos, sería incluso mejor considerar otro idéntico para cada tipo de mensaje.
    y = (((size(mensaje) modulo 11113) * 251) +  (size(mensaje) modulo 251))
y luego unificarlos:
    z = (x modulo 11) * 29) + (y modulo 29))

Luego z sería en punto del mensaje donde empezar a calcular el hash. Cualquier manipulación añadiendo contenido al mensaje original o sustrayéndolo cambiará ese punto y por tanto el hash resultante... con lo que queda imposible forzar a que se compute un hash específico, a base añadir contenido...

Espero que el tocho aclaratorio sea suficiente para que entiendas el caso... el problema básico a que refiere es la correlación directa de un contenido sobre un contenido + un añadido y la forma más sencilla de evitarlo o una más sofisticada (pero todavía fácil).
Si tu función dispone de varias fases distintas, provee un orden distinto según el tamaño de origen...  eso limita bastante más, posibles colisiones forzadas, buscadas a partir de añadir contenido.

La solución HMAC, no me convence particularmente...
     HMAC = H(key, H(key, contenido))
Preferiría más bien:
     HMAC = H(key, (contenido + H(key, contenido))
pero claro, esto es más costoso en tiempo. Además tampoco me termina de agradar que el hash quede concatenado siempre al final del contenido...

Si te queda alguna duda, avisa...


modificado, para añadirle vistosidad con negritas e identación y no resulte tan tocho...