CubeCart 6.6.3 upgraded password hashing to Argon2id, with transparent migration on login. It is a change you will never see happen, and it materially improves what a stolen database is worth to whoever stole it.

What password hashing is actually for

Your store does not store passwords. It stores a hash: a one-way transformation that lets you check whether a submitted password is correct without ever holding the password itself.

The value of that shows up in one specific scenario. If your database is ever exposed, through a SQL injection, a compromised backup, a misconfigured server, the attacker gets the hashes. What happens next depends entirely on which algorithm produced them.

With a fast general purpose hash, an attacker with a consumer graphics card can test billions of candidate passwords per second offline. Every weak or reused password in your customer base falls quickly. And because people reuse passwords, the damage does not stop at your store: those credentials get tried against email accounts and banks.

With a purpose-built password hash, the same attacker gets a rate low enough that only genuinely weak passwords fall, and it takes a long time. That gap is the entire point.

Why Argon2id specifically

Argon2 won the Password Hashing Competition in 2015, and Argon2id, the hybrid variant, is what OWASP currently recommends for new applications.

The property that matters is that it is memory hard. Older schemes made hashing slow by requiring many iterations, and iterations are exactly what specialised hardware is good at parallelising. Argon2id also requires a substantial amount of memory per hash computation, and memory is expensive to replicate thousands of times over on a GPU or a custom chip. That shifts the economics against bulk cracking in a way that iteration count alone does not.

The “id” variant blends two modes: resistance to side-channel attacks from one, and resistance to time-memory trade-off attacks from the other. It is the sensible default and the one to use unless you have a specific reason not to.

How the migration works

This is the part worth understanding, because it explains the timeline.

Existing password hashes cannot be converted. A hash is one way, so CubeCart cannot take an old hash and produce an Argon2id hash from it without the original password.

What it does instead is upgrade on login. When someone signs in successfully, CubeCart has the plaintext password for a moment, legitimately, in order to verify it. At that instant it re-hashes with Argon2id and replaces the stored value. Nobody is forced to reset anything, there is no bulk migration job, and nothing is visible to the user.

The consequence is that migration is gradual, and accounts that never log in again keep their old hashes indefinitely. That is the correct trade off. The alternative, forcing a password reset across your entire customer base, would cost you far more in lost accounts and support tickets than the residual risk justifies.

Practically: your administrator accounts migrate the first week. Your active customers migrate over the following months. A dormant account from 2019 stays as it was. If you are ever in a position where that matters, the right response is a targeted reset, not a blanket one.

The hosting requirement

Argon2id is available through PHP’s password_hash() from PHP 7.3 onwards, as PASSWORD_ARGON2ID, provided your PHP build includes libargon2 support. Not every build does.

If your host built PHP without it, CubeCart falls back rather than failing, so your store keeps working and you get no benefit and no warning. That is the sensible behaviour for CubeCart but it does mean you cannot assume you have this just because you upgraded.

Worth confirming with your host. If you host with us, ask and we will check it for you.

What this does not do

Strong hashing limits the damage of a breach. It does not prevent one. It also does nothing about:

  • Weak passwords. Argon2id makes cracking expensive per guess. If the password is “password123” it is one guess.
  • Reused passwords. If a customer used the same password on a site that was breached with worse hashing, their credentials are already out there and yours were never the weak link.
  • Phishing. No hashing algorithm helps when the user types their password into a convincing fake.
  • Your admin accounts. Which is why two factor authentication, added in 6.6.0, matters more for the back office than hashing does.

The takeaway

This is a change you benefit from by upgrading and then doing nothing. The two things worth actually acting on: confirm your PHP build supports Argon2id so you are getting it at all, and enable two factor authentication on your administrator accounts, because that is the control protecting the accounts that matter most.

If you host your CubeCart store with us and want us to confirm your PHP build supports Argon2id, just ask.

Copyright Havenswift Hosting 2007-2026. All rights reserved.