Mensajes

Creo que el culpable aquí es diferentes metodos de hash_hmac. Tu contador parece estar correcto, lo único que pudiera ser en ese aspecto es que los relojes no estén sincronizados.

Ahora, yo creo que el formato es el verdadero problema. En el RFC de TOTP ellos usan bytes para el secreto y el mensaje. Por ejemplo, si el secreto en ASCII es '12345678901234567890', el hexadecimal de este es:

Código [Seleccionar] Expandir


31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30

Y por ejemplo, si el contador fuera 1, lo que ellos hacen es hacer 0 padding hasta tener 8 bytes.

Código [Seleccionar] Expandir


00 00 00 00 00 00 00 01

En el ejemplo que ponen en su RFC, ellos usan Java y convierten el string hexadecimal a bytes. Para este preciso ejemplo, con Sha-1 y el secreto que mencione, ellos obtienen:

Código [Seleccionar] Expandir



 +-------------+--------------+------------------+----------+--------+
 |  Time (sec) |   UTC Time   | Value of T (hex) |   TOTP   |  Mode  |
 +-------------+--------------+------------------+----------+--------+
 |      59     |  1970-01-01  | 0000000000000001 | 94287082 |  SHA1  |
 |             |   00:00:59   |                  |          |        |
 +-------------+--------------+------------------+----------+--------+

Y simplemente, no doy con ese TOTP sin importar que valores use en el hmac. Intente con strings en hexadecimal y ASCII (con pack). Simplemente, no obtengo esos números. Lo voy a probar con node, porque la libreria crypto en node si me deja usar buffers.

El RFC de TOTP por si te sirve:

https://tools.ietf.org/html/rfc6238

Edit: Ok, vale... pude hacerlo funcionar ya. Tanto el secreto como el contador parece que hash_hmac los toma como ASCII. No puedes enviar un entero como mensaje. Me imagino que PHP simplemente lo convierte a ASCII (1 vendría siendo 31 en hex). El contador también tiene que tener padding hasta que tengas 8 bytes. Un string en hexadecimal necesitaría tener 16 caracteres. Tomas el contador, lo conviertes a un string en hexadecimal y le agregas 0 hasta tener 16 caracteres.

Ejemplo:

3167928 es 3056B8 en hexadecimal. Le necesitas agregar otros 5 bytes (10 caracteres).

Código [Seleccionar] Expandir


00000000003056B8

Y usas pack a ese string:

Código (php) [Seleccionar] Expandir


pack('H*', '00000000003056B8');

Los 0s son importantes...

En cuanto a tu secreto, es necesario que conviertas de Base32 a ASCII.

el presidente de los EEUU pidió que el viaje, planeado en un principio para 2028, se adelantara a 2024.

¿Me pregunto porque sera...?

La primera de estas dos claves depende del Congreso de EEUU;

El congreso está en crisis ahora mismo. Los democratas dicen que pueden caminar y mascara goma al mismo tiempo pero ciertas personitas van a estar obstruyendoles a cada paso.

La llave que se hashea me imagino que debe ser en su forma base32. El secreto que se comparte debe ser el mismo.

Necesitas truncar el HMAC, como dice el RFC. Necesitas extraer 31 bits del HMAC. Lo que dice el RFC es que primero obtengas el offset del cual vas a agarrar los 31 bits. Este offset, son los últimos 4 bits del HMAC. El número que obtengas lo multiplicas por 8 para obtener el inicio del offset. Para obtener el final del offset, solo le sumas 32. De ese offset, solo tomas los 31 bits menos significativos (no tomas el bit más significativo). Lo último es tomar los últimos d digitos de la representación numérica de esos 31 bits. Es un número entre 0 y 2147483648.

Este es un ejemplo HMAC sacado del RFC:

Código [Seleccionar] Expandir


   -------------------------------------------------------------
   | Byte Number                                               |
   -------------------------------------------------------------
   |00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|
   -------------------------------------------------------------
   | Byte Value                                                |
   -------------------------------------------------------------
   |1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a|
   -------------------------------***********----------------++|


