Olen utelias, onko jollakin neuvoja tai viitekohtia määritettäessä kuinka monta iteraatiota on "tarpeeksi hyvä" käytettäessä PBKDF2: ta (erityisesti SHA-256: n kanssa). Varmasti, "tarpeeksi hyvä" on subjektiivinen ja vaikea määritellä, vaihtelee sovelluksen &-riskiprofiilin mukaan, ja mikä tänään on "tarpeeksi hyvä", ei todennäköisesti ole huomenna "tarpeeksi hyvä" ...
Mutta kysymys on edelleen mikä teollisuuden mielestä on tällä hetkellä "tarpeeksi hyvä"? Mitä vertailupisteitä on saatavilla vertailua varten?
Joitakin löytämiäni viitteitä:
- syyskuu 2000 - suositellaan yli 1000 kierrosta (lähde: RFC 2898)
- helmikuu 2005 - AES Kerberos 5: ssä "oletusarvo" 4096 SHA-1-kierrokselle. (lähde: RFC 3962)
- syyskuu 2010 - ElcomSoft väittää, että iOS 3.x käyttää 2000 iteraatiota, iOS 4.x käyttää 10000 iteraatiota, osoittaa, että BlackBerry käyttää 1: tä (tarkkaa hash-algoritmia ei ilmoiteta) (lähde: ElcomSoft)
- Toukokuu 2011 - LastPass käyttää 100000 SHA-256-toistoa (lähde: LastPass)
- kesäkuu 2015 - StableBit käyttää 200 000 SHA-512-toistoa (lähde: StableBit CloudDrive Nuts & Bolts)
- elokuu 2015 - CloudBerry käyttää 1000 SHA-1-iteraatiota (lähde: CloudBerry Lab Security näkökohdat (pdf))
Arvostan muita viitteitä tai palautetta siitä, kuinka määritit, kuinka monta iteraatiota oli tarpeeksi hyvä sovelluksellesi.
Lisätaustana harkitsen PBKDF2-SHA256: ta menetelmänä, jolla hajautetaan käyttäjän salasanoja tietoturvatietoiselle verkkosivustolle. Suunniteltu PBKDF2-suola on: käyttäjäkohtainen satunnaissoola (joka on tallennettu tyhjään tilaan jokaisen käyttäjätietueen kanssa), XOR'tettu globaalilla suolalla. Tavoitteena on nostaa salasanojen pakottamisen kustannuksia ja välttää paljastamasta käyttäjiä, joilla on sama salasana.
Viitteet:
- RFC 2898: PKCS # 5: Salasana- Perustuva salausmääritys v2.0
- RFC 3962: Advanced Encryption Standard (AES) -salaus Kerberos 5: lle
- PBKDF2: Salasanapohjainen avaimen johtamistoiminto v2