Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>1. Random bytes size</strong>: </p> <p>Salts should be at least the same size as your hash function, so for <code>sha256</code> you should use at least 32 bytes. Node.js Crypto's <code>pbkdf2</code> uses <code>SHA1</code>, so 20 bytes should be the minimum. However, the least you should use is <strong>64 bits (8 bytes)</strong>, as explained in #3. (Source: <a href="https://crackstation.net/hashing-security.htm" rel="nofollow noreferrer">https://crackstation.net/hashing-security.htm</a>).</p> <p><strong>2. PBKDF2 number of iterations</strong>: </p> <p>See <a href="https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256">this question</a> for a great discussion. I took from it that <strong>10.000 range</strong> is sufficient without impact performance, but this is hardware/performance dependant.</p> <p><strong>3. PBKDF2 length</strong>:</p> <p>See <a href="https://security.stackexchange.com/questions/31564/key-length-and-hash-function-in-pbkdf2">this other discussion</a> about key lengths. The parameter is again the hashing function used, in your case SHA-1, so 20 bytes is the correct value. Since <a href="http://en.wikipedia.org/wiki/PBKDF2" rel="nofollow noreferrer">PBKDF2's Standard</a> recommends salts of at least <strong>64 bits</strong>, it's a waste to generate keys smaller than your input, so use at least <strong>8 bytes</strong>. Do not use output length of greater than 20, as it provides no additional security, but doubles computation time for each multiple of 20.</p> <p><strong>4. How to store variables</strong>:</p> <p>Discussed in all the links above (especially <a href="https://crackstation.net/hashing-security.htm" rel="nofollow noreferrer">the first</a>), salts should be saved along passwords (but never reused elsewhere), usually by appending it first in the resulting string (salt:hash), or in another database column. </p> <p>As far as other variables, their knowledge is not critical for breaching security (as stated in <a href="https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle" rel="nofollow noreferrer">Kerckhoffs's Principle</a>, so you could parametrize it safely anywhere. Your way of doing it by separating them with "::" is fine, <em>but you are saving extra information</em>. <a href="https://crackstation.net/hashing-security.htm" rel="nofollow noreferrer">Crackstation's codes</a> only save <code>"algorithm:iterations:salt:hash"</code>, so in your case, <strong><code>"salt::derivedKey::iterations"</code></strong> is all you need.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload