How We Transfer And Store Passwords

Our new security mechanism is designed to ensure that end-users' passwords are properly hashed and stored on our server in a secure manner, significantly reducing the risk of password theft and security breaches. Our multi-level approach includes a unique client salt, unique server salt, PBDKF2-HMAC-SHA512 hash function, and 130,000 rounds of iterations applied twice. The Argon2id is to be implemented in Q3-Q4 2023 as an optional KDF function.

The end-user's browser accepts the client salt, which is sent by our server, and hashes the end-user's password with the client salt using the PBDKF2-HMAC- SHA512 hash function with 130,000 rounds of iterations. The browser then sends the hash to the DeskAlerts server using secure TLS 1.3 or TLS 1.2 connection, which takes the end-user's already salted password hash, adds the server's salt, and hashes the salted password hash once again using the PBDKF2-HMAC- SHA512 hash function with 130,000 rounds of iterations before storing the final hash in the database. The output hash length is 64 bytes. For a better understanding, please analyze the scheme of a login process attached to this post.

With this multi-level approach, we have ensured that the final hash is hashed twice using two different salts, and the PBDKF2-HMAC-SHA512 hash function's rounds of iterations reach 260,000, which is even better than OWASP recommends. This ensures that the end-users' passwords are adequately protected from theft and unauthorized access.