How bad is a bad password really?

Sarah Mount

25 February 2025

We tested how quickly a poor password could be cracked using a ‘honeypot’ site

If you have ever used a computer, no doubt someone at some stage has told you to choose a “good” password for a service you log into. There are a number of different methods that a bad actor might use to gain access to your account on a system. In this post I’m going to look at how to avoid brute-force attacks, where someone tries a large number of well-known or leaked passwords until they hit on one that successfully logs them in.

This is in no way a sophisticated attack and it relies on users making poor choices when they set up their accounts. But you might still wonder, if you do choose a very obvious password, how likely is it that someone will find the website you use and run a brute-force attack on your account?

Using a ‘honeypot’ site

The answer is ‘very likely’, and to demonstrate this we recently created a ‘honeypot’ site which was seeded with a number of accounts which had passwords taken from widely available lists of most commonly used credentials.

To make it a little less likely that our site would be attacked, we set up a WordPress installation which had the “Discourage search engines from indexing this site” set. This doesn’t guarantee that the site would not appear in searches, but it makes it less likely.

We also set up the honeypot accounts with very low levels of privilege and although the site had a human-readable URL it did not have any content except for the default WordPress theme (Twenty Twenty-Five) and an administrator account.

Of course, no-one should try this with any data they care about, but to make it slightly less risky we tweaked the WordPress theme to store information about any login attempts and to immediately log anyone out if they did break in. We couldn’t use dxw hosting for this because we have a number of security measures that would prevent these sorts of attacks, so we chose an external supplier.

Cracking accounts

Once we started recording login attempts, the first login attempt was made around 9 minutes later, and the first successful login came after 4 hours. All but one of the weak accounts were cracked after a few hours:

Over around 600 hours, 1980 attempts to login were made and 44 of those (2.22%) were successful. Those 1980 attempted logins were made from 470 unique IP addresses – the address that identifies the physical or virtual machine that the login attempt comes from.

The attackers tried a variety of usernames which are commonly used and might be expected to have administrator rights and some more random names that may have been leaked from previous breaches:

• adm
• admim
• admin
• admin@<website-domain>
• administrator
• alukgkcz
• editor
• ihqxfntu
• info@<website-domain>
• pntklcap
• <website-name>
• <website-name>@<website-domain>
• raawetbj
• specialsystemuser
• stender
• sucuri
• ulhnazud
• user
• wadminw
• wamdaines
• wwwadmin
• yekmiqak

By default, WordPress will tell you if you try to log into a site with a username that does not exist, which is useful information to an attacker. It’s also possible to determine the names of authors on a site, which can then be used to put together usernames or email addresses which can be used for attempted logins. Most hosting companies that deal with WordPress will change this default behaviour, but clearly enough users have predictable usernames for attackers to cycle through lists of them.

The pattern of attempted logins varied over time but it broadly matched the behaviour that we see on real systems that we host – there were some spikes in the number of attempts by people who slowly ran through a large list of potential passwords, and also a lot of attempts from attackers who tried a few times and moved on.

On a real system the spikes in login attempts are the ones we would be most concerned about and want to block. First because these attackers are a little more likely to succeed but also because a high volume of login attempts can use up resources and cause a site to perform poorly for legitimate users.

Number of failed and successful logins on the honeypot site, once we started recording all login attempts.

It’s also easy to see the effect of those spikes from a map of where each attack originated from – many countries only contributed a few attempts whereas a couple of countries generated several hundred.

Attempted logins by country of originating IP address.

It would make sense to assume that IP addresses that made a large number of login attempts were more likely to be successful in those attempts, but in this case at least quite a few IP addresses got lucky quite early in their attacks. Presumably attackers test more common usernames and passwords first, to save on their own infrastructure costs.

The number of attempted logins made by each IP address that tried to login to the honeypot site.

You might be wondering whether it’s possible just to keep a long list of IP addresses that are used for attacks like this and block them all. This is more complex than you might imagine. IP addresses are usually purchased in bulk by ISPs, hosting companies and other infrastructure providers and then used by customers as needed. So the IP address that you are using while you read this blog post might be one that has been assigned to your device for a long time, or it could be one that has only just been assigned to you, in which case there’s no way of knowing whether previous users of the address were legitimate. 

There are attempts to collect some indicative information about IP usage, such as AbuseIPDB which stores reports about IP addresses being used for malicious purposes. For the IP addresses attacking our honeypot site most had a positive (high) reputation, including several of those addresses that logged in successfully.

Reputation, as reported by AbuseIPDB, for each IP address that attempted to login to the honeypot site.

The number of abuse reports made to AbuseIPDB is also not simply correlated with the likelihood of malicious use, so we cannot use the volume of reports as a reliable metric for blocking IP addresses either:

Number of abuse reports made to AbuseIPDB, for each IP address that attempted to login to the honeypot site.

Why you should listen to your IT colleagues

So there’s no easy way to block malicious login attempts before they are made, and even for a site which has no meaningful traffic sent to it by search engines or social media, the likelihood of an attack taking place is pretty much certain.

Your IT colleagues are definitely right to nag you about using long, complex passwords but if you run a website, this sort of malicious behaviour should also influence your choice of hosting provider. Providers should be proactive in keeping software patched and up to date for you and have a plan for what to do when the worst does happen.

Unfortunately security attacks are a fact of life on the Internet, but good hosting providers will be familiar with common weaknesses in the software they host and have ways of mitigating attacks when they do occur.