¿Esto cuenta como salazón único en comparación con las tablas del arco iris?

0

** Debido a las limitaciones de mi situación, el exe (es decir, la fuente), hash, sal, todo se almacena localmente como una aplicación local.

¿Esta idea vencería a las tablas de arco iris?

Password = Input (always 8 in length, 0-9 accepted) (unique to person)
Check = Input2 (always 2 in length, 0-9 accepted) (unique to person)

HashedPassworwd = Hash(Password, SHA_512)

Salt = Starting at string position Check, take 32 chars onwards

HashedSalt = Hash(Salt, SHA_512)

FinalHash = Hash(HashedPassworwd+HashedSalt, SHA_512)

¿Se trataría de batir las tablas del arco iris y solo funcionaría contra la fuerza bruta?

    
pregunta ian smith 12.09.2016 - 22:52
fuente

2 respuestas

1

Su idea no está claramente especificada, por lo que, planteada, esta es una pregunta casi imposible de responder. Pero sin embargo veo toneladas de problemas claros:

  1. Longitud de contraseña corta y fija de 8 caracteres. Debe aceptar contraseñas muy largas si los usuarios desean proporcionarlas.
  2. El problema de la longitud de la contraseña se complica particularmente por el hecho de que solo acepta dígitos del 0-9.
  3. Si los usuarios eligen sus propias contraseñas, no puede asumir que serán únicas. En la vida real, muchas personas usan las mismas contraseñas, como "12345678", que es una de las contraseñas más comunes en la práctica .
  4. Si la variable Check tiene 2 dígitos, no puede ser "única para cada persona" a menos que no haya más de 100 personas.
  5. Como sus sales se derivan de una variable Check que solo tiene 100 combinaciones distintas, solo hay 100 sales distintas. Esto hace que la longitud de 32 caracteres no tenga sentido. (Supongo que la "cadena" de la que tomas los 32 caracteres siempre es la misma. No nos has dicho nada sobre esta cadena).
  6. SHA-512 no tiene ningún tipo de factor de trabajo ajustable para ralentizar a un atacante. Si tiene acceso a SHA-512, tiene acceso a PBKDF2-HMAC-SHA512, por lo que debe usar al menos eso. (¡No es que te vaya a hacer mucho bien, dado el número de problemas que tienes!)
  7. No entiendo de qué tipo de limitaciones está hablando en su primera oración, pero si el atacante tiene acceso al código objeto del programa, puede modificarlo para evitar todo esto.
  8. Parece que estás obsesionado con las tablas del arco iris, ya que probablemente son el menor de tus problemas.
respondido por el Luis Casillas 13.09.2016 - 00:27
fuente
1

Probablemente sea mejor aumentar la longitud y la fuerza de la contraseña en lugar de hacer algo con check y salt. Salt está destinado a ser almacenado con la contraseña de hash como un principio general.

Lo que realmente has hecho con la verificación es aumentar la entropía de la contraseña en 2 dígitos y hacer que te resulte más difícil usar bibliotecas estándar. Si solo está utilizando 0-9, eso es solo 10 ^ 10, incluso con sal, incluso con SHA512, lo puede romper alguien que realmente quiere hacerlo, especialmente si sus usuarios usan patrones predecibles, lo que probablemente harán.

¿Por qué limitar la longitud de la contraseña y los caracteres válidos? De todos modos, se eliminará el hash, no se le quitará la piel de la nariz desde una perspectiva de almacenamiento. Con un mejor conjunto de caracteres, puedes usar simplemente sal y hash sha512 y estar seguro.

    
respondido por el crovers 12.09.2016 - 23:00
fuente

Lea otras preguntas en las etiquetas