Algoritmo inscripcion autenticacion

[matake]

Hola,

Después de muchísimas vueltas y reflexionando sobre los consejos que me dio kub0x en mis post anteriores  he pensado en el siguiente algoritmo de autenticación:

Inscripción:
 Cliente:
   - Escoge un nombre usuario
   - Proporciona su numero de teléfono móvil
   - Envía estos datos


 Servidor:
   - Crea una tarjeta de coordenadas con 20 de coordenadas aleatorias (como
     sugirió kub0x números entre 10.000 y 99.999)
          A      B     C    D
      1  --     --    --    --
      2  --     --    --    --
      3  --     --    --    --
      4  --     --    --    --
      5  --     --    --    --
          Escoge 3 de ellas al azar.
      Ej: A3,C5 y D4 (12345, 99876, 68872 )
      
      Suma los numeros pertenecientes a cada coordenada entre si
      A3 = 12345 = 1+2+3+4+5 = 15
      C5 = 99876 = 9+9+8+7+6 = 39
      D4 = 68872 = 6+8+8+7+2 = 31
      
      Concatena estos resultados en una variable "$base"
      $base = "153931";
      
   - Escoge 1 color al azar de los 7 básicos del arco iris
   
   - A cada color corresponde un array aleatorio de números   
   Ej: $rojo = [4,0,3,1,2,5] donde cada elemento del array representara la posición
      dentro de "$base"
      
   - Emplea este array como algoritmo para alargar la "base" para emplearlo como
      passphrase
      
   Ej: $rojo[0] = 4 representara el quinto elemento de $base (empezando con 1)
       que seria en este caso el 3
   entonces hace 153931 ^ 3 = 3647356987253491 y lo concatena como string en
       una variable $passphrase
      etc ... etc ver ejemplo PHP abajo      
     En el ejemplo he utilizado potencias ... pero se podrá usar lo que uno quiere
      

Código (php) [Seleccionar] Expandir

$passphrase = '';
$base = "153931";
$algoritmo = [4,0,3,1,2,5]; //$rojo

foreach($algoritmo as $posicion){
if($base[$posicion] == "1"){
$exponent = "10"; //para no dejarlo a la potencia 1
}else{
$exponent = $base[$posicion];
}
$passphrase .= bcpow($base,$exponent);
}

//lo que daría como resultado la passphrase siguiente:
//36473569872534917468973308479888166911376979002445509842001282099801485215668609954341030161369639802607001968497718642322204407729767913865136473569872534917468973308479888166911376979002445509842001282099801
      
      
      Esta sera la passphrase "P"   para ser empleada en el cifrado simétrico    
      36473569872534917468973308479888166911376979002445509842001282099801485215668609954341030161369639802607001968497718642322204407729767913865136473569872534917468973308479888166911376979002445509842001282099801
      
       Envía al usuario por SMS la tarjeta de coordenadas + La referencia a una de las tres coordenadas empleadas mas arriba ej: D3 y el color ej: rojo (verán mas abajo en la autenticación porque D3 y no D4 que se utilizo realmente )
      
   Lo que el usuario tendrá que memorar seria "D3" y "rojo" ... la tarjeta de coordenadas la imprime o la apunte (de todos modos aconsejado que la borre del móvil)
      
   En el servidor se guarda:
   Un hash (sha3) sobre la passphrase "P"
   La tarjeta de coordenadas y los datos del usuario cifrados (simétrico) usando la passphrase "P"
   Dos referencias a las coordenadas de la tajeta Ej: A3 y D4 (para este caso)
   Y un numero de referencia de 1 a 20  en vez de la tercera coordenada ej: 1 (verán mas abajo en la autenticación porque 1 en el caso actual)
   Guarda también el color que escogió (o un hash)
      
   Enviara al administrador la passphrase P cifrada con otro algoritmo (parecido  al de arriba) y este lo guardara en una maquina sin conexión a internet + otras medidas de seguridad (para comprobar manualmente en caso de perdida).      
      
      
      
      
