passgen: a password generator with a memory

2026-08-05T00:00:00+00:00

I just added passgen, a password generator, to my colas-bash-lib collection. It is a tool that lives in your terminal, generates a password, copies it to your clipboard, and keeps a private log of what it generated and for what.

Why a log, you may ask. Because the biggest password problem is not generating strong ones, it is remembering which password goes where. My log solves it in the laziest possible way: I search it when I need to know which password I used for a given site.

What it does🔗

passgen generates a password of length 24 by default, made of lowercase letters, uppercase, digits, and a few special characters. It is careful about the details:

It starts with a lowercase letter, so the password is a valid identifier anywhere.
It deliberately avoids the zero character, to prevent confusion with the letter O.
The special characters are limited to -%=+_^/~?. — the ones that survive a double-click to select the whole password, which is the way I copy things from a terminal.

Then it copies the password to your clipboard, on Wayland or X11 alike. No need to select it yourself.

The log🔗

Every generated password is appended to ~/.local/state/passgen/log, with a date and an optional note. I use it this way:

passgen -l lists the last passwords generated, so I can find the one for a given site.
passgen 32 facebook generates a 32-character password and logs it as the "facebook" one.

The log is chmod'ed to be readable only by me, and I keep it in sync and backed up like the rest of my home directory. It replaced my password manager for everything but shared secrets.

Checking the strength🔗

passgen -s 24 prints the strength of a password of that length in number of combinations, which for 24 characters is about 10^42 — comfortably future-proof even against quantum computers. The default length of 24 is chosen for exactly that reason.

Why I like it🔗

One tool, one habit: no account, no sync, no database, nothing to learn. Generate, paste, done.
The password is in my control, stored in a plain file I can grep, rsync, and back up with the rest of my life.
Useful in a script: pipe it, adapt the length, add a note. It composes like any other command-line tool.

See it and the rest of my bash functions at colas-bash-lib.

I recovered my Facebook account, read how

2026-04-28T00:00:00+00:00

What happened🔗

On 2024-10-24, my Facebook account was hacked. Alas, Facebook did not allow me to get back my account, or even report the account as compromised, without entering the current password that whad been changed by the hackers. So I had to create a new account, and moved on.

However, I recently created a test account on Instagram, to try to generate RSS feeds to follow Instagram accounts more comfortably via my RSS-Bridge. And I was surprised to see that my "new" account was in fact the account of another user that had been blocked, then unblocked.

This prompted me to try to re-log into my old Facebook account and... it worked! I was able to reset the password without knowing the current one. I thus will remove the new account after some time.

Nice, but why?🔗

But looking a bit (for instance about Risk-Based Authentication (RBA), it appears I was lucky to try to re-use my account just days after a 6 month delay: Facebook relaxes accounts the security measures 6 months after a detected suspicious activity!

The behavior I experienced — being blocked from recovery despite having valid contact info, followed by a sudden "opening" of access — is apparently a documented pattern in Facebook’s security ecosystem, notably their automated risk assessment procedures.

The "Security Freeze" (Why I was stuck)🔗

When a hijacker changes a password, Facebook’s "Trusted Device" and "Location" protocols often trigger a lock. Even if my email and phone were correct, Facebook may refuse a reset if:

I cannot provide the current password, aka The "Current Password" Requirement. This is a common defensive measure when Facebook detects a "conflict of ownership." If the system sees two different locations (mine and the hacker's) trying to claim the account, it often demands the current password to prevent the owner from being "kicked out" by someone who isn't actually the owner. Needless to say, this is a really bad design, as hackers first move is to change the password.
I use another browser. As I tried many ways to recover my account, I also tried to use another browser on another machine, to start afresh. But this failed Facebook IP Reputation detection: Seeing I was trying to recover the account from a network or device the system didn't "trust" at that moment, it applied the most restrictive recovery path to the account.

Why it suddenly worked (The 6 months "Cooldown" Period)🔗

Nothing is actually officially documented, but here is the likely scenario:

Risk Score Decay: After 6 months of inactivity (or if the hacker eventually triggered a "Security Lock" that made the account go dormant), the "Risk Score" associated with the account drops.
Account Dormancy: Facebook often flags accounts that have been compromised as "checkpointed." After a certain period of time without successful logins from the hijacker, the system may lower the threshold for recovery for the original owner, especially if he are using a device or IP address that was associated with the account for years before the hack.
The "Verification Reset": Facebook occasionally clears the "verification debt" on accounts. If the hacker was blocked by Facebook’s automated systems (e.g., for spamming), the account enters a state where the next person to provide valid 2FA or email confirmation is granted access without the "current password" hurdle.

All of this is totally automated, with no human intervention, by the system's "Identity Verification" logic resetting itself after a period of dormancy. Once the "Pirate" was no longer active, the system stopped viewing my recovery attempt as a "hostile takeover" and allowed the standard email/phone reset to work.

Summary of Known Behavior🔗

Stage	System Logic	Result
Initial Hack	High-conflict state; system protects the "active" user.	Recovery denied despite valid email.
The 6-Month Gap	Account goes dormant or hacker is "checkpointed."	Security tension on the account relaxes.
Recovery	System recognizes you are the owner IP/Location and valid contact info.	Password reset allowed without "Current Password."

What to do once the account is recovered🔗

Check the Settings for "Saved Login", "Where you're logged in", and "Apps and websites" immediately. Sometimes hackers leave a "backdoor" by authorizing a specific browser or app that doesn't require a password.
Change the password, enable 2FA (Two-factor authentication).
Remove all apps connected to the account.
Check other sites that authorized logins from this Facebook account, change their passwords andf look for suspicious activity.

Colas.Nahaboo.net - security