11 Best Practices for User Account Authorization and Password Management in 2026

As the Founder and CEO at Acquaint Softtech, I have reviewed a lot of authentication code, and the pattern is remarkably consistent. The login screen is almost always fine. Passwords are hashed, sessions expire, somebody has thought about it. Then you open the password reset flow and find a token that never expires, or one that is guessable, or an endpoint with no rate limit that will happily accept 10,000 attempts per minute. The front door has three locks and the back door is propped open with a brick. That asymmetry is the single most common finding in the software product development audits we run on existing applications.

It happens because attention follows visibility. Sign-in is the screen everyone sees, discusses, and tests. Recovery is the screen nobody looks at until it fails. 

So this rewrite keeps all eleven original practices, corrects the ones that guidance has moved past, repairs one that was published broken, and adds the sections that decide whether the rest of it holds: recovery, rate limiting, and what to do when credentials from somebody else's breach arrive at your door.

---

A note on what has been removed. The 2018 version opened by framing all of this as something Google Cloud Platform solves for you. None of the eleven practices are specific to any cloud provider, and the framing narrowed a genuinely useful article for no reason, so it is gone. A promotional paragraph about a password manager, placed within the hashing section, has gone too, because product recommendations do not belong in the middle of a security instruction.

And practice eleven, which promised advice on case sensitivity, contained a duplicate of practice ten's text. It has been given the answer it should have had all along, further down.

Find Your Weakest Link First

Authentication fails at whichever point received the least attention, and it is rarely the login form. Find the row that describes your system and start there.

What is true of your system	What an attacker does with it
Reset tokens do not expire	Reuses an old email link
No rate limit on login	Tries breached passwords in bulk
Passwords hashed with SHA or MD5	Cracks the whole table offline
Composition rules but no breach check	Guesses Summer2026! first
SMS is the only second factor	Ports the phone number
Email address is the primary key	Blocks the user from changing it
Sessions never expire	Keeps a stolen token indefinitely
No deletion route	Accrues a legal problem instead

If more than three rows apply, treat it as an architecture problem rather than a list of fixes, and consider whether a managed identity provider is the better answer. That comparison appears in the cost section, and it is a decision worth making deliberately rather than by accumulation.

Hash Passwords With Argon2id

Argon2id is the current first choice for password hashing, and the 2018 advice listed it as one option among four equals. It is no longer an even field.

The OWASP password storage guidance sets out the order plainly: Argon2id where available, bcrypt where it is not, and PBKDF2 chiefly where a compliance regime such as FIPS requires it. All three are acceptable; only one is the default. MD5 and SHA-1 were already unacceptable in 2018 and remain so, and the original was right to say so.

Three details that matter more than the algorithm

Salting is handled for you by every modern implementation, so the original's advice to salt manually is now a warning sign rather than a task. Use your language's built-in functions rather than assembling anything yourself. And tune the cost parameters to your hardware, targeting a few hundred milliseconds per hash, because a correctly chosen algorithm with default parameters left untouched is doing a fraction of the work it should.

Plan for rehashing. When a user signs in successfully, check whether their stored hash uses your current algorithm and parameters, and if not, rehash it with the password you already have in memory. This migrates a table quietly over months without ever asking anyone to reset anything, and it is the mechanism that lets you improve hashing without a disruptive announcement.

Offer Passkeys, and Understand the Catch

Passkeys are the most significant change in authentication since this article was written, and they resist phishing in a way no code-based factor does. They replace the password with a key pair held by the device, so there is no secret to steal, reuse, or type into a fake site.

Support is now broad across major platforms and browsers, and the FIDO Alliance maintains the specification and the implementation guidance behind it. For a consumer product, offering passkeys is no longer an experiment; it is a reasonable default to present alongside your existing options.

The catch worth planning for

You cannot switch passwords off. Some users will be on unsupported devices, some will lose access to a device, and some will simply decline. That means you keep a fallback, and the fallback becomes the weakest path into the account, which returns you to recovery being the thing that actually needs the work.

On SMS, more precisely than before

The original said SMS two-factor authentication has been deprecated by NIST. That overstates it. SMS is restricted and discouraged relative to stronger factors because of number-porting and interception risks, not banned. The practical position is unchanged: offer the strongest factor your users will accept, prefer authenticator applications or hardware keys, and treat SMS as far better than nothing rather than as a failure.