Autenticacion:
   Cliente:
    - Introduce su nombre usuario
   
   Servidor:
    - Si el usuario es correcto    
    - Le pide escoger su color (que memorizo)
    - Si el color es correcto le manda el algoritmo utilizado Ej: $rojo = [4,0,3,1,2,5] ,
          las dos coordenadas que se usaron para construir la passphrase mas un numero explicado mas abajo
    - S le pide que sume de memoria (o en papel ideal seria que si lo suma en una calculadora que no sea la del  aparato con el que se esta conectando a internet)
   Normalmente no seria tan difícil sumar 5 números de memoria
   y apuntar solo el resultado en la casilla correspondiente (y no el valor de la coordenada)
   Ej:
   A3 = 12345 = 1+2+3+4+5 = 15
   C5 = 99876 = 9+9+8+7+6 = 39
      
   Para la tercera referencia (Que se supone que memorizo al inscribirse y recibio D3 en vez de D4 que se utilizo realmente )  solo recibe el numero 1
   Entonces se le pide a que al la coordenada que memorizo (D3) le suma 1 (en este caso ) lo que le dara D4 y que haga la suma como en las de arriba y apunte el resultado en la casilla
      
   secreto +1 = D3 +1 = D4 = 68872 = 6+8+8+7+2 = 31   
      (llamaremos secreto a la referencia D3 que el usuario tendra que memorizar)
      
   Si el secreto era D5, entonces D6 no existe (porque solo hay 20 coordenadas) y el siguiente sera A1 (algo parecido a los módulos) empezar desde el principio
   o si el numero que recibe el usuario sera mas grande por ej. 10 y el secreto es D3 entonces la coordenada correcta seria B3
   O sea si contando desde su secreto el nr que recibe llega al final D5 ... continua con el A1 A2 etc
       Ej:
       D5 + 1   = A1
       D3 + 6   = A3
       D3 + 10 = B3 ... etc

      
   El resto se hace automáticamente en el lado cliente y se regenera la passphrase P
   la cual se puede primero comprobar con su hash y si esto es ok se autentifica y se  desencriptan sus datos
      
   Si la autenticación es OK el servidor genera otros credenciales para la siguiente autenticación
   También controla la sesión en curso con combinaciones de tokens + tiempo + la passphrase correcta que no se utilizara otra vez para login
      
      
      
Resumiendo:


   - El usuario solo tendrá que memorar Un color (ej: rojo) y dos dígitos  ej: D3 (y no el contenido de la coordenada.  Solo la referencia)
   - Si alguien intenta mandar su usuario y su color pero no llega autenticarse se le notificara al usuario y si las dos coordenadas pedidas son correctas, (pero no la secreta) se pregunta al usuario y si no ha sido el, se le cambia la tarjeta de coordenadas obligatorio
   - La passphrase no se guarda en ningún lado (eventualmente el administrador las guarda en otra maquina con otro cifrado y sin conexión a internet para recuperación y comprobación de los datos manualmente en caso de perdida)
   Se le puede pedir al usuario al principio si acepta esto ... pero si no acepta ... pierde todo si se pierde la tarjeta de coordenadas o se olvida la que tiene como secreta
   - No revela los números de las coordenadas que tiene
   - La coordenada que tiene secreta siempre es otra (Aunque el memoriza la misma siempre)
   - Aunque se le robe la tarjeta de coordenadas no se podrá saber cual es la secreta (bueno ... digamos ... bastante difícil)
   - Siempre que se ha conectado de otra maquina se le avisa
   - No habrán nunca dos sesiones permitidas al mismo tiempo
   - Esto si, tiene que hacer unas sumas simples de memoria ( Eso le tendrá el cerebro entrenado )
   
   
   
   Bueno dicho esto, como muchas cosas, en teoría parece bien pero con mis escasos conocimientos de matemática no se si esto seria un sistema fiable por esto espero sus opiniones
   
   
   Cada paso se puede complicar de varias formas pero espero primero vuestras opiniones, criticas , mejoras ,puntos debiles etc.
   
   Como duda mas grande que tengo por ahora: ¿es la passphrase P fuerte desde el punto de vista criptografico ? (se pasa tambien por pbkdf2 )
   He olvidado decir :
   Para el cifrado simétrico he pensado en el AES-256 CBC siguiendo los consejos de @kub0x:
   Salt e IV aleatorios,
   pbkdf2 con iteraciones diferentes por cada algoritmo, usuario y autentificacion para la  "passphrase" ,
   cifrado AES-256 CBC padding: Pkcs7 ,
   hmac para el control de integridad
   
   
   Saludos y espero vuestras opiniones
      
      
      
      
      
      
      

[kub0x]

Buenas matake, bonito problema combinatorial, recuerdo cuando empecé a interesarme por la crypto, un amigo cercano me dijo: Déjaselo a los matemáticos, y desde ese día me puse la meta de comprender la matemática subyacente así como estudiar nuevos campos relacionados con la crypto. Lo que quiero decir es que proponer es fácil, pero la mayoría de veces romperlo (criptoanálisis) por tus medios no lo es. Hoy día sigo peleando con ese gigante pero ya le he ganado unas cuantas batallas.

Suponemos que conocemos las credenciales usuario/password del usuario en cuestión. Por lo tanto nos quedan tres incógnitas: color y tres coordenadas de la tarjeta. Suponiendo que el intercambio está cifrado por TLS (HTTPS) poco podemos averiguar de ahí, por lo tanto:

Primero debemos de hallar el color. Son 7 colores antes de proceder al cálculo de la base que nos deja P. Probabilidad [latex]\frac{1}{7}[/latex]. En una tirada tenemos el 14% de hallarlo. En el peor de los casos 7 intentos bastarían para hallar el color asignado a ese usuario. El atacante sabe que estás mapeando números de 5 digitos (10.000 hasta 99.999) a un espacio de 2 dígitos con tamaño 44 (1 hasta 45). ¿Por qué? -> Coge el máximo (99.999) haz la suma digital y obtienes 9*5=45. Ten en cuenta que la suma digital de dos números capicúa, permutados y al reverso es la misma. Al mapeo lineal de 5 a 2 dígitos se le conoce como homomorfismo matemático.

