How We Protect Your Passwords

In the previous articles, we explored how HTTPS protects the route between your app and our server, and how SSH secures the server itself. Now it’s time to look inside the server — at how Splync keeps your password safe once it arrives there. If someone were to obtain your password, that person could log into your account and access sensitive information, including your expense records. That’s why Splync never stores passwords in plain text. Instead, each password is transformed into a hashed version before being saved in the database. What does that mean exactly? Hashing is a one-way conversion — once transformed, it can never be turned back into the original password. This method is standard across the internet, from banks to major cloud services, yet many people don’t know how it actually works. Let’s explore it through a simple everyday analogy.

To understand how password protection works, let’s start with a simple hashing method called SHA-256. Think of it as a blender that always mixes ingredients in exactly the same way. If you put the same password into the blender and press the button, you’ll always get the same unique smoothie — a scrambled mix of letters and numbers. The key idea is that the process can’t be reversed. Just as you can’t take a smoothie and separate it back into the original banana and milk, you can’t take the scrambled hash and recover the original password.

SHA-256 is one of the most common hashing algorithms. For example, it hashes the password "splync1234" into “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. In milliseconds, every time an existing user enters a login password, SHA-256 always produces the same hashed password. The app simply hashes the entered password again and checks whether it matches the stored hash. At no point does the system ever know the user’s original password. But what if an attacker pre-computes a list of common passwords and their hashes (known as a rainbow table attack) to quickly guess users’ passwords? That concern is very real. This is why modern systems, including Splync, do not rely on plain SHA-256.

Bcrypt uses a random per-user salt and encodes that salt (and the cost factor) directly in the stored hash string. Think of bcrypt as a blender with a secret spice (salt) and a slow motor (work factor) — it makes every mix unique and harder to copy. Because the salt is 128 bits (≈3×10³⁸ possibilities), the same password can map to an astronomically large number of different stored hashes. That makes precomputed rainbow tables useless at scale. During login, Splync reads the salt and cost from the saved bcrypt string, re-runs bcrypt on the entered password with those parameters, and compares the result to the stored hash. If they match, the password is correct — but because bcrypt is intentionally slow and salts are unique, brute-force attacks become far more costly for an attacker.

Let’s see how this looks in practice. If you hash the password "splync1234" with bcrypt (using cost 12), you might get a string like this: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. In this bcrypt string, `$2b` marks the algorithm version, `$12` shows the cost factor (how many times the password is processed), `gBeouKYdue9uvvuV0HtGgeV` is the unique random salt, and `PymnrojMqP/wcRw28HFlGEGIQbyw7O` is the final hashed password. Because the hash itself contains the salt and cost, Splync can reproduce the same hashing process for verification by extracting those values from the stored string and comparing the result. On the other hand, If an attacker does not know the salt and cost, they cannot build a single rainbow table that works for every user.

This approach has another important advantage. Because Splync never stores plain passwords, even if the database were leaked or stolen, users are not immediately at risk. Attackers cannot log in directly with the stolen data, because what they have are only scrambled strings. This design gives users an extra layer of protection, on top of the safeguards that already exist around the server itself. Password hashing is not unique to Splync; it is the standard across the technology industry, used by giants like Google, Apple, and Amazon. Splync has been built very safely, and it will only get safer as we keep improving security with features like email verification, brute-force protection, and ongoing monitoring.