Valoarea pentru iterații: randomNumber
nu trebuie să fie un număr aleatoriu. Este un număr de iterații care controlează costul PBKDF2. Ar trebui să fie setat cât mai sus este tolerabil în aplicație, iar protecția oferită de PBKDF2 împotriva căutării prin parole crește aproximativ liniar cu acel parametru. În cele ce urmează îmi asum un mare iterații
(să zicem o linie de bază de o sută de mii) și asta sare
se depozitează cumva. Presupun, de asemenea, că este folosit HMAC-SHA-1 (prestabilit) sau HMAC-SHA-256 (de asemenea comun).
Din câte știm, principala slăbiciune în ceea ce este descris este că este posibil să se testeze o frază de acces, rulând generateKey și apoi testând cheia corespunzătoare folosind o criptogramă AES cunoscută. Este asta „fără să-i pese de expresia de acces”? Asta nu-mi este clar.
Problema este că PBKDF2 poate fi rulat la viteză foarte mare de către atacatori care folosesc GPU-uri, FPGA-uri sau ASIC-uri. Când iterații
este mare (cum ar trebui), PBKDF2 este blocajul generateKey
și căutare prin parolă. Deci, adversarii pot căuta parole mai repede decât utilizatorii obișnuiți folosind CryptoJS. Din punctul de vedere al îngreunării căutării prin parole, care este scopul principal al întrebării, PBKDF2 este, prin urmare, printre cele mai proaste utilizări posibile a puterii CPU de rezervă pentru întinderea cheii când vine vorba de adversari puternici. Opțiuni mult mai bune ar Argon2, scrypt sau chiar bcrypt.
Tu decizi dacă este o coincidență că NIST recomandat anterior PBKDF2, și încă nu impune folosirea a ceva mai bun; cum a fost împins înainte Dual_EC_DRBG, cu intenția evidentă de a permite informațiilor americane să spargă această cripto. S-ar putea să se aplice aparatul de ras al lui Hanlon, dar îi țin pe oamenii de știință de la NIST la o mare stima.