Securing Your Exchange Account

Go: open a terminal in a folder you can write to, e.g. cd ~/Desktop (Windows: cd %USERPROFILE%\Desktop).

Do: save this as totp.py. It prints nothing on its own — it is the generator the next steps call.

import hmac, hashlib, struct

def totp(secret: bytes, when: int, step: int = 30, digits: int = 6, algo=hashlib.sha1):
    counter = struct.pack(">Q", when // step)
    mac = hmac.new(secret, counter, algo).digest()
    offset = mac[-1] & 0x0F
    code = struct.unpack(">I", mac[offset:offset + 4])[0] & 0x7FFFFFFF
    return str(code % 10 ** digits).zfill(digits)

Now save this as check.py and run python3 check.py. It compares your generator against a value published in RFC 6238, the standard every authenticator app implements.

import hashlib
from totp import totp

secret = b"12345678901234567890"
print("code at T=59 :", totp(secret, 59, digits=8))
print("RFC 6238 says: 94287082")
print("implementation is correct:", totp(secret, 59, digits=8) == "94287082")

You should see: your own code matching the standard’s:

code at T=59 : 94287082
RFC 6238 says: 94287082
implementation is correct: True

Take in what that means. Your authenticator app is not talking to the exchange, and never has been. It is doing this arithmetic on a shared secret and the clock — which is why it keeps working in aeroplane mode.

If not: False on the last line means a character in the generator differs — the likely spot is mac[-1] & 0x0F or the >Q and >I format strings, which must be exactly those. ModuleNotFoundError: No module named 'totp' means the two files are not in the same folder.

Go: same folder.

Do: save this as window.py and run it. The starting moment is fixed so your output matches this page.

from totp import totp

secret = b"12345678901234567890"
start = 1_700_000_000          # a fixed moment, so your output matches this page

previous = None
for offset in range(0, 46, 5):
    code = totp(secret, start + offset)
    mark = "  <-- the code changed here" if previous and code != previous else ""
    print(f"second {offset:>2}: {code}{mark}")
    previous = code

You should see: the same code repeating, then changing twice:

second  0: 921300
second  5: 921300
second 10: 732303  <-- the code changed here
second 15: 732303
second 20: 732303
second 25: 732303
second 30: 732303
second 35: 732303
second 40: 136087  <-- the code changed here
second 45: 136087

Look closely at where the change happens: at second 10 and second 40, not at 0 and 30. The 30-second windows are aligned to the world clock, not to the moment you opened the app. That is why a code sometimes disappears the instant you finish typing it.

If not: if no <-- marker appears, the previous comparison is not being updated at the end of the loop. If the codes differ from those above, start was mistyped — the underscores in 1_700_000_000 are legal Python and are only there for readability.

Go: same folder. This is the number an attacker cares about.

Do: save this as lifetime.py and run it.

from totp import totp

secret = b"12345678901234567890"

for now in (1_700_000_000, 1_700_000_019, 1_700_000_025):
    left = 30 - (now % 30)
    print(f"at t={now}: code {totp(secret, now)}, valid for {left:>2} more second(s)")

You should see: the same six digits carrying wildly different amounts of remaining life:

at t=1700000000: code 921300, valid for 10 more second(s)
at t=1700000019: code 732303, valid for 21 more second(s)
at t=1700000025: code 732303, valid for 15 more second(s)

Between ten and thirty seconds is plenty. A phishing site does not need to store your code — it needs to use it once, immediately, on the real exchange while you wait for a page that will never load. Most exchanges also accept the previous window to tolerate clock drift, which quietly doubles that budget.

If not: if every line shows 30 seconds remaining, the modulo was written as now % 30 - 30 instead of 30 - now % 30. A negative number means the same thing with the operands swapped.

Go: same folder. This step is short because the finding is the point.

Do: save this as whichsite.py and run it.

from totp import totp

secret = b"12345678901234567890"
now = 1_700_000_000

for site in ["binance.com", "binаnce.com", "totally-not-a-phishing-site.xyz"]:
    print(f"code your app shows for {site:32s}: {totp(secret, now)}")

You should see: one code, offered to all three:

code your app shows for binance.com                     : 921300
code your app shows for binаnce.com                     : 921300
code your app shows for totally-not-a-phishing-site.xyz : 921300

Now look at the generator in step 1 again: the site is not one of its inputs. A six-digit code cannot tell the real exchange from a lookalike, because it never knew which site was asking. This is why 2FA codes do not stop a convincing phishing page — you read the code out, the attacker types it into the real site within your thirty seconds, and both of you are logged in.

If not: if the three codes differ, the now variable is being replaced inside the loop — it must stay fixed. There is deliberately no way to make this function depend on the site; that absence is the finding.

Go: same folder. This is what a hardware security key or a passkey does, reduced to its essential move.

Do: save this as securitykey.py and run it. You will play the victim on a lookalike domain while the attacker relays your proof to the real exchange.

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.exceptions import InvalidSignature

key = Ed25519PrivateKey.from_private_bytes(bytes(range(32)))   # a fixed practice key
pub = key.public_key()

def security_key_signs(challenge, site_you_are_really_on):
    """A hardware key signs the challenge TOGETHER WITH the site's name."""
    return key.sign(challenge + b"|" + site_you_are_really_on.encode())

challenge = b"login-attempt-8842"

proof = security_key_signs(challenge, "xn--binnce-5nf.com")

try:
    pub.verify(proof, challenge + b"|" + "binance.com".encode())
    print("binance.com ACCEPTED the relayed proof")
except InvalidSignature:
    print("binance.com REJECTED the relayed proof -- wrong site baked in")

You should see: the relay failing:

binance.com REJECTED the relayed proof -- wrong site baked in

The whole difference is the site’s name inside the signature. Your browser supplies it — the phishing page cannot lie about which domain it is, because the browser, not the page, decides what gets signed. The proof is therefore useless anywhere except the site it was made for. On an exchange holding real money, a hardware key or a passkey is not a marginal upgrade over a code app; it removes the attack that actually happens.

If not: if it prints ACCEPTED, the two site strings were made identical — the signing call must use the impostor domain and the verify call the real one. ModuleNotFoundError: No module named 'cryptography' means the library is missing; run pip install cryptography.