Los últimos 4 bits son: "A"(10). Entonces, tomas los bits de 80 a 112, que son:

Código [Seleccionar] Expandir


50 EF 7F 19

El primer bit es 0 así que no importa, pero aquí le aplicas una mascara al bit más significativo (50 & 7F = 50). Este es tu número de 31 bits:

Código [Seleccionar] Expandir


1357872921

En el RFC usan de ejemplo que solo toman 6 digitos. Usan modulo con una potencia de 10 para truncar el número.

Código [Seleccionar] Expandir


We then take this number modulo 1,000,000 (10^6) to generate the 6-
   digit HOTP value 872921 decimal.

Y ya esta, ese es tu HOTP:

https://tools.ietf.org/html/rfc4226

Ya pero no puedo probarlo porque es un ssd msata3 y en cualquier placa no vale, de hecho se lo pase a un amigo que tiene ranura para m2 y no valia, no se como comprobarlo

Yo creo que tienes más probabilidades de encontrarte la interface con equipos portatiles. Hay carcasas de 12 dolares en amazon, por si quieres probar de nuevo. Los SSDs son mucho más difícil de dañarlos que con un HDD, yo también creo que debe ser un problema con tu carcasa, pero no te podría decir si es eso exactamente.

Una banda de respuestas  pero no hacia falta todo eso, yo decía si acarreaba una vulnerabilidad no volver a definir x variable en este caso $_GET

Respondiendo: La aplicación web está en desarrollo por eso no tengo una URL que mandarles para que la vean.

A lo que iba era digamos que yo tengo un comentario que quiero editar, yo me ilustro o imagino que hay como "2 procesos" el "protocolo de seguridad entrante" y el "protocolo de seguridad de envío" (esto me lo invente yo  por si les suena raro)

Bueno el protocolo de seguridad entrante se va a encargar de validar si el usuario tiene permisos para ingresar a x pagina.php

Por ejemplo si el usuario tiene la session iniciada, si el usuario no está bloqueado, si el usuario tiene el email verificado, entre tantas otras que pueda tener una aplicación... dependiendo el caso va a redireccionarlo a otras paginas... por ejemplo si no tiene la session iniciada lo manda a el index pero si si tiene la session iniciada pero esta baneado lo mando a ban.php y así hasta completar todos los protocolos.

Después está el protocolo de seguridad de envío que es cuando un usuario envía un formulario... Generalmente van a compartir el mismo protocolo pero con una diferencia y es que el protocolo de envío va a preguntar si la $session_id es igual a $_SESSION['id_user']

hay les explico (me va a salir tremendo texto bíblico pero así se entiende xD)

Ejemplo:

Código (php) [Seleccionar] Expandir


