Rfc2898DeriveBytes implementos El algoritmo estándar conocido como PBKDF2 y se define en RFC 2898 (de ahí el nombre). Ese algoritmo utiliza una función pseudoaleatoria subyacente configurable, que suele ser HMAC , y HMAC se basa en una función hash subyacente configurable. , generalmente SHA-1. Si bien todo esto es configurable, una implementación dada puede no ser tan flexible y, de hecho, Rfc2898DeriveBytes siempre usa HMAC y siempre usa SHA-1 como función subyacente para SHA-1.
Hoy en día, las personas conocidas colectivamente como "auditores" tienden a lamentarse, aullar, gritar, burlarse y correr en círculos cuando ven algo que involucra a SHA-1 . Esto es científicamente injustificado. En este momento , entre toda la Ciencia publicada, no hay la menor indicación de que SHA-1 cuando se usa en HMAC sea débil. Las debilidades conocidas en SHA-1 se refieren a colisiones que no afectan el HMAC (y de todas formas son todavía teóricas). Si un tipo con un CISSP insiste en que SHA-1 en realidad hace que el PBKDF2 sea más vulnerable a la fuerza bruta, ese tipo debería ir a aprender sus lecciones.
Sin embargo, cambiar el SHA-256 no es una mala idea, por lo que si rechazar SHA-1 es lo que se necesita para deshacerse de los auditores, que así sea.
Sin embargo, aún se debe decir lo siguiente:
-
Desmontar y luego modificar es un método bastante burdo y tiende a conducir a un código que no se puede mantener. Simplemente puede comenzar desde el código fuente real (por ejemplo, desde aquí ), o incluso más simple (y con un estado legal más limpio), vuelva a implementarlo desde cero. .NET proporciona una implementación de HMAC / SHA-256 ; usarlo para hacer un código PBKDF2 no es difícil.
-
Como alternativa, puede intentar reutilizar otra implementación existente, como esta .
-
Usted usa PBKDF2 cuando quiere "marcar una contraseña", y no todas las funciones son iguales a ese respecto. Una función de hashing es útil solo en la medida en que sea costoso para los atacantes calcularla. En ese sentido, PBKDF2 con SHA-1 o SHA-256 no es la mejor opción; Podría decirse que PBKDF2 con SHA-512 es mejor (porque la GPU existente tiene más dificultades para optimizar SHA-512 que SHA-256), pero pueden ser preferibles otras soluciones, en particular bcrypt . Para obtener más información sobre este tema, lea esto , y más generalmente esto .
Esto significa que, si bien las "debilidades" de SHA-1 no debilitan a PBKDF2, aún es una función que puede optimizarse muy bien en GPU, que es, en ese caso, un problema, pero eso es lo importante. Punto aquí, las tarifas SHA-256 no son mejores.
-
En cualquier caso, al usar una implementación de C # puro, acepta que este uso intensivo de la CPU se ejecutará con la desaceleración inherente de esa tecnología, que se puede estimar en un factor de 2 a 3 en comparación con la optimización Código C (o ensamblaje). En otras palabras, le das una ventaja de 2x o 3x a los atacantes. Por lo tanto, es posible que desee utilizar algún código nativo aquí, no C # puro.