edición general
  1. gallir gallir
    Hoy @DZPM tuiteó un excelente artículo sobre seguridad en el cifrado de claves, y el método de "salt" correcto que hay que usar: crackstation.net/hashing-security.htm

    Haciendo caso a eso (y porque me convenció, el método de salt era lo que sospechaba y no lo que se decía), actualicé (finalmente) el método de almacenar claves en la base de datos. Ahora va "salted" con un clave aleatoria de 32 caracteres aleatorios apto para este tipo de cosas, y luego se aplica el sha256.

    Los cambios: github.com/gallir/Meneame/commit/7ba7f724225d464c7cbc4b925a0076ecd216a

    Si queréis pasar vuestra clave al nuevo método basta que hagáis un login, o que volváis a poner la clave en la edición del perfil.

    PS: Nunca pasó nada con las claves, no hubo ninguna fuga (afortunadamente), pero siempre es mejor estar más seguro, y el md5() ya tenía que morir.
    17 K 187
  1. anacard anacard
    @gallir @DZPM Tengo dudas sobre la ventaja de guardar el salt en la BBDD de usuarios. A ver si me explico:

    Partiendo de la base de que la BBDD ha sido comprometida, entiendo que haber hecho el hash con salt hace mucho más difícil el ataque por fuerza bruta ya que no puede hacer la búsqueda inversa de hashes. Sin embargo, al disponer de la BBDD también se dispone del salt personalizado de cada usuario así que teóricamente es posible hacer un ataque de fuerza bruta para un usuario concreto.

    Es decir, se evita una búsqueda inversa y se dificulta mucho el ataque de fuerza bruta para un usuario concreto, pero podría hacerse, al menos en teoría, desconozco si el tiempo práctico lo hace imposible.

    ¿No sería mejor guardar parte del salt fuera de la BBDD? Es decir, un salt único para todo el mundo es poco seguro porque dos contraseñas iguales generarían dos hashes idénticos pero ¿hacer una combinación entre el salt de la BBDD y un valor que salga de otro origen? ¿No sería mejor?
    2 K 27
    1. DZPM DZPM
      @anacard @gallir sobre guardar el salt en otra db. Cuantos más factores añadas, mejor. Pero:

      - Desventaja 1: No añade seguridad.
      Se asume que alguien que ha accedido a tu base de datos de contraseñas también tiene acceso a esa otra base de datos externa. La dificultad de romper las claves es la misma, por lo que la ventaja 1 desaparece.
      Idem para sistemas que calculan otro factor "secreto" a partir de los datos de usuario (base64 del email, md5 de la fecha de creación, etc). Se asume que el código se filtra.

      - Desventaja 2: Rendimiento y complejidad.
      Si para validar cada usuario tienes que acceder y cruzar datos de varios sitios, el rendimiento empeora. Si usas un slow hash (PBKDF2), ya es bastante lento como para añadir más pasos.


      En todo caso, el artículo se centra en cómo mitigar daños cuando la db de usuarios se ha filtrado. Lo que tú propones es cómo evitar que el atacante se haga con los datos, y sobre ese tema da para otro artículo igual de largo.
      2 K 24
      1. anacard anacard
        @DZPM @gallir En realidad lo que proponía era también en el sentido de mitigar daños cuando la BBDD se ha filtrado. El segundo salt podría estar incrustado directamente en el código fuente (mala práctica) o tomarse a partir de archivos de configuración. Seguramente en rendimiento no merece la pena, pero quería plantear el escenario de que el atacante sólo tuviera acceso a una parte del salt.
        1 K 18
        1. gallir gallir
          A los viejos usuarios, os recomiendo -> @gallir

          Por otro lado, me esperaba una minidebacle hoy con fallos de autentificación por algún bug. Ninguna queja o problema hasta ahora. Creo que es la primera vez que ocurre con un cambio tan importante 8-D
          19 K 206
          1. angelitoMagno angelitoMagno
            @gallir Nadie se ha quejado porque has cambiado un aspecto crítico del sistema de usuarios. Pero eso nadie lo ve.
            Llegas a cambiar el icono de "editar comentario" y se monta la de San Quintín.

            La dura realidad de la programación :-(
            29 K 325
          2. tnt80 tnt80
            @angelitoMagno Yo le propondría a @gallir una cosa, que cambiase toda la interfaz de Menéame, de arriba abajo, cuando la gente se dejase de quejar del cambio, la cambiase de nuevo entera otra vez, y así sucesivamente, hasta que aprendan que las cosas cambian.
            1 K 11
        2. DZPM DZPM
          @anacard @gallir
          > El segundo salt podría estar incrustado directamente en el código fuente (mala práctica) o tomarse a partir de archivos de configuración

          - el salt tiene que ser distinto para cada usuario, o no funciona. Si usas el mismo salt, es contraproducente.
          - si tienen acceso a tu db de usuarios puedes asumir que también tienen acceso a la app. El código fuente, o la config, estarán en memoria.

          > Seguramente en rendimiento no merece la pena, pero quería plantear el escenario de que el atacante sólo tuviera acceso a una parte del salt.

          El salt es algo público, casi por definición. La idea es que el hash y el salt son públicos y conocidos, mientras que el password es secreto y es (casi)imposible de deducir a partir del hash y el salt.
          1 K 9
          1. dphi0pn dphi0pn
            @DZPM @anacard @gallir Lo que se dice hardcodeado. Siempre mala praxis
            0 K 0

            menéame