DEV Community: Autional

0.1 + 0.2 Is Not 0.3. Here Is Why Money Needs Its Own Way to Be Stored

Autional — Mon, 19 Oct 2026 01:59:53 +0000

A small shop owner runs a discount split on one order.

She calculates it with the till software. Then she does it again on paper. The two numbers differ by one cent.

She rubs her eyes and tries again. Still one cent off.

The customer says nothing. But the look says: "Are you overcharging me?"

She can cover the cent herself. But if the books do not add up, why should anyone trust her?

She wants to understand one small thing: where did that cent come from?

It is not a calculation error. And it is not a display quirk.

Many programs compute 0.1 + 0.2 and get this:

0.30000000000000004

The first reaction is usually: "That is just a display bug, right?"

No. The difference is real.

Computers store decimals in an approximate way. That way is called floating point.

Here is an analogy. Write one third as a decimal: 0.3333... It never ends.

In binary, 0.1 is the same kind of number. It never ends either.

If it never ends, it cannot fit. If it cannot fit, the computer stores an approximation.

The 0.1 you stored is already a tiny bit short. Add two of those, and you get that tiny difference.

Three ways to store a number

Storage	Exact 0.1?	Rounding under control?	Cost	Good for
Floating point (float/double)	No	No	Small	Graphics, science
Integer minor units (cents)	Yes	Fixed 2 digits	Must fix one unit	Single currency, payments
Fixed-point decimal (DECIMAL)	Yes	Yes, explicitly	A bit slower, a bit bigger	Default for ledgers

In one line: where "close enough" is fine, floating point is fine. Where "not one cent off" matters, it is not.

A short history

When	What happened
1985	IEEE 754 is published: floating point gets an international standard
1982–1983	A Vancouver stock exchange index keeps three decimals and truncates the rest
22 months later	The index "falls" from 1000 to 524.811; newspapers say the market is finished
Nov 1983	A weekend fix; the index jumps back to 1098.892
After that	Financial systems move to fixed-point decimal

The counter-intuitive part: the index did not halve because of floating point. It halved because the rounding rule was wrong.

There is one test: money is not a number. It is a ledger.

The same error, in different places, has very different consequences.

In a draft or an image
off by 0.00000000000004 -> nobody notices

In a money ledger
off by 0.01 -> the books do not balance; someone spends a day hunting it

A draft can be "close enough." Money cannot.

Money has to reconcile: your entry and mine must match to the cent.

So money is not an ordinary number. Money is a ledger.

What actually breaks is often not "cannot store it"

That exchange index was not a floating point problem.

Its rule was: after each calculation, keep three decimals and truncate the rest — not round, truncate.

It ran two to three thousand times a day. Each time it cut a little off.

The error only ever went one way. After 22 months, the index had "halved."

That is what a rounding rule is: how many decimals to keep, and how to treat the remainder. You have to write it down first.

Rule	How	Bias
Truncate	Drop extra digits	Always downward; accumulates
Round half up	5 and above rounds up	Nearly unbiased, but .5 always up
Banker's rounding	.5 goes to even	Close to unbiased; common in finance

So how should money be stored?

Case	Practice
Amount fields	Fixed-point decimal, digit by digit
Precision	Do not stop at two decimals; multi-currency and tax need more
FX rate	Not a fixed number; a quote with an ID and an expiry
Ledger	Append-only; verify entry by entry
Rounding	Hard-code the rule; never rely on defaults

A common setup: amounts as DECIMAL(20,4), tax rates at higher precision, currencies as ISO 4217 three-letter codes.

When you send or display an amount, send it as a string, not a number. Every extra hop can make it "close enough" again.

Four common mistakes

Mistake	Fact
"0.1+0.2 is just a display issue."	No. There is no exact 0.1 in binary.
"Two decimals are always enough."	Not with multiple currencies and tax.
"Precision incidents are calculation errors."	Often the rounding rule was wrong.
"An FX rate is just a number."	It is a quote that expires.

Takeaway

Numbers can be "close enough." Money cannot: one cent off means the books are wrong.

Next time a bill is off by a cent, ask one more question: did it calculate wrong — or was money never treated as a ledger?

We hit this ourselves while building Autional, an identity and access management platform: we migrated amount fields from floating point to fixed-point decimal, and from two decimals to four — seven models in total. Slower and a bit bigger, in exchange for books that balance to the cent. https://www.autional.com

Sources

IEEE 754-2019, IEEE Standard for Floating-Point Arithmetic.
ISO 4217, Codes for the representation of currencies.
Wall Street Journal (1983-11-08), Toronto Star (1983-11-29) — coverage of the Vancouver Stock Exchange index truncation.
McCullough & Vinod, Journal of Economic Literature (1999), retrospective on the same event.

The Page Looked Exactly Like the Real One. So Why Was the Account Still Stolen?

Autional — Sun, 18 Oct 2026 10:22:17 +0000

You get a message: "Unusual activity. Please sign in again."

You click. The icon, the colors, the font — exactly like the real site.

You type your password. You even check: two-factor is on. You feel safe.

The next day, the account is gone. Someone is using your name to ask your friends for money.

What went wrong?

Not a weak password. Not a useless one-time code. The page was fake.

Phishing is not "guessing your password." It is a fake page plus a live relay.

The attacker puts a fake page in front of the real site.

You think you are talking to the site. In fact, someone sits in the middle.

Whatever you hand over, they pass it on — to the real site.

So the real question is not "how strong is my password?" It is:

Can the thing you use be handed over?

Five login methods, side by side