Ahora que sabemos el color procedemos a la parte "complicada", hallar la suma digital de las tres coordenadas desconocidas por el atacante. Trabajaré con las coordenadas que diste, A3,D4,C5.

Si la suma digital de varias coordenadas es la misma: SD(A3)=SD(D4)... por lo tanto nos queda una variación con repeticion de 44 elementos (suma digital mínima->1 - suma dígital máxima 45) tomados en 3 (son 3 coordenadas) VR(44,3) = [latex]44^{3}= 84184[/latex]  intentos en el peor de los casos para hallar la base. Como ya sabemos el color, es trivial calcular P haciendo exponenciales a la base tomando sus dígitos como exponente dependiendo de la posición del algoritmo del color.

Si la suma digital de todas las coordenadas son distintas: SD(A3)!=SD(D4)... Pasamos de la VR a la variación estándar (V) [latex]\frac{44!}{3! \cdot 44!}= 79464[/latex]  intentos para hallar la base en el peor de los casos.

No todo acaba aquí. Pensándolo bien, darle al usuario la tarjeta de 20 elementos con cinco cifras es lo mismo que darle la tarjeta con la suma digital de esos 20 elementos.

Posibles mejoras:

- El color no es más que una permutación del máximo de dígitos de la base. En este caso son máximo 2 dígitos por coordenada, la base son 3 coordenadas = 2*3 = 6 dígitos tiene la base como máximo. El color sería [latex]P_{6}=6!= 720[/latex] posibles "colores" o vectores de posición. Si el atacante supiera la base pero no el vector permutación, tendria P, pero desordenado. La probabilidad de acertar el vector permutación ahora es infima según vaya incrementando el número de dígitos máximo de la base.
- Incrementar el espacio numérico de las coordenadas para que la suma digital sea más grande hasta que la variación estándar y la repetida queden intratables (lo desaconsejo debido a que una coordenada de 20 dígitos todo a 9's tendria una suma digital de 180 máximo. Con 1500 dígitos la suma dígital máxima seria de 13500 y ahí ya podría ser intratable con 2.4 billones de intentos para hallar la base. Quizá con estas dos modificaciones (vector permutación e incremento del espacio numérico de la suma digital) el esquema sea seguro y fuerte.

Agarre por donde lo agarre lo rompo. Añadir capas de restricción como bloquear al de 3 intentos y re-generar la tarjeta solo añade complicaciones y mala disponibilidad del servicio, ya que Internet no es una utopía y hay mucho listo suelto.

Aun así, no te desmotives. Por cierto esta pregunta reciente me recordo a tí -> https://crypto.stackexchange.com/questions/41643/having-access-to-multiple-servers-would-additional-usage-of-secret-sharing-fo

Puedes leer sobre Secure Multi-party computation (https://en.wikipedia.org/wiki/Secure_multi-party_computation) se basa en no intercambiar el secreto para establecer una veracidad sobre la autenticación. Y haciendo alusión a la introducción de mi post: estos temas dejaselos a los matemáticos Para ello ya hay docenas de algoritmos para la autenticación e identificación de extremos, bien provados y que son seguros.

P.D = ¿Quizá se me haya pasado algo por alto? Dale un par de vueltas a mis argumentos y me comentas.

Saludos!

[matake]

Primero gracias por tu tiempo kub0x

Déjaselo a los matemáticos

 Tienes toda la razon.

y desde ese día me puse la meta de comprender la matemática subyacente

Aquí también lo has clavado ... has conseguido convencerme que por aqui esta el camino para mi también.


Lo que pasa es que hasta alcanzar dicha meta ( o intentar acercarme a ella ) tengo que sobrevivir de alguna manera  (ademas tengo medio siglo de vida y sera mas difícil de roer huesos del gigante a esta edad)


He mirado un poco lo de Secure multi-party computation y Secure two-party computation pero no he insistido mucho viendo que se requiere un tercero de confianza (que en caso de la web supongo que seria un servidor ... ¿me equivoco?).

Inspirado en tu firma "No hay amigos, ni enemigos, lucha necia, todos contra todos" ... pues igual con los servidores en que servidor voy a tener yo 100% confianza


Volviendo a los matemáticos, (por esto me gustaba lo del Shamir sharing secret) pero no hay matemático que pueda hacer que al querido cliente no se le robe su secreto con un keyloger, troyano etc o en el caso de Secure multi-party computation (y otros por estilo), que no haya listo suelto (como tu decías) que no entre algún día en dicho servidor de confianza.


Así que para luchar con el gigante (como no conozco bien sus armas)... haré otro intento pero jugare sucio ... o sea intentare no emplear las armas del gigante (la matemática) ... y empleare las manos, los ojos, y cabeza del querido cliente ... que por cierto no va a ser contento con el trabajo que le voy a dar, pero si clama seguridad ... que venga con su contribución para poder alcanzarla !!! (¿No les parce correcto ?)


Entonces Voy a dividir el acceso de los usuarios en dos secciones:

- Una para poder trabajar, donde se usa el usuario y contraseña de toda la vida + (https TLS ... para toda la web no solo login)

- Y otra sección para datos sensibles + otras cosas que necesitan mas seguridad para la cual el cliente genere manualmente una passphrase (la P de antes) de al menos 30 digitos de longitud (y de un solo uso) pero sin revelar mucha información de su tarjeta.


  - El cliente  memoriza solo una referencia ( que le da el servidor al inscribirse ej D4 de antes )
  (¿Me explico? no memoriza el valor de la coordenada solo su referencia D4)
   
  - El servidor le manda un numero (entre -10 y +10) ej: 5 (que lo sabe desde cuando genero la ultima passphrase)
   Entonces el cliente cuenta 5 coordenadas en su tarjeta empezando desde la que tiene memorada (D4)
   Lo que le dará A3 (porque la D4 es la penúltima de su tarjeta y D5 la ultima)
   
   - Apunta a mano en un papel el valor de A3 mas los valores de sus vecinos A2 y A4 (en una sola linea)
   Ej:
   791624629153825 (15 digitos de tres coordenadas)
   
   - Ahora emplea como algoritmo los mismos dígitos que conforman el numero resultante de arriba
   Tacha el primer dígito (7 en este caso), cuenta siete dígitos adelante llegaría hasta el 6
   y apunta sus vecinos (4 y 2) o sea ahora P = 42
   Tacha el segundo dígito 9 cuenta nueve dígitos adelante, le sale 1 y apunta sus vecinos (9 y 5)
   Ahora P = 4295
   etc ... etc ...

   Si contando, supera al final continua empezando desde el principio
   Ej: para el 8 (el que esta a 3 posiciones antes del final)
   cuenta hasta el 2 (el quinto dígito desde el principio) y sus vecinos son 6 y 4
   Espero que se entiende

   - Al final P = 429596212621582171952785642712 (30 digitos)
   

 Solamente pido tu opinión (o de otros conocedores) y si ésta es también fácil de romper, ya no te molesto mas (tonterías por la cabeza me pasan millones )
 
 Como mejora ya me ha pasado una tontería ( en este instante ) ... hacer dos tarjetas esta misma numérica para el algoritmo de conteo y otra alfanumérica (mayúsculas + minúsculas + números) de donde escoger para construir la P
 
 Y otra ... no paro en soltar tonterías Para que la longitud de P no sea fija, escoger el primer dígito
 Ej actual 4 contar cuatro desde el mismo llegamos al 5 y agregamos los 5 dígitos contando desde el 5 (59621) al final de la P

 ahora P = 42959621262158217195278564271259621 (35 dígitos) y nunca no se sabrá cual es la longitud
 
 También quiero subrayar que ésta seria de un único uso (como las OTP) cada vez el servidor genera otra para la siguiente autenticación ( mejor dicho autorización, para cuando hace falta, ya que para autenticación utiliza contraseña normal)
 
 Saludos y gracias por adelantado.
 
 P.D (Perdone también por mi Castellano ... lo aprendí "a la oreja")

[kub0x]

Buenas noches matake,

nunca es tarde para adentrarse en un tema y estudiarlo a fondo, en este caso las matemáticas, pero bueno yo soy muy joven que te voy a contar... Sobre lo de sobrevivir, lo entiendo, cada uno tenemos nuestra ocupación, y bueno, mi meta es sobrevivir de este gigante (ya me veo pidiendo en una esquina ).

En criptografía existe algo llamado el principio de Kerckhoff, con el cual quizá estés familiarizado. Este principio nos dicta las directrices que debe seguir un criptosistema, independientemente de su aplicación. Se puede resumir en que el sistema debe de ser conocido por el atacante pero sin revelar información subyaciente de los valores observados (fíjate en los hashes, assymetric-key crypto, symmetric-key..), debe de ser "trivial" de computar y sin apenas interacción del usuario.

Ahora, toma 5 minutos de tu tiempo y pregúntate si tu sistema cumple dichos principios:

   The system must be practically, if not mathematically, indecipherable;
   It should not require secrecy, and it should not be a problem if it falls into enemy hands;
   It must be possible to communicate and remember the key without using written notes, and correspondents must be able to change or modify it at will;
   It must be applicable to telegraph communications; (Aquí nos moveríamos en el mundo de Internet)
   It must be portable, and should not require several persons to handle or operate;
   Lastly, given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules.

Inspirado en tu firma "No hay amigos, ni enemigos, lucha necia, todos contra todos" ... pues igual con los servidores en que servidor voy a tener yo 100% confianza
Volviendo a los matemáticos, (por esto me gustaba lo del Shamir sharing secret) pero no hay matemático que pueda hacer que al querido cliente no se le robe su secreto con un keyloger, troyano etc o en el caso de Secure multi-party computation (y otros por estilo), que no haya listo suelto (como tu decías) que no entre algún día en dicho servidor de confianza.

La verdad, mi firma define muy bien el mundo en Internet (y en cierto punto la sociedad), siempre digo en mis respuestas que una vez ganado acceso al equipo del usuario/servidor la crypto está totalmente rota e inservible. En criptografía jugamos con otro tipo de suposiciones, simplemente nos basamos en la información que se puede obtener a través de la observación de ciphertexts, intercambio de claves etc. En cualquier esquema, si al usuario se le roba su valor privado -> GAME OVER. ¡No siempre eh! imagina que al usuario se le roba su private-key pero esta esta cifrada por AES-256-CBC, no me quedaría otra que ver en que equipos posiblemente esté almacenada, pero quizá no lo esté... Con esto quiero decir que cuanta menos información se guarde mejor.

En tu caso sucedería lo mismo, da igual cuantas veces cambies el sistema que si se le roba la tarjeta adios. Vale, el atacante no sabría el valor privado (a no ser que entre al server), pero teniendo la tarjeta del usuario, no tardaría mucho en adivinar el valor privado antes de que el usuario reporte el robo o se de cuenta de la intrusión. El factor de segunda autenticación siempre se podrá romper robando el dispositivo de identidad asignado al usuario (y en biometría ya ni me meto ).

Ahora, basándonos en el principio de Kerckhoff, ten en cuenta que cualquiera sabrá como generas P, también sabrán como te comunicas con el servidor y que información recibirás del mismo. Sabrán que utilizas 3 coordenadas para la generación de P inicial, cada una de 5 dígitos (de 10.000 a 99.999 -> 89.999 valores posibles). Hallar esas tres coordenadas es complicado, se basa en un problema combinatorial con [latex]7.28951401\cdot10^{14}[/latex] posibilidades (V(89.999,3)).

El atacante comienza a desesperar por la complejidad de adivinar el trío de coordenadas, entonces empieza a estudiar con detenimiento la generación de P final suponiendo la P inicial (concatenación de las tres coordenadas). Si el atacante da con una breaktrough sobre la derivación de la P final a través de la inicial, entonces se habrá ahorrado adivinar el trío de coordenadas. El mismo sabe que P final cuenta con 30 dígitos, a simple vista, en el peor de los casos y siendo brutos, son [latex]10^{30}[/latex] posibilidades (muy muy brutos..). Sin embargo, día tras día, empieza a ser imas ingenioso, y se da cuenta de lo siguiente:

El quiere adivinar [latex]P_{final} = 429596212621582171952785642712[/latex] pero la desconoce. Sabe que cogiendo el primer dígito, tachándolo y contando el número de cifras hacia delante haya el siguiente número para seguir generando [latex]P_{final}[/latex] pero como la inicial la desconoce, sigue sin sacar nada en claro. Entonces reconstruye [latex]P_{final}[/latex]:

Supone que [latex]P_{1} = 42[/latex] y supone que el 4 es la última cifra de la primera coordenada y el 2 la primera cifra de la segunda coordenada. Por lo tanto supone que se ha contado 7 veces y ya tiene la primera cifra de la primera coordenada. A3 = 7xxx4. Ya sólo le falta calcular 3 dígitos de A3.

Como ves, esto último es un ataque más ingenioso, y es lo único que se me ocurre para atacar tu sistema, algo basado en la suposición y análisis por conteo. Puede que con tiempo y semanas, pueda ser capaz de obtener toda la matriz de coordenadas (tarjeta) haciendo pruebas con el servidor a ver si la [latex]P_{final}[/latex] es la correcta, y sin robar nada al usuario.

Lo mejor es usar una tarjeta de coordenadas electrónica con renovación semanal/mensual dependendiendo del grado de seguridad, al estilo de los bancos. Sólo pides tres coordenadas al usuario y ya, no hace falta realizar más operaciones, y así te ciñes sólo a que el atacante tenga que adivinar [latex]7.28951401\cdot10^{14}[/latex] posibilidades (V(89.999,3)). Recalco, los bancos hacen esto y me parece, trivial, sencillo de implementar y estupendo, por que si recuerdas, ante un robo de credenciales, da igual que uses un sistema complejísimo y robusto o uno más simple pero robusto al mismo tiempo.

Dale un par de vueltas a mi respuesta y me comentas Al final eres libre de usar el sistema que quieras, pero antes de implementar, sigue comentando tus ideas.

Saludos!

[matake]

Muy buenas noches kub0x

Desconocía lo de Kerckhoff pero algunos puntos si que los sabia por otras lecturas ( como que mejor que sea conocido y fuerte por su propia fortaleza que por el ocultismo incluso que no sea muy complicado pero no se me ocurría otra cosa )


Por mi parte me gustaría uno con un simple click ni contraseñas ni nada, estilo captcha este "No soy un robot" pero estoy consciente que no es posible.


Llevo solo unos meses tocando un poquito mas de cerca el tema de la seguridad y al principio creí que con https se resuelve la cosa. Pronto me di cuenta que resuelve solo el transporte entonces he empezado ( cuando me ha quedado tiempo ) en alguna manera en cifrar los datos ... luego surgió la pregunta: ¿Y la clave donde lo guardo? ... y de allí llegue a CryptoJS para hacerlo desde el cliente ... el resto lo conoces.

imagina que al usuario se le roba su private-key pero esta esta cifrada por AES-256-CBC, no me quedaría otra que ver en que equipos posiblemente esté almacenada, pero quizá no lo esté... Con esto quiero decir que cuanta menos información se guarde mejor.

De acuerdo contigo pero llegamos al kelogger + los demás y estará cifrada por AES-256-CBC con una passphrase que tiene que introducir en la maldita casilla

Lo mejor es usar una tarjeta de coordenadas electrónica

No entiendo que quieres decir con electrónica. ¿Hay alguna con chip o algo así?

He mirado en google y lo que vi es (en la cajarural) "Tarjeta de firma electrónica"  o sea la llaman electrónica pero es la misma de las coordenadas nada de electrónico.  Además no voy a tener los medios al principio para permitirme esto.


Como te dije al principio sabía que no tiene que ser complicado y la manera en que la he pensado yo no solo que no es trivial ... Es un verdadero coñazo !!!... Imagínate medio planeta ( que intento conquistar   ) con sus bolígrafos, contando dígitos en sus tarjetitas ... y maldiciéndome a mi )))))

