A recent article from The Register reported that Kaspersky researchers found 60% of MD5 password hashes could be cracked in under an hour using a single high-end GPU.

That should make people uncomfortable.

Not because MD5 is new. It is not.

Not because weak passwords are new. They are not.

The uncomfortable part is that a lot of organizations still have old cryptography, old VPN settings, old password storage methods, and old assumptions quietly sitting in production.

And in many cases, nobody has checked them in years.

Encryption Does Not Age Gracefully

Encryption and hashing choices are not “set it and forget it” decisions.

Something that was acceptable years ago may be completely inappropriate today. Hardware gets faster. Cloud compute gets cheaper. Attack tools get better. Leaked password datasets get larger. What used to require time, money, and specialized equipment may now be practical for a motivated attacker with rented GPU time.

That is why weak encryption is often less about one bad technical decision and more about process failure.

Someone built an application.

Someone configured a VPN.

Someone set up a database.

Someone picked a hashing method.

Then the business moved on.

Years later, the company may still be relying on that original decision without realizing the risk has changed.

SHA-256 Is Not the Whole Answer

One common question is whether applications are using newer hashing algorithms like SHA-256 instead of MD5 or SHA-1.

That is a good question, but it needs a little nuance.

SHA-256 is a modern cryptographic hash function, but by itself, it is not the right answer for password storage.

Passwords should not be stored using fast general-purpose hashes like:

  • MD5
  • SHA-1
  • Plain SHA-256
  • Plain SHA-512

Those algorithms are fast by design. Fast is good for file integrity and digital signatures. Fast is bad for password storage because attackers can test guesses extremely quickly.

For passwords, applications should use password hashing or key derivation functions designed to be slow and resistant to brute force attacks, such as:

  • Argon2id
  • bcrypt
  • scrypt
  • PBKDF2 with appropriate parameters

The important part is not just the algorithm name. It is also how it is configured.

A good password storage review should ask:

  • What algorithm is being used?
  • Is each password uniquely salted?
  • Is there an appropriate work factor, cost, iteration count, or memory setting?
  • Can the parameters be increased over time?
  • Are old hashes upgraded after successful login?
  • Are passwords ever encrypted reversibly instead of hashed?
  • Are service accounts, API keys, and shared secrets handled differently than user passwords?

If your application team cannot answer those questions, that does not automatically mean something is wrong. It does mean someone should take a closer look.

Key Management Is Usually Where Things Fall Apart

Encryption is only as strong as the way keys are managed.

A strong algorithm with poor key management is still a weak system.

Common problems include:

  • Encryption keys stored in source code
  • Secrets committed to GitHub
  • Keys reused across environments
  • Production and development sharing the same secrets
  • No documented key rotation process
  • No clear owner for encryption keys
  • Old API keys that never expire
  • Shared administrator credentials
  • Backup encryption keys stored next to the backups
  • No inventory of certificates, keys, tokens, and secrets

A key management review does not have to be overly complicated. Start with a simple inventory.

For each important system, identify:

  • What data is encrypted
  • Where the keys live
  • Who can access the keys
  • How keys are rotated
  • What happens if a key is exposed
  • Whether keys are backed up securely
  • Whether old keys still work
  • Whether access to keys is logged and reviewed

If nobody owns this process, the business is probably relying on luck.

VPNs Deserve a Fresh Look

VPNs are another area where old configurations tend to linger.

Over the last several years, SSL VPN products and edge appliances have had a steady stream of serious security issues. These systems are attractive targets because they are exposed to the internet and often provide direct access into the internal network.

That does not mean every VPN is bad.

It does mean VPNs need to be reviewed like high-risk internet-facing infrastructure.

If your company still has an SSL VPN exposed to the internet, ask:

  • Do we still need this?
  • Is it fully patched?
  • Is it monitored?
  • Is MFA required for every user?
  • Are inactive users removed?
  • Are vendors and contractors reviewed?
  • Are logs being sent somewhere useful?
  • Has the appliance been checked for indicators of compromise?
  • Is there a safer access model available?

Many organizations deployed SSL VPNs because they were convenient. Convenience is not a security strategy.

IPsec VPNs Need Review Too

IPsec VPNs are common for site-to-site connections, vendor tunnels, cloud connectivity, and branch offices.

They can be very secure when configured well. They can also be weak if they are running old settings nobody has touched in years.

A practical IPsec VPN review should check for:

  • IKEv2 instead of IKEv1 where possible
  • AES-256 or another approved strong encryption option
  • SHA-2 instead of SHA-1 or MD5
  • Strong Diffie-Hellman groups
  • No aggressive mode
  • No weak pre-shared keys
  • No shared keys reused across multiple tunnels
  • No obsolete encryption like DES or 3DES
  • Documented tunnel ownership
  • Documented business purpose
  • Regular review of whether the tunnel is still needed

Aggressive mode is especially worth checking. It has historically made certain VPN configurations easier to attack, especially when combined with weak pre-shared keys. If it is enabled, there should be a very good reason.

Most of the time, there is not.

MFA Should Be Non-Negotiable

Anything exposed to the internet should have MFA enabled.

That includes:

  • VPNs
  • Email
  • Remote access tools
  • Cloud consoles
  • Admin portals
  • Firewalls
  • SaaS applications
  • Identity providers
  • Code repositories
  • Backup platforms
  • Financial systems

MFA is not perfect, but lack of MFA is still one of the easiest ways to turn a stolen password into a real incident.

For higher-risk systems, organizations should also look at stronger MFA options, conditional access, device posture, phishing-resistant authentication, and admin separation.

But the first question is simple:

Is MFA enabled everywhere it should be?

If the answer is “mostly,” the next question is “where is it not enabled?”

That list matters.

The Real Problem Is Drift

Most weak encryption problems do not start as negligence.

They start as drift.

A setting was acceptable when it was deployed.

A vendor recommended something years ago.

An application was inherited from another team.

A VPN tunnel was created during an emergency.

A developer used a default library example.

A certificate was renewed manually.

A key was copied somewhere for troubleshooting.

Then time passed.

The business changed. The threat landscape changed. The technology changed. But the configuration stayed the same.

That is how organizations end up with weak hashing, exposed VPNs, old ciphers, forgotten tunnels, and unmanaged keys.

What Businesses Should Do Next

This does not need to become a massive project right away. Start with a focused review.

1. Review password storage

Identify applications that store user passwords and confirm how those passwords are protected. Pay close attention to custom applications, older portals, customer-facing systems, and internally developed tools.

2. Inventory encryption keys and secrets

Find out where important keys, tokens, certificates, and secrets live. Determine who owns them and how they are rotated.

3. Review internet-facing remote access

Look closely at VPNs, remote access portals, firewalls, and administrative interfaces. Confirm they are patched, monitored, and protected with MFA.

4. Validate IPsec VPN settings

Check tunnel configurations for weak encryption, old IKE versions, aggressive mode, weak pre-shared keys, and outdated business purpose.

5. Remove what you no longer need

The best VPN tunnel, admin portal, or exposed service is the one you no longer have to expose at all.

6. Make this a recurring review

Encryption and remote access settings should be reviewed on a schedule. Not once. Not only after an incident. Not only when a vendor asks.

Final Thought

Weak encryption is not always dramatic. It is not always visible. It does not always show up as a flashing red alert.

Sometimes it is just an old setting that nobody has looked at in five years.

That is the risk.

Modern security is not just about buying better tools. It is about making sure the tools, applications, VPNs, keys, and authentication systems you already have are still configured for the world we live in now.

Because attackers are not testing your environment against what was reasonable ten years ago.

They are testing it against what works today.

References