Use Third-Party Identity Providers Deliberately

Letting Google or Apple verify identity removes a large amount of risk from your system, and it introduces a dependency you should choose knowingly. The 2018 list of providers needs updating: Sign in with Apple is now expected on consumer products, and the Twitter option effectively no longer exists.

The benefits are real. You never store a password, you inherit the provider's fraud detection and second factor, and sign-up completion usually improves. The costs are equally real. You depend on a company that can change terms or retire a service; some users will not have or want an account with any provider you offer, and business customers frequently require their own single sign-on instead.

The sensible arrangement for most products is two or three social providers, an email option, and enterprise single sign-on if you sell to organisations. As authentication requirements grow across teams, devices, and cloud services, many enterprises also evaluate identity and access management solutions to centralise authentication, enforce access policies, and simplify user provisioning across their application ecosystem. Wiring several providers into one coherent account model is where this gets fiddly, and it is a common reason teams hire API developers rather than absorbing it into feature work.

Separate Identity From Account

This was the strongest idea in the original article, and it remains better than most current writing on the subject. A user is not an email address, a phone number, or an OAuth subject identifier. Those are ways of proving who someone is; they are not the person.

Give every user an internal identifier that never changes and never leaves your system. Attach authentication identities to that identifier as separate records: a password credential, a Google identity, an Apple identity, an enterprise single sign-on identity. Everything else in your application references the internal identifier and nothing else.

Why it pays off later

Because every alternative creates work you cannot undo cheaply. When the email address is the primary key, changing it means rewriting foreign keys across the database. When the OAuth subject is the primary key, retiring that provider strands the account. Teams that skipped this step usually discover it two years in, when a customer asks to change their email, and the answer is that it would take a fortnight.

Let One Account Hold Many Identities

Duplicate accounts are the most common consequence of getting the previous practice wrong. Somebody signs up with a password in January, returns in June, clicks the Google button and lands in an empty account with none of their history.

The fix the original described still works. When a new identity arrives carrying an email address that already exists in your system, do not silently create a second account and do not silently merge them either. Ask the person to authenticate with the identity you already know, and only then link the new one. That single confirmation step is what stops an account takeover through an unverified email claim.

Verify the email address before treating it as a match. An identity provider asserting an address is not the same as that address having been proven, and merging on an unverified assertion is a genuine vulnerability rather than a theoretical one.

Accept Long Passwords and Drop Composition Rules

The original was ahead of its time here and slightly self-contradictory. It argued correctly for allowing long passwords and any characters, while also stating that requiring letters, symbols, and numbers is what sites now do, as though that were a good thing.

Current NIST digital identity guidance resolves the tension. Composition rules are discouraged because they produce predictable substitutions rather than genuine entropy, and forced periodic changes are discouraged for the same reason. What is recommended instead is a generous minimum length, acceptance of all printable characters including spaces and emoji, no truncation, and screening new passwords against lists of known-breached credentials.

The check that does the real work

Breach screening materially reduces risk because the passwords used against your users are already exposed elsewhere. Reject a password that appears in a known breach list at the moment it is chosen, and explain why in plain language. This single control outperforms every composition rule ever written, and it takes an afternoon to add.

Keep Username Rules Light

Restrictive username rules create support tickets and prevent very little. The original's guidance holds: enforce a sensible minimum length, strip leading and trailing whitespace, block invisible and control characters, and stop there.

Two additions worth making. Normalise Unicode on storage so that two visually identical names cannot be registered as different accounts, which is a genuine impersonation route. And if you generate usernames automatically, screen the output against a word list in the languages you serve, since randomly generated strings produce unfortunate results often enough to be worth preventing before a customer finds one.

Allow Username Changes Safely

People need to change usernames, and the risk sits in what happens to the old one. Release a former username back into the pool immediately, and somebody can claim it and inherit whatever reputation or trust attached to it.

Hold released usernames in quarantine for a period rather than freeing them at once, keep the internal identifier unchanged throughout so nothing else in the system moves, and log the change with the previous value. Notify the account by email when a username or email address changes, sent to the old address as well as the new one, because that message is often the only warning a person gets that their account has been taken over.

Handle Sessions Without Punishing People