Claro que me gustaría algo más sencillo pero por ahora no se qué.

A no ser que no he entendido yo bien: O sea sin el rollo del conteo en el cual he pensado, ¿quieres decirme que es bastante robusto así pedir directamente 3 coordenadas ( y cambiar la tarjeta cada cierto tiempo )?

¿O quedarme  solo con la parte (de la idea que tenia) de la coordenada secreta + un pequeño conteo ( sin boligrafo) y escoger la coordenada que coincide con el conteo + dos vecinas?



Muchísimas gracias por tu ayuda kub0x

P.D.

En tu caso sucedería lo mismo, da igual cuantas veces cambies el sistema que si se le roba la tarjeta adios. Vale, el atacante no sabría el valor privado (a no ser que entre al server), pero teniendo la tarjeta del usuario, no tardaría mucho en adivinar el valor privado antes de que el usuario reporte el robo o se de cuenta de la intrusión

El valor privado no se guardaría en el servidor ... se envía al usuario al inscribirse (para que lo memorice) y no se guarda nada sobre el ni hash ni nada solo se guarda la diferencia entre el valor privado (D4) y el valor usado (A3) en el ejemplo seria la cifra 5 y a los 3 intentos si que el cliente sabrá porque se bloquea.

La tarjeta entera si tiene que guardarse con los otros datos del cliente a cifrar pero cifrados AES-CBC con la passphrase P.