// protocolo de seguridad entrante
[Si hay sessión iniciada]
     -> [Si usuario no esta bloqueado]
           -> [Se mantiene a el usuario en la pagina]
                [Creo una variable $session_id que va a tener el valor de $_SESSION['id_user']
     [Si no: mando -> ban.php]
[Si no: mando-> index.php]


Imaginen que una persona tiene abierto una pagina comentar.php que requiere que el usuario tenga una session inciada pero ese mismo usuario abre otra pagina comentar.php, hay ahora 2 pestañas abiertas con el mismo fichero... ahora en la primer pestaña va a cerrar su sesión por lo que lo va mandar a el index pero recordemos que dejó abierta otra donde se ve la pagina como si tuviera la sesión todavía iniciada, gracias a el protocolo de envío lo que va a hacer es que cuando el usuario que tiene una pagina abierta que requiere tener la sessión iniciada pero no la tiene lo que va a hacer es redirigirlo cuando intente usar el formulario...

Ahora gracias a session_id lo que va a hacer es que imaginemos ahora que el usuario tiene 2 cuentas, y abre esas 2 pestañas con el mismo fichero php cierra la sesión en una, pero le quedo la otra abierta y vuelve a ingresar a otra cuenta diferente pero ahora tenemos (1). comentar.php con una cuenta (X) y tenemos comentar.php con una cuenta (Y) ...

el protocolo de envio se va a quedar corto porque si va  a detectar que hay una session abierta, no puede decir si es la misma de antes pero si que hay una... entonces con session id lo que hago es compararlas

$session_id == $_session['id_user'] ?

Lo que trato de mostrar con esto (igual ya deben saber) es que cuando el usuario use el formulario van haber datos que se van a "actualizar" que no van a seguir siendo iguales...

Código (php) [Seleccionar] Expandir


<?php
$comentarios = comentarios::Mostrar_Comentarios(); // Muestra todos los comentarios
$comentarios = count($comentarios); // contamos todos los registros

echo $comentarios; // hay 3 comentarios
?>

Ahora imaginemos cuando el usuario manda un formulario

<?php
if(isset($_POST['ver_otravez']))
{
     $comentarios = comentarios::Mostrar_Comentarios(); // Muestra todos los comentarios
     $comentarios = count($comentarios); // contamos todos los registros

     echo $comentarios; // capaz acá pueda mostrar 4 o 5 o capaz menos comentarios, 2 comentarios... porque desde que yo abro la pagina hasta que yo mando un formulario pueden mostrarse datos diferentes (actualizados)

     Si yo acá no volvía a definir la variable $comentarios se iba a quedar con un valor viejo que era el 3
}
?>


A eso iba cuando preguntaba si tenia que volver  a definir variables cuando envío el formulario... por ahí un $_GET no se puede actualizar de otra forma que no sea cambiandolo y recargando la pagina por eso preguntaba...
Yo se que es un poco dificil de entender, más que nada no porque sea dificil sino porque explico para la mrd xD

En ningún momento el usuario vas a tener dos cuentas abiertas por navegador. La única forma de hacer tal cosa sería quizás usar diferentes perfiles de navegador (me imagino que no se comparte la información de navegador en esta instancia, pero nunca lo he probado), usar diferentes navegadores o usar alguna especie de script del lado del cliente que maneje las session ids.

Si tienes un usuario en comentar.php con una sesión iniciada y abre una nueva pestaña, no estás creando dos sesiones en ningún momento. Y si el usuario aborta la sesión en una pestaña, esa sesión ya no existe del lado del servidor (o al menos esa es la definición de borrar una sesión). No se crea una nueva sesión mágicamente.

Las sesiones no se crean del lado del cliente. Tendrías TU que crear un sistema que maneje multiples sesiones (a lo cual no le encuentro un uso práctico, pero quizás lo hay).

No entiendo para que quieres una variable $session_id, ¿Estás abriendo sesiones sin que el usuario haya iniciado sesión? Viene siendo lo mismo, si usas una variable dentro de la sesión para determinar si ha iniciado sesión, al momento que el usuario aborte la sesión tu borras esa variable del lado del servidor. Ya no existe.

[trim]

Olle, pero tienes la función trim, esa te elimina todos los espacios, saltos de línea, etc.

Trim elimina espacios en blanco en los bordes del string, no todos los espacios en blanco.

Volver a asignar el mismo valor a la variable no sirve de nada si ese mismo valor que estás asignando no es de una fuente segura. Es como si le preguntarás a alguien su nombre y para estar seguros de que su nombre es como dice él... le vuelves a preguntar su nombre.

Bryan Cranston lo hizo en el 2013:

No hereda el contexto porque se evalua antes? Se evalua de dentro hacia fuera?

Muchas gracias! Se ve my interesante!

No lo hereda porque el contexto del objeto de una llamada se determina en la invocación de la función (en el caso de funciones regulares). Solo en el caso de funciones flecha es que el contexto del objeto se "hereda" (hay una explicación un poco más larga).

El contexto del objeto es básicamente lo que va detrás de la función o metodo.

Código (javascript) [Seleccionar] Expandir


  obj.fn();
// ^
//contexto

Código (javascript) [Seleccionar] Expandir


       fn();
//^
//no hay contexto
//a menos que sea una función resultante de bind
//misma situación para IIFEs

Código (javascript) [Seleccionar] Expandir


  fn.call(obj);
//         ^
//         contexto