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 11 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.