A no ser que quieres decir que al saber esta distancia 5 ... intentara todas las posibilidades. Entonces se podrá mejorar hacer el cliente Que recuerde también esta diferencia (seria como su OTP).
O mejor que se renuncia al lio de guardar una secreta, luego recibir el intervalo y luego el conteo.
Darse cada vez que recuerde una como privada como su OTP


Lo que me gustaba mas con la P de 30 dígitos era que al menos para la fuerza bruta parecía mas fuerte (en teoria)

Pero si lo pienso bien ... con una normal (o sea 3 coordenadas 15 caracteres) pero con mayúsculas + minúsculas + dígitos tampoco no se queda demasiado lejos (en teoría fuerza bruta)

Ademas si le añado esto de que memorice siempre una privada como OTP, ni siquiera le digo que coordenadas tiene que ingresar que ya sabe una, mas dos vecinas

Hmm y aqui entra el keylogger o troyano     cuando le voy a dar la siguiente OTP

[kub0x]

El valor privado no se guardaría en el servidor ... se envía al usuario al inscribirse (para que lo memorice) y no se guarda nada sobre el ni hash ni nada solo se guarda la diferencia entre el valor privado (D4) y el valor usado (A3) en el ejemplo seria la cifra 5 y a los 3 intentos si que el cliente sabrá porque se bloquea.

