Hotspot users with trivial passwords

What the audit found

The export contains hotspot user accounts under IP → Hotspot → Users whose passwords are trivial — very short, a dictionary word, digits only, the same as the username, or similar. The finding lists the account names concerned.

The audit rates this low. Hotspot accounts are, by design, often shared and easy: a "click to connect" login for a café or waiting room. The point of the finding is not that every hotspot password must be strong, but that you should check what each of these accounts can actually do. An account named admin with password 1234 on a hotspot is a very different matter from a guest account with the same password.

Why it matters

A hotspot user account controls two things: whether a device on the hotspot network gets through the captive portal, and which hotspot profile — and therefore which limits — apply to it. On a properly isolated guest network, a guessed guest password gives an outsider free internet and nothing else. That is a nuisance rather than a breach, and for many public hotspots it is the intended level of security.

The situations to worry about are the exceptions. A hotspot profile that skips the firewall rules or has an address list granting access to internal servers. A staff account that exists on the hotspot "so we can use the WiFi" and points to a profile with no isolation. An account named admin, manager or after a person, which suggests it was created for someone with expectations beyond guest access. Any of these with a trivial password turns the public WiFi into a way into your network, and the password will be guessed — captive-portal logins are easy to try in bulk, and the usual suspects (1234, password, the venue's name) come first.

There is also a billing angle: on a paid hotspot, a guessable password on a shared account means free service for anyone who works it out, and in some setups a shared account is limited to a single session, so the legitimate user is kicked off when someone else logs in with it.

Treat the finding as a prompt to review hotspot accounts against what they are allowed to reach, rather than as a demand for complex passwords on the guest login.

What it looks like in Winbox

Open IP → Hotspot → Users. Each row shows Name, Profile, Address and limits. The passwords are hidden in Winbox; the audit sees them because the export was made with the show-sensitive option. Check the Profile column against IP → Hotspot → User Profiles to see what each account is entitled to.

How to fix it

Start by deciding which accounts are genuinely guest accounts. For those, a simple password is acceptable as long as the hotspot network is isolated from the LAN and the profile carries no special rights. Check the profile's Address List and Incoming/Outgoing Filter settings under IP → Hotspot → User Profiles, and make sure the guest interface has a forward-chain drop rule towards internal networks (the audit reports a missing one separately).

For any account that is not purely a guest login — anything named after a role or a person, or attached to a privileged profile — set a proper password in the account's dialog under IP → Hotspot → Users: a random passphrase of 4–5 unrelated words or at least 16 random characters from a password manager. Remove accounts that nobody uses, particularly anything called admin or test. If the goal is to give staff WiFi access, give them a separate SSID on the internal VLAN instead of a privileged hotspot account.

Where guests need individual access, use the hotspot's built-in User Manager or voucher-style generated accounts with an expiry, so that each password is short-lived rather than shared for years. None of this affects your management session, so Safe Mode is not needed.

Afterwards, look through IP → Hotspot → Users once more to confirm that no privileged or role-named account remains with a trivial password and that the remaining accounts use guest-only profiles, then log in through the portal with a guest account and confirm that LAN addresses are unreachable. Re-run the audit with a fresh sensitive export: the finding should disappear or list only accounts you have consciously accepted.

The full MKRouterKit report gives the exact commands for your configuration — with your interface names and subnets filled in, in the order that will not lock you out.

FAQ

Our café hotspot uses one shared login with a simple password. Must I change it?

No, if the hotspot network is isolated from your internal LAN and the account's profile grants nothing beyond internet access. That is the normal way to run a public hotspot. The finding is low severity for exactly this reason; use it to double-check the isolation rather than to complicate the guest login.

Why does the audit see hotspot passwords at all?

Because the export was created with the show-sensitive option (or on RouterOS 6, which includes secrets by default). This is necessary for any password check but means the file is sensitive. Delete it once the audit is done and do not send it by e-mail or chat.

Does a MAC-based or trial login make this irrelevant?

Partly. If users are authenticated by MAC address or a trial timer, the password accounts may be unused, in which case remove them. Any account that still exists can still be used by someone who types it at the portal, whether or not that is the intended path.