Hola Salva!

Como he comentado en el post en inglés, en un entorno productivo esto no nos sirve ya que inmediatamente después ya tenemos queries cacheadas.

El tema es que hasta ahora después de este comando teníamos un If ($ZERROR '= "") y en realidad no se si esto llegaba a hacer algo, sería interesante que alguien nos confirmase si dentro del código de PurgeForTable^%apiSQL se setea $ZERROR, %objlasterror, o alguna otra cosa.

Traduzco la respuesta de Jon Willeke  en la community en ingles:

FIPS 180-4 describe SHA-512 y otros, FIPS 198-1 describe HMAC, y PKCS #5 describe PBKDF2, el cual depende de HMAC-SHA. Sobre NIST, la publicacion especial 800-132 (hace ya 10 años) dice literalmente: "This Recommendation approves PBKDF2 as the PBKDF using HMAC with any approved hash function as the PRF." For more recent guidance, consider special publication 800-63B Lo cual podríamos traducir como "Esta recomendación aprueba PBKDF2 como PBKDF usando HMAC con cualquiér función de hashing aprobada por el PRF, para información más reciente considerar la publivación 800-63B.

Por lo que entiendo, ninguna de las vulnerabilidades de SHA afectan a HMAC o PBKDF2. Sin embargo, si SHA-1 ya no esta aprobada por FIPS, la guía de NIST indicaría que se ha de reemplazar con SHA-2 o 3...

En terminos de fuerza, PBKDF2 tiene esencialmente dos parámetros, la función de hashing y el número de iteraciones. Para la función de hashing, mas largo suele querer decir mas lento, por lo que mas seguro. Para el número de iteraciones, PKCS #5 y NIST 800-132 sugieren ambos un mínimo de 1000. NIST 800-63B dice literalmente "el número de iteraciones DEBERÍA ser lo más grande que el rendimiento del servidor de verificación permita, normalmente al menos 10000 iteraciones.