La tarjeta entera si tiene que guardarse con los otros datos del cliente a cifrar pero cifrados AES-CBC con la passphrase P.

A no ser que quieres decir que al saber esta distancia 5 ... intentara todas las posibilidades. Entonces se podrá mejorar hacer el cliente Que recuerde también esta diferencia (seria como su OTP).

Vale entonces el servidor al generar la tarjeta por primera vez escoge D4 y un desplazamiento (5) para calcular A3 y sus vecinas, de esta forma calcula P. Pero si el servidor cifra la tarjeta con P, y sólo guarda el desplazamiento (5), ¿entonces en el siguiente login/autenticación como calcula el servidor P para descifrar el contenido de la tarjeta?. Me explico, la tarjeta estaría cifrada por P, y con el 5 no haría nada, le sería imposible calcular P.

La tarjeta sería mejor cifrarla con un user+pass+salt+iteracciones usando PKDF, así sí que podrías descifrar la tarjeta en cada sesión. Ahora con la tarjeta descifrada, lo óptimo sería cambiar P en cada sesión, por lo tanto el servidor debería conocer el valor privado para calcular un nuevo desplazamiento y hallar las nuevas coordenadas vecinas. Al cliente le enviaría sólo el desplazamiento y así calculan el nuevo P. Ahora el usuario cifra un mensaje aleatorio simetricamente con P (usando PKDF + AES-256 + HMAC) y el server comprueba la integridad del mensaje con P.

