title: What is the optimum way to store passwords in 2021?
body: <p>I store passwords, if you are a developer then it's easy to store passwords in which ever way is actually best. So I want to know, in 2021 which is the best? It's easy for me to tweak my code to become the best.</p>
  <p><strong>AND YES</strong> - I've researched and read many articles on Stack Overflow and other sites all offering the very best advice and I've followed it so this question <strong>is not a repeat</strong> of other threads.</p>
  <hr />
  <p>A high level overview of what I currently do:</p>
  <ul>
  <li>Use SSL</li>
  <li>Use a bcrypt library</li>
  <li>Use a password strength library</li>
  <li>Generate / store a random unique salt every time</li>
  <li>Store as a SHA3_512</li>
  </ul>
  <p>Which is the &quot;learnt&quot; wisdom from all of the articles and threads I've read.</p>
  <p><strong>BUT</strong>, just recently, <em>someone</em> told me that actually the above should now be considered insecure in 2021. Although this <em>someone</em> has good qualifications, I am nevertheless wary of making any security changes on a conversation and <em>I am not a security expert</em> so I thought before I make the changes then I must test it.</p>
  <p><strong>AND</strong>, I can think of no better place than Stack Overflow where I know it will be immediately cut to shreds if it deserves to be! I am not a security expert but it sounds believable enough that I am asking the question.</p>
  <p>So I ask with some trepidation of looking like, and following some idiot that I believed, the following.... and yes I AM ASKING THIS not anyone else.  Please find the logic I was presented with and I present to you ... eek!:</p>
  <ul>
  <li>If the <code>Users</code> table of your database has been compromised then your stored SALT has also been compromised <em>(this is generally accepted from what I have read)</em></li>
  <li>Hacker / password cracking tools are sophisticated, mature and rapidly evolve/adapt.</li>
  <li>The standard &quot;hacker&quot; password database has over 700 million of cleartext already used farmed passwords and their software creates clever variations producing rapid access to billions of likely possibilities.</li>
  <li>Standard hacking software already takes a &quot;salt&quot; input for bcrypt and PBKDF derivatives from an existing field within an existing compromised database therefore meaning the SALT becomes irrelevant. Effectively it becomes a command-line option to an existing tool which simply describes the algorithm and which field is the &quot;salt&quot;.</li>
  <li>Further, these tools are now so sophisticated that they can quickly check the top x% of passwords with different &quot;cost&quot; values, different permutations of SHA digests to ascertain and analyze the actual combination used by the developer if they do not know it.</li>
  <li>So these &quot;latest tools&quot; are clever to the point of trying a whole number of commonly used techniques with the known salt against a selection of &quot;likely targets&quot; to actually determine if you used a SHA1/2/3 or what length and other stuff that I really just don't understand.  But they are no longer stupid, actually they are very very clever.</li>
  <li>And these &quot;tools&quot; already exist and they are relatively easy to use with a ton of command line options so they are very accessible which massively broadens the attack vector.</li>
  </ul>
  <p>So generating a random SALT using <em>bcrypt or similar</em> is longer secure as the tools have evolved past that. The salt doesn't actually make any difference anymore, as it is basically expected.</p>
  <p><strong>QUESTION 1:</strong>  IS THE ABOVE ACTUALLY TRUE?   <em>(I personally have no idea at all)</em></p>
  <p>And the recommended 2021 SOLUTION, apparently, is as follows:</p>
  <ol>
  <li>Do not rely on the inbuilt salt functionality of existing cryptography methods.</li>
  <li>Yes, utilize the existing salt functionality but this is no longer enough as a standard.</li>
  <li>You must create your own additional SALTS which thwart existing and mainstream tools.</li>
  <li>You must create 2 x additional and separate SALTS stored in 2 x separate places.</li>
  <li>SALT 1: Is a random and static secret stored locally in an environment variable or stored locally in a &quot;secret file&quot;.</li>
  <li>SALT 2: Is a dynamic and random &quot;user salt&quot; stored within the DB and is password specific.</li>
  <li>SALT 3: Is the current salt you are already generating and storing and passing to bcrypt or similar.</li>
  <li>You then create your own unique formulae to generate the final encrypted password token.</li>
  </ol>
  <p><strong>ANALYSIS</strong></p>
  <ul>
  <li>If your database has been compromised you are no longer subject to attack due to the local static secret.</li>
  <li>If your local scripts and database has been compromised then a copy of your scripts will not include ENV STATIC secrets which are needed to be attacked. You are no longer subject to attack.</li>
  <li>If you have been entirely compromised then the existing mainstream tools cannot be utilized for an attack as your customized system is still beyond the scope of current hack command line technology.</li>
  <li>If you have been entirely compromised then the bad actor would need to recode underlying hack tool source code to directly address your precise attack vector to utilize existing technology.</li>
  </ul>
  <p>Something like as a possible unique salt example:</p>
  <pre><code>encrypted_real_user_password = Bcrypt ( SHA3_512 ( 
  SHA1_256(static_password_stored_on_server) + 
  SHA2_512(plain_text_user_provided_password) + 
  CRC_32  ( (static_password_stored_on_server) + (plain_text_user_provided_password) ) +
  SHA3_256(dynamic_password_stored_in_DB) ))
  </code></pre>
  <p><strong>QUESTION 2:</strong>  AM I AN IDIOT?  <em>(and please tell me if I am... I know you will!)</em></p>
  <p><strong>IN CONCLUSION</strong></p>
  <p>I really don't know what the response will be, try to be nice (as possible) and I hope in the end that if any small changes come from this to make my storing of passwords more secure then it will be worth it.</p>
  <p><strong>FINALLY FINALLY</strong></p>
  <p>Programmatically storing the encrypted password or &quot;password token&quot; as per the above is simple. A single line of code can encrypt and decrypt the password as per above.</p>
  <p><strong>BUT IS IT MORE SECURE?</strong></p>