Locked out of your own account
Whether this is an annoyance or a permanent loss was decided at setup, months before it happened.
- How often
- Common
- Typical size
- Whatever is inside
- Recoverable
- If you saved the material
- Cost to prevent
- One minute, once
Work through the dull causes first
- Verify you are on a genuine address before retrying. A login refusing correct credentials is what a copied page looks like after taking them, and each retry hands them over again.
- Try another address. Sessions are shared, so failing at one and working at another points at that address.
- Build a new circuit. A dying circuit produces failures that read exactly like rejection, including codes appearing wrong.
- Check your clock. Time based codes fail on a drifted machine, which is a surprising share of these reports.
- Check the username character by character. Not the password. People change a character and debug the wrong field for an hour.
- Wait an hour. Repeated attempts trigger rate limiting, which looks identical to refusal.
The version that is permanent
Recovery works when you hold the material you were given at setup. Without it, recovery is limited and frequently impossible, because the alternative would be a mechanism for taking over accounts you do not own.
That is why this entry costs one minute to prevent and that minute happens months before the problem. Save the recovery material before closing the setup page, keep it separate from the password, do not keep the only copy on one device, and test once that you can produce it.
What makes it expensive
A balance. A lockout with nothing parked is an inconvenience and a fresh account. A lockout with funds sitting there is a permanent loss, which is why rank one and this entry compound each other. Removing either one removes most of the cost of both.
Why access failures look like theft
A hidden service cannot see who you are, so it cannot treat you differently from anyone else knocking on the door. Everything protective it does is behavioural: slowing repeated attempts, refusing bursts, dropping connections under load. From your side those are indistinguishable from a rejected password, and the natural response, trying harder and faster, is exactly what triggers more of it.
The setup minute, written out
- Save the recovery material before closing the page. There is no second chance to see it.
- Store it apart from the password. Together, they are one secret rather than two.
- Put a copy somewhere physically different. A device failure should not be an account failure.
- Write down the date and the address you registered at. Both come up during recovery and neither is memorable.
- Test once that you can retrieve it without the primary device.