No sé, quizá me haya perdido algo

Con tarjetas electrónicas, me refiero a que envíes las coordenadas de la matriz/tarjeta por SMS o e-mail, siendo esta ultima mejor, así el usuario lo imprime y no tienes que entregarlas al estilo banco. Pides tres coordenadas en cada sesión y comparas en el lado del servidor que las coordenadas sean correctas. Es sencillo, práctico y seguro a la vez.

Saludos!

[matake]

La tarjeta sería mejor cifrarla con un user+pass+salt+iteracciones usando PKDF + AES-256 + HMAC

Correcto.(solo que la tarjeta lo guardo junto con los otros datos a cifrar no separado)

Lo que si no creo que has entendido es que al cliente se le manda dicho intervalo -> el cliente regerera la P  y se lo manda asi como esta (por https TLS) al servidor o sea la P del cliente es la passphrase ..  usado para generar el key de  AES  con PKDF  para cifrar los datos en el servidor incluso la tarjeta

Al recibir la P correcta el servidor descifra , tiene la tarjeta , genera otros credenciales (otra P) otro key AES y cifra de nuevo con estas nuevas guardando otro intervalo (el nuevo) y destruye la llave y la P.

Al siguiente login el usuario solo recibe el intervalo nuevo ... regenera la P la manda al servidor y este puede usarla de nuevo como passphrase para regenerar la key ... esto si tiene que guardar tambien las iteraciones ... IV +salt ya los tiene

En el mensaje anterior he añadido algo al final ... justo cuando tu creo que me respondías ... que opinas ?

[kub0x]

Lo que si no creo que has entendido es que al cliente se le manda dicho intervalo -> el cliente regerera la P  y se lo manda asi como esta (por https TLS) al servidor o sea la P del cliente es la passphrase .. el pass que pusiste tu en la cita de arriba usado para AES  para cifrar los datos en el servidor

Era la otra forma que se me había ocurrido. No la he puesto en mi respuesta anterior ya que pensé: no creo que haga que el cliente mandé la passphrase al server. No lo veo conveniente por un motivo, en estos esquemas, lo suyo es que ambos generen P sin tener que compartirla, al igual que Shamir's secret sharing. Esto se debe a que si alguien monitoriza los key-exchanges y rompen RSA/ECC/DH podrán computar la clave AES y ver el passphrase, en cambio si ambos extremos generan P, el atacante debe conocer los valores privados. Aun así, lo dejo como "valido" (entre comillas ).

Ahora que el server es capaz de descifrar la tarjeta en cada sesión ya que el cliente le manda P, ¿cómo calcula el server la nueva P si sólo tiene el desplazamiento y no tiene el valor privado del cliente? Creo que cliente y server no podrán calcular la misma P en este caso, ya que si el server no sabe D4, no podrán establecer la misma passphrase. Para solucionar esto, el server al calcular la nueva P, elige una nueva privada, un nuevo desplazamiento y se los envía al cliente, de esta forma si podrían computar la misma P.

Pero si lo pienso bien ... con una normal (o sea 3 coordenadas 15 caracteres) pero con mayúsculas + minúsculas + dígitos tampoco no se queda demasiado lejos (en teoría fuerza bruta)

Ademas si le añado esto de que memorice siempre una privada como OTP, ni siquiera le digo que coordenadas tiene que ingresar que ya sabe una, mas dos vecinas

Hmm y aqui entra el keylogger o troyano     cuando le voy a dar la siguiente OTP

Si añades caracteres alfanuméricos, el espacio de valores se incrementa y la complejidad de rotura también, pero bueno, con los 5 dígitos numéricos es suficiente.

Con lo de la privada y OTP, en OTP ambos extremos tienen que saber la clave. La nueva OTP, supongo que la entregas cuando el server computa la nueva P, como ya he dicho arriba, el server computa la nueva privada + desplazamiento y envía esa info al cliente, así ambos tienen la nueva P. Hombre, ya estás enviando la passphrase por el canal, no veo ningún incoveniente en que envíes dicha información también. Pero ojo, bajo el punto de vista puro de la crypto, esto no está bien  Se puede hacer, pero confiar en TLS y PKI es decir mucho

Saludos!

[matake]

el server no sabe D4, no podrán establecer la misma passphrase

Tienes razon ... me he olvidado el maldito D4 .... intervalo hacia que hacia yo  ???

No la he puesto en mi respuesta anterior ya que pensé: no creo que haga que el cliente mandé la passphrase al server. No lo veo conveniente por un motivo, en estos esquemas, lo suyo es que ambos generen P sin tener que compartirla, al igual que Shamir's secret sharing