Method	What proves it	Can it be handed over?	Phishing-resistant	Main weakness
Password	something you remember	Yes — typed straight into the fake page	No	reuse, leaks
SMS code	a code sent to your phone	Yes — the attacker asks you for it	No	SIM swap, live relay
Magic link	a link in your email	Yes — whoever finds it, gets in	No	link theft
QR login	your logged-in phone confirms a number	Yes — the number can be swapped	Partial	wrong code, swapped code
Passkey	a key inside your device	No — the key never leaves the device, and it only trusts the site it registered with	Yes	lost device, cross-device sync

In one line: if it can be spoken, typed, or clicked open, it can be handed over.

A short history

When	What happened
1990s	"Phishing" appears: fake email + fake page to steal passwords
2019	W3C publishes the WebAuthn standard (the basis of phishing resistance)
2022	Apple, Google, and Microsoft push Passkeys
2022	Microsoft reports a wave of "adversary-in-the-middle" phishing that steals the login session too

The direction is clear: take the key out of the network, and lock it in the device.

There is only one test

A fake page sits between you and the real site
You (something hand-over-able) -> fake page -> real site <- the hand copies it
You (Passkey) -> x the fake page is not trusted -> cannot be handed over

Why does a Passkey resist phishing? Two reasons:

The key lives inside your device. It never leaves.
It only trusts the exact site it registered with. Wrong address, no deal.

A fake page is simply not trusted. Even if you wanted to hand it over, you cannot.

What the standards say

NIST SP 800-63B-4 (2025): passwords, look-up secrets, and out-of-band (SMS/QR) are not phishing-resistant. Higher assurance levels require phishing resistance.
Microsoft (2022): an AiTM wave stole password + login session together, and walked past MFA; by its own report, it targeted 10,000+ organizations in under a year.

Together: not every "extra step" is equally strong.

So what should you pick?

Who you are	What to do
Regular user	Turn on Passkeys first; if you cannot, at least stop reusing one password everywhere
Everyday work	Prefer Passkeys (phishing-resistant); keep one usable fallback
Sensitive roles / admins	Require phishing resistance: Passkey or a hardware key

Four common mistakes

Mistake	Fact
"With a code, I am safe from phishing."	Not always. The code can be relayed live.
"If the page looks right, it is right."	A fake page can copy the design 1:1. Check the address, not the look.
"One-click login is both easier and safer."	The easier it is to hand over, the easier it is to steal.
"Passkeys are foolproof."	They fear lost devices, missing cross-device sync, and old sites that do not support them.

Takeaway

Phishing resistance comes down to one thing: can the thing you use be handed over? If it can, a fake page is dangerous.

(If the account was already stolen: revoke all sessions, sign in again, then switch to something that cannot be handed over.)

These practices come from building Autional, an identity and access management platform — https://www.autional.com

Sources

NIST, SP 800-63B-4, Digital Identity Guidelines (2025) — phishing resistance.
W3C, WebAuthn Level 2 (2021); FIDO Alliance, FIDO2 / CTAP2.
Microsoft Security Blog (2022-07-12), adversary-in-the-middle (AiTM) phishing: password and session theft, MFA bypass.
Zscaler ThreatLabz (2022-08-02), independent observation of the same AiTM proxy phishing.

"Sign in with Google": Why It Bounces You Out and Back

Autional — Sun, 11 Oct 2026 05:47:18 +0000

You click "Sign in with Google." The page jumps away, jumps back a second later, and you are in. So why the round trip — why not just type something on this page?

Because the safe way is to never hand over your password.

The old way: hand over your password

Twenty years ago, if a site wanted to read your data somewhere else, you gave it your password. Convenient — and costly:

It stored your password, sometimes in plaintext.
It got the full set, so it could do things you never agreed to.
To undo it, you could only change your password — which logged you out everywhere else too.

The new way: bounce out, approve, bounce back

The password stays put. You click "Sign in with Google": you bounce to Google, sign in, and approve; you come back with a single-use ticket — the authorization code; the site trades that ticket for an access token — a pass that says on whose behalf, until when, and what it can do. The site never touches your password.

What you get back: a pass with a scope

The pass carries three things: on whose behalf, until when, and what it can do. Whatever you did not tick is not on the pass, and the door stays shut (scope, RFC 6749 3.3). The pass expires, and you can revoke it anytime under "authorized apps."

How it got here: 1.0 to 2.0 to patches

Stage	When	What changed
OAuth 1.0	2007 (RFC 5849)	First version; convoluted, everyone rolled their own
OAuth 2.0	2012 (RFC 6749)	Rewritten into one common version; codes become single-use
PKCE	2015 (RFC 7636)	A proof key makes a stolen code useless
Security BCP	2025 (RFC 9700)	Implicit flow deprecated; PKCE mandatory

The real opening: the consent step

The danger is not the password — it is you, at the consent prompt. In 2022, attackers built malicious OAuth apps (one even passed a Verified Publisher review) that tricked people into clicking approve — then quietly read their email and calendar (Microsoft / Proofpoint). That "bounce out" is your one clear look: see who is asking before you approve.

Three things people get wrong

"Sign in with X" is not the same as the site being secure. Your password only went to the provider.
It is not a login protocol. OAuth is authorization; proving who you are is OIDC.
Approving is not forever. You can revoke access under "authorized apps."

Takeaway

With third-party sign-in, the site never gets your password. It gets a scoped, expiring, revocable pass.

These practices come from building Autional, an open-core identity and access management platform — https://www.autional.com

Reference: RFC 6749, RFC 7636, RFC 9700, RFC 5849, OpenID Connect Core 1.0; case: Microsoft consent phishing (2022).