Recomendaciones para el Dane sobre la seguridad del eCenso

si entendí bien, como han dicho por acá en algunas ocasiones, póngale cero. nuevamente, si entenddí bien, son errores que parecen muy de novato y no se entiende cómo es que en un proyecto de alcance nacional suceden estas cosas.
explicación: lo que dice acá es que revisaron el código de la página y encontr´ço que las claves se estaban conviertiendo en un algoritmo de hash. la verdad no importa qué algoritmo se use, es el hecho que la conversión se haga desde la página, y no desde el servidor. explicación 2: se supone que los datos privados, en lo posible deben quedar convertidos en otro formato. hay unos datos que cuando se almacenan en una base de datos se guardan convertidos, hay otros datos que no, y la razón por la que no todos los datos se convierten, es porque esos datos se usan para hacer búsquedas. por ejemplo, si quisiera hacer una búsqueda por nombre, no esmuy práctico desencriptar todos los nombres para luego hacer la búsqueda, pues paracada consulta le tocaría hacer la conversión de todos los nombres en la base de datos, y no es viable (o se puede, pero no podría hacer todo eso para cada consulta que se vaya ahacer, a la velocidad a la que se requiere). otros datos, como las claves de ingreso, no seguardan tal cual, sino se guardan convertidas, para que si pasa algo, el que se robe las claves no la tenga tan fácil. para ingresar al sistema no necesita la clave como tal, sino que convierte lo que el usuario ingresa comio clave, y lo compara con la clave convertida que tiene en la base de datos. sin embargo, la conversión se debe hacer en el servidor. hay unas conversio9nes que sehacen directamente en la página wweb, como revisar la ortografía, como revisar que la dirección de correo está bien escrita y esas cosas, pero por un lado, lo que llega al servidor donde está la base de datos le llega por un cable, pero el servidor no sabe lo que hay al otro lado del cable; no sabe si la información le llegó desde la página web de donde debe llegar, os i alguien hizo una aplicación que envía dats que no son, o si yo mismo hice mi propia página web que envía datos sin validar. el servidor no sabe quiéne nvía los datos (las cookies, los gets y los post). esos pueden venir de cualquier fuente; demanera que cosas como l de convertir la clave en otra cosa (el hash) nunca deberían hacerse desde la página web, sino desde el servidor, y es un error muy denovato, y es difícil entender cómo le asignan un proyecto a alguien que comete esa clase de errores. y eso abre las puertas a cosas todavía más peligrosas.

editado: con respecto alo de ‘colisiones en el algoritrmo de hash’, ése no es el problema. explicación 3: hay diferentes tipos de convertr a cadenas encriptadas. encriptar no es lo mismo que aplicar un hash, aunque en general el hashing se usa como método de seguridad. una cosa es la comunicación de varios tipos de datos a través de un cable donde el que está al otro lado del cable debe entender lo mismo que yo envié, y otra cosa es algo como lo del hashing que se usa para guardr claves. en qué consiste lo de colisión: en que el hashing puede que no sea una función ‘uno a uno’. para los que no lo recuerdan de las clñases de matemáticas o no lo vieron o no lo han visto aún, una función uno a uno es algo que si yo divido la función en rango y dominio, para cada elemento del rango existe unúnico elemento ene l dominio (pues si no no sería una función), pero también aplica lo contrario, que para cada elemento en el dominio sólo existe un valor ene l rango para el que se obtiene ese valor. por ejemplo, la función más 1 (+1), para cualquier número que yo le dé, sé cuál es el número al que se le sumó el 1, por ejemplo si digo 3,sólo hay un núm,ero al que al sumarle 1 da 3 (el 2) pero si digo ‘la función cuadrado’ las cosas cambian, porque si digo 4, el 4 es el cuadrado tanto de 2 como de -2. el cuadrado no es ua función 1 a 1. para el hashing no me importa que no sea una función uno a uno (y lo de las colisiones se refiere a eso, que varias cadenas que yo puedo ingresar en como claves terminanc on el mismo hashing), pero síme importa que no haya tantas colisiones, que sea una función qu emás o menos se disperse en forma pareja pro todo el dominio de resultados posibles, y que sean varios resultados posibles. en el caso del md5 hay variso resultados posibles, y aunque de hecho sí es posible aplicar fuerza bruta para obtener un valor para el cual el resultado del hashing sería ése (y que se podría usar como clave), es posible pero no tan fácil. para comparar, existen millones de posibles resultados para un hash, pero por otro lado me parece que lo del reconocimiento de caras de apple puede fallar con una cara entre 50mil (si no me equivoco). esos ignifica que ‘adivinando’ posiblemente necesite millones de intentos para atinarle a la clave correcta, pero necesitaría 50 mil máscaras para desbloquear un teléfono de apple. aunque obvio, e smás fácil teclear y me demoro menos que haciendo una máscara por cada intento. y sea cual sea el algoritmo de hashing, si es hash lo que se hace, pues habrá colisiones, aunque menos (puede que el otro algortimo tenga más millones de posibilidades, y sea más difícil obtener un posible valor que devuelva ese valor de hash)

editado 2: la verdad lo del hashing no es tan relevante, pues si yo fuera una agencia que estuviera dispuesta a gastar plata en ese tipo de cosas o estaría construyendo o ya tendría las 50 mil máscaras listas, o alguna máquina con la que apartir de fotos yo pueda hacer una máscara en 5minutos; eso es casi irelevante, y aunque un ‘hacker’ casero puede que no ten ga el presupuesto para eso, sí tendría algo de poder computacional y mucho tiempo libre. el cuento es que no llegueb al archivo de claves, estén encriptadas o no. pero si ud llega a un restaurante y ve a través de la puerta de la cocina una cosa por la que le están echando perros y gatos recogidos de la calle y por el otro lado salen salchichas, no es que digan que ‘con las hamburguesas no hacemos eso y ésas sí son seguras’, es que no importa lo que diga ud ya no les cree.