Supongo que tu tienes toda la razon ... al saber sobre el tema pero mi logica, no me deja entender por ahora en donde seria esto un problema ya que de este modo la P no existe en ningun lado .... solo cuando el cliente la envia ... en algunos milisegundos (segundos) queda inutilizable ya que una vez utilizada esta P ... en el servidor se genera otra , se cifra otra vez con otra P nueva, y despues se destruye . Por mucho que alguien ha capturado la P que mando el cliente ... ya no sirve ... ya hay otra .. empleada y destruida tambien.

Ya lo he pillado ... como la P son las coordenadas .... en 5 - 10 intentos tendra toda la tarjeta ... Solo le falta el D4 ... a por el servidor !!!    (o con un poco mas de paciencia ) ... lo adivinara pronto   

.... A dormir ... en España son las seis y media de la mañana  ... y a soñar .... D4 y demas    ... Gracias kub0x

¿Cual seria entonces tu consejo?

Lo leere luego ... Un saludo

[kub0x]

en algunos milisegundos (segundos) queda inutilizable ya que una vez utilizada esta P ... en el servidor se genera otra , se cifra otra vez con otra P nueva, y despues se destruye . Por mucho que alguien ha capturado la P que mando el cliente ... ya no sirve ... ya hay otra .. empleada y destruida tambien.

Así es, en caso que se observe la primera P, el servidor descifrará la tarjeta con esa P, computará una nueva (segunda P) y destruirá la primera. Si alguién fue capaz de observar esa P o hacerse con ella de alguna forma, no valdría pa nada.

Pero no te me líes, el primer consejo que siempre se da a los iniciados en la crypto es, "Never implement your own crypto", con esto no quiero decir que jugetees con la crypto, pero en entornos profesionales es mejor implementar algo que sea considerado seguro por los expertos,

Yo te propondría lo siguiente:

- Servidor genera la tarjeta de coordenadas, se la entrega al usuario y la cifra con AES-256 usando la contraseña obtenida por PKDF -> user+pass+salt+iteracción. La pass es introducida en cada login por lo que descifrarla es posible una vez iniciada la sesión. Si consiguen acceso a tu server, no sabrán más que el hash+salt de la password, pero no sabrán la password que hay detrás del hash, por lo tanto no podrán obtener la tarjeta de coordenadas. Aun así si compremeten tu seguridad, lo ideal es avisar a todos los usuarios por mail y obligarles a cambiar sus credenciales, pero el atacante no podrá saber ni las passwords ni las tarjetas de cada usuario.
- En cada sesión, una vez hecho el login, descifras la tarjeta del usuario con PKDF, escoges 3 coordenadas al azar y le pides al usuario que te envíe su contenido (ej: Dime A3,D2,B1). El servidor compara si el contenido de esas coordenadas son las pedidas, si es así, ya lo has identificado correctamente.
- Como mejora, paranoia mode ON, después del login, el usuario y server podrían generar una nueva clave simétrica (PKDF -> user+pass+salt+it). Ahora el server al hacer el challenge de las 3 coordenadas, cifraría el challenge con esa clave y el usuario respondería cifrando el contenido de esas 3 coordenadas con esa clave simétrica. No sería necesario ya que TLS (HTTPS) ya cifra por defecto al establecer la comunicación, pero bueno, es una capa de seguridad más.

Otro esquema más y el que más me gusta desde el punto matemático, el más empleado en el real world:

-El usuario al registrarse en el servicio, genera en su equipo un par de claves RSA 2048-bit, envía su clave pública al server y guarda la privada firmada por AES-256 en su equipo. La clave simétrica para cifrar la privada la elige a gusto, pero HA DE RECORDARLA (si la pierde tendrá que avisarte).
- Después del login, el usuario genera una clave simétrica AES y un mensaje aleatorio. El usuario computa el SHA-256 sobre el mensaje y lo firma con su privada, esto es una firma digital sobre el mensaje. Ahora el usuario cifra el mensaje aleatorio con la simétrica y cifra la clave simétrica con la pública del servidor y envía al servidor el mensaje aleatorio cifrado, la clave simétrica cifrada por la pública del server y la firma digital.
- El servidor recibe el mensaje aleatorio cifrado por AES, la clave simétrica AES cifrada con la pública del servidor (su pública) y la firma digital. El propio server coge la clave simétrica cifrada y la descifra con su privada, coge la firma digital y la descifra con la pública del usuario (recuerda que fue guardada en el registro), coge el mensaje aleatorio y lo descifra con la simétrica obtenida. Ahora que tiene el mensaje aleatorio en plaintext, computa el SHA-256 y lo compara con el descifrado de la firma digital. Si son iguales, el servidor sabe que el mensaje fue firmado por el usuario y sabe que sólo el propio servidor puede descifrar la clave simétrica. Esto nos da una autenticidad REAL (PGP trabaja así cuando se utiliza RSA+AES).

Saludos!