Session policy is a trade between security and irritation, and most systems get the balance wrong in the same direction. The original made a good point that the article never developed: losing unsaved work to a session timeout is a design failure, not a security feature.

A workable arrangement

Use a rolling session that extends with activity rather than a fixed expiry that ignores it. Set an absolute maximum so a session cannot live forever regardless of use. Issue session cookies with the HttpOnly, Secure, and SameSite attributes, and regenerate the session identifier on login to close off fixation attacks. 

Give people a visible list of active sessions with the ability to revoke any of them, which is both a security control and the fastest way somebody recovers from a shared or stolen device.

Re-authenticate for consequences, not for time

Rather than expiring people aggressively, ask for the password again at the moments that matter: changing the email address, changing the password, adding a payment method, deleting the account. 

That gives you stronger protection exactly where it counts and lets everyone else stay logged in while they work. Preserve form state across any re-authentication prompt, because losing a half-written submission is the reason people start writing their passwords down.

Treat Deletion as a Legal Right

Account deletion was described in 2018 as a courtesy to offer users. It is now an obligation in most of the markets this article is read in. Data protection law in the UK and EU gives individuals a right to erasure, and comparable rights exist in Australia and across several United States state regimes.

What a compliant deletion actually involves

Deletion has to reach backups, analytics systems, support tickets, email platforms and anywhere else the data was copied, which is why it needs designing rather than adding. A soft delete followed by a scheduled purge is the usual pattern, since it gives an accidental request a window for reversal while still producing genuine erasure.

Two nuances people get wrong. You are usually permitted, and sometimes required, to retain specific records such as financial transactions for a statutory period, so complete erasure of everything is not always the correct outcome. 

And anonymisation is a legitimate alternative where the data genuinely cannot be reconnected to a person. Write down which category each data store falls into before you build the delete button, and keep that record, because the mapping is what an auditor will ask for.

Get Case Sensitivity Right

This is the practice the original promised and did not deliver, and the rules are short enough to state completely. Email addresses should be treated as case-insensitive, usernames should be stored normalised, and passwords must always remain case-sensitive.

Email addresses

The domain half is case-insensitive by specification, and the local half is technically case-sensitive, but effectively no mail provider treats it that way. Normalise to lower case on storage and comparison. Doing otherwise means a person who capitalises their address on Tuesday cannot sign in on Wednesday, and creates duplicate accounts that are painful to merge later.

Usernames

Store a normalised form for uniqueness checks and preserve the display form the person chose. That way a name is not claimed twice with different capitalisation, while the profile still shows it as intended.

Passwords

Never normalise a password. Case sensitivity is a meaningful part of the search space, and folding case discards entropy the person believed they had. Similarly, never trim whitespace from inside a password or truncate one to fit a column, both of which silently weaken credentials people chose carefully.

The Section Everyone Skips: Account Recovery

A secure login with a weak reset flow is a strong door in a paper wall. Recovery is where the majority of real account takeovers happen, and it appeared nowhere in the original eleven practices.

What a sound reset flow looks like

Generate a token with a cryptographic random source, store only a hash of it, expire it within fifteen to thirty minutes, and invalidate it the moment it is used or a newer one is issued. Rate-limit the request endpoint by account and by network address.

Return an identical response whether or not the address exists, so the form cannot be used to enumerate your users. Invalidate every active session on a successful reset, and email the account to confirm the change happened.

The failures we find most often

Tokens that never expire. Tokens embedded in a URL that then leaks through a referrer header. Reset links that remain valid after use, so anyone with access to the mailbox can replay them months later. Security questions, which are guessable from public information and should not exist. And a reset flow that bypasses the second factor entirely, which quietly reduces your carefully configured two-factor system to one factor.

That last one is worth checking today. If a password reset alone grants full access without the second factor, then the second factor protects nothing against anyone who controls the email account, and email accounts are the most commonly compromised asset in the chain.

Defending Against Credential Stuffing

Most login attacks now use valid credentials stolen from somewhere else, which means your password policy is irrelevant to them. The attacker is not guessing; they are trying combinations that already worked elsewhere.

Rate-limit by account and by network address, with an escalating delay rather than a hard lockout, since lockouts hand attackers a denial-of-service tool. Screen new and changed passwords against breach lists. Watch for the pattern that gives stuffing away, which is a high volume of attempts across many accounts with a very low success rate, and alert on it. Require a second factor or an email confirmation when a sign-in arrives from an unfamiliar device or location.

Add a challenge only when signals warrant it rather than on every attempt, because a challenge on the happy path costs conversions and stops determined attackers less than people assume. Configuring this properly sits with whoever owns your infrastructure, and it is standard work for teams who hire DevOps engineers to look after edge configuration and monitoring.

Proof: What This Looks Like on Real Work

Authentication decisions are easiest to justify with an example where the stakes were regulated rather than theoretical. This one is from our own client work.

Client: Ailleron, banking technology, Krakow Ailleron's reporting was spread across disconnected sources, which made compliance reporting slow and error-prone. Acquaint Softtech consolidated it into a centralised data warehouse with three BI and compliance dashboards built on top, each with controlled access for different internal roles. Result: around 200 hours a week saved across the reporting function, and report creation reduced from four days to one. The engagement holds a 5.0 out of 5 rating on Clutch.

The connection to this article is the access layer rather than the dashboards. In a banking environment, who can see which report is a compliance question, so identity has to be modelled properly from the start: a stable internal identifier, roles attached to it rather than to an email address, and sessions that behave predictably. Getting that structure right at the beginning is what allows a reporting platform to be opened to more people later without reopening the security design.

The wider record is verifiable rather than asserted: 1,300+ delivered projects, 95% on-time sprint delivery, and 4.9 out of 5 across verified Clutch reviews. We sign an NDA before work begins, and clients hold 100% ownership of what we produce. Our software case studies and client testimonials cover the longer engagements, which are the ones where authentication decisions are tested properly over time.

What an Authentication Build Costs

The first decision is not how much to spend but whether to build authentication at all. This comparison is the one most teams should make before any of the numbers below matter. 

Route	Suits you when	Trade-off
Framework built-in auth	Standard needs, full data control	You own every future fix
Managed identity provider	Speed matters, compliance is heavy	Per-user cost, external dependency
Provider plus custom layer	Complex roles or enterprise SSO	Highest flexibility, most integration
Fully custom build	Genuinely unusual requirements	Rarely justified, easiest to get wrong

For most products, the framework's built-in authentication, configured properly, is sufficient and keeps user data under your control. A managed provider earns its per-user cost when you need enterprise single sign-on, audited compliance, or speed above all else. 

What you are implementing	What it stops	Effort and cost (USD)
Argon2id with rehash on login	Offline cracking of your table	2 to 4 days, 1,500 to 5,000
Passkeys alongside passwords	Phishing and credential reuse	1 to 3 weeks, 6,000 to 20,000
Hardened recovery flow	The most common takeover route	3 to 6 days, 2,500 to 8,000
Rate limiting and breach screening	Credential stuffing at volume	2 to 5 days, 1,500 to 6,000
Identity and account separation	Costly rewrites two years later	1 to 3 weeks, 5,000 to 18,000
Compliant deletion pipeline	Regulatory exposure and fines	1 to 2 weeks, 4,000 to 14,000
Session management and revocation	Stolen tokens living forever	4 to 8 days, 3,000 to 10,000

Two things are worth reading off that table. The cheapest items, hardened recovery and rate limiting, prevent the two failures we see most often, which is an unusually good return. And identity separation is the only row whose cost multiplies with delay, because retrofitting it means touching every foreign key in the database rather than a handful of files. Do that one first even though nothing visible improves.

Where the work is done	Senior engineering rate	Same scope, relative cost
New York, USA	USD 110 to 200 / hour	Highest
United States (national)	USD 90 to 170 / hour	Very high
Australia	AUD 110 to 200 / hour	High
United Kingdom	GBP 65 to 130 / hour	High
Europe (EU)	EUR 70 to 140 / hour	High
India (Acquaint Softtech)	USD 25 to 49 / hour	Up to 40% lower

Authentication is well suited to a bounded engagement because the deliverables are inspectable: a threat model, a code diff, a passing test suite covering the reset flow. Where capacity rather than budget is the constraint, adding an engineer through IT staff augmentation for a few weeks usually covers the whole list, and our guide to web application development cost sets out how this fits a wider budget.

Frequently Asked Questions