SECURITY

Passwords

The main hole isn’t password complexity, it’s reuse. The break-in is usually a boring story: a database leaked from some small forum you signed up to five years ago, and the same password opens your email — and from the email, everything else.

• Different passwords everywhere. Not «the same one plus a digit», but genuinely different.
• A password manager. Any decent one. You remember one master password, everything else is stored encrypted.
• Length matters more than symbols. A four-word phrase is more reliable than eight characters with an exclamation mark, and it’s easier to type on a phone.
• Check your email on a breach-lookup service. You’ll probably find a couple of unpleasant surprises.

Two-factor authentication

The second factor is what turns a stolen password into a useless string. Turn it on everywhere it’s offered: email, hosting, domains, affiliate networks, exchanges.

But not every second factor is equal. From weakest to strongest: SMS, an authenticator app, a physical key. SMS is the weakest option, because a number can be reissued at a mobile shop with a copy of your documents. Use an app for anything that matters.

Separation

Don’t mix personal and work. This isn’t paranoia, it’s about making sure one problem doesn’t drag everything else down with it.

What must never be left in plain text

Two real cases from our own practice — both look stupid, both happen constantly.

A password in the command history

On a server, the administrator password once ended up written in plain text in the command history — it was typed into the wrong field by accident, and the system dutifully saved it to a file. Anyone who gets access to that server for even a minute reads that file first.

A token in the logs

A Telegram bot was writing the full addresses of its requests into a log — with the token inside the address. Meanwhile the log had grown to three hundred megabytes and was sitting right next to the project. A token in a log means anyone who got the log got the whole bot.

The rule is simple: secrets live in a separate file with locked-down permissions and never end up in logs, in command history or in code. And if you have ever shown anyone a screen with a token on it, treat it as compromised and rotate it.

Proxies and IPs

If you work with several accounts, the IP is as much an identifier as a password. Three things matter here:

• One account — one IP. A permanent one, not something that changes every hour.
• The type of address matters. Platforms spot a datacenter server IP instantly. Mobile and residential addresses cost more but look like ordinary people.
• Check that the proxy genuinely works, not just that a «connection was established». You need a request out to an external service and a comparison of which IP it sees.

Backups

The dullest item and the most underrated. A backup isn’t protection from hackers, it’s protection from your own hand: deleted the wrong folder, updated a plugin, rebuilt the project and wiped the data.

We had a case: rebuilding the application deleted the folder entirely, and the working profiles lived inside it. That’s how a two-hundred-megabyte profile with live logins disappeared. It’s fixed by one line in the build script, but you only learn that after you’ve already lost it.

• The copy has to sit somewhere else, not where the original is.
• Once a month, check that the copy actually restores. An untested backup isn’t a backup.
• For a site that’s an archive of the files plus a database dump. For a bot — the code plus the database plus the settings file.

The short checklist

1. Password manager installed, no passwords reused.
2. Two-factor everywhere possible, backup codes saved separately.
3. Work email and work phone number separated from the personal ones.
4. No secrets sitting in code, logs or command history.
5. Domains and hosting registered to you, not to a contractor.
6. A fresh copy of the site and the database exists, and you have restored it at least once.