The hacker posted a screenshot of the shell on the 4chan server. It was running FreeBSD 10.1, which came out in 2014 and stopped getting patches in 2016. It seems like there was basically nobody doing maintenance after moot sold the site. I wonder how long it'll take for them to get the site back up if they don't have anyone who can do server administration.
Sure, if you slap Basic Auth with "admin:admin" on phpMyAdmin in 2025, you're asking for it. But a Basic Auth password with 256 bits of entropy is just as resistant to brute force as AES-256 (assuming the implementation is sound and TLS is used). It's not the protocol that's insecure, it's usually how it's deployed.
As long as "a lot of attempts" take longer than the time it'll take the sun to expand and envelop the earth, that's not really a problem.
Every form of authentication is either subject to "a lot of attempts" or trivial DoS (for when you rate limit the login API so now admins can't log in either). The principles behind modern authentication are mostly "how do we make verification require even more attempts if the attacker doesn't know the password".
"a lot of attempts" is doing a LOT of heavy lifting here.
If your password was a set of random letters (both upper and lower case) and numbers and 20 characters long, then even if you could attempt 1,000 logins/second (a very high number for an online attack), it would take a whopping 2,232,000,000,000,000,000,000,000 years.
If you could do 1,000,000 logins/second, an absolutely absurd number for an online attack, that only takes 3 zeros off that number.
What is "a lot of attempts"? I'm no expert in cryptography, but there's many orders of magnitude difference between a distributed bruteforce of a known hash, and bruteforcing over the web.
Can you please elaborate how it is "asking for it" if we assume the basic auth password is reasonably complex and kept as safe as, say, the SSH login credentials of the same server?
You shouldn't be logging in to a server via SSH using a user+password combo, instead use a public/private key combo which is considerably more complex and can't effectively be bruteforced like a user+password.
Most web servers don't really come with any built in defense against brute force attempts vs Basic Auth gates, so unless you've set something up to protect it, someone with enough time will eventually get in.
Genuine question that I haven't found a good solution to yet, if I want to just go to any old computer and ssh into my server, do I have to carry around a USB stick with the ssh key on or something? because I sure as hell wont be able to just remember it
In that case I'd normally recommend a bastion host with SSH MFA and fail2ban. It'd be publicly available and have SSH keys for other machines. Or you could look at setting up a VPN solution with MFA, but never have a password only admin login exposed to the public Internet.
That's my point - if you have a reasonably secure password (let's say 50-100 characters, fully random), it's extremely unlikely that anyone is ever going to even get beyond the basic auth prompt.
Then you should also be worried about bugs that let you log into an SSH session without providing your SSH certificate, passkey or whatever. Authentication bypass can happen with pretty much any buggy authentication method. None of this is inherently a problem of passwords or basic auth.
Again, the premise was that phpMyAdmin is secured behind basic auth. It doesn't matter how secure or insecure phpMyAdmin is, it only matters how secure whatever webserver is that it is served through. phpMyAdmin code isn't even touched before the basic auth login was successful. Only after that, it becomes relevant, in that you either find a hole in phpMyAdmin itself, or you have to break another (hopefully strong) password for the MySQL login itself.
You can easily put phpMyAdmin behind basic auth as an additional security layer, completely bypassing any PHP execution and letting the web server completely handle the authentication. It's exactly what I have done multiple times in the past. Arguably phpMyAdmin's direct integration is a less secure way of doing it, but do we even know if it's the basic auth itself that was bypassed, or was it just the case of a weak password?
A password is just plain text, which apart from being bruteforced, can easily be phished. There are so many things wrong with using a password even if it's fairly complex. Instead, stick to passkeys and SSH keys
I was kinda surprised to see that phpMyAdmin is still maintained, albeit only barely. The last release was in January but before that it hadn't been touched for over two years.
Nearly every website developer servicing small business builds a WordPress site and sets it up on a hosting company's cPanel install with phpmyadmin running by default.
Which are far far outnumbered by people setting up squarespace sites, or shopify sites or facebook pages or twitter profiles these days.
It was definitely true at one point that small scale indie web devs and small business contractors outnumbered big tech in both headcount and servers. I don't think that's been true for a while now.
- nih.gov - It's using Drupal, per a meta generator tag
- forbes.com - No real for or against evidence, though the lack of any wp- paths leans a little more against it being wordpress
- archive.org - It's some type of react app, not wordpress. Probably home grown
- nginx.org - Just... no.
- ebay.com - Would it surprise you, no.
I have serious questions about their methodology.
Similarly, just because sites like Techcrunch use Wordpress, doesn't mean they're doing it by having someone upload files over FTP to some cPanel managed Godaddy account.
Most of those do in fact seem to use WordPress for part of their site:
* microsoft.com – uses WP at devblogs.microsoft.com
* digicert.com – may be a false positive, they link to files at /wp-content/ URLs, maybe they used WP in the past and kept the URLs?
* mozilla.org – uses WP at blog.mozilla.org
* nih.gov – uses WP at directorsblog.nih.gov
* forbes.com – can’t tell, my ad blocker breaks their cookie consent screen
* archive.org – uses WP at blog.archive.org
* nginx.org – uses WP at blog.nginx.org
* ebay.com – may be false positive?
We end up with 2/10 potential false positives, and one unknown (and even then, those are huge sites, who knows if they’ve got WP hiding under some deeply-buried subdomain).
I agree with you that Microsoft and TechCrunch probably aren’t FTPing their files in, but even if we assume that only 50% of WordPress sites are doing so, that’s still more websites than the next 10 competitors, combined!
If you think about it, this makes sense: do you reckon your local small businesses have a TechCrunch-level web presence, or are they using GoDaddy? Now consider that there exist many more local businesses than TechCrunches.
I serve a cPanel hosting, some people just want something up and running now which cPanel provides.
With Softaculous for automatic installation of scripts it's still widely popular for Wordpress installations. Web hosting is however a very dead market to startup in.
The hacker posted a screenshot of the shell on the 4chan server. It was running FreeBSD 10.1, which came out in 2014 and stopped getting patches in 2016. It seems like there was basically nobody doing maintenance after moot sold the site. I wonder how long it'll take for them to get the site back up if they don't have anyone who can do server administration.
Sure, if you slap Basic Auth with "admin:admin" on phpMyAdmin in 2025, you're asking for it. But a Basic Auth password with 256 bits of entropy is just as resistant to brute force as AES-256 (assuming the implementation is sound and TLS is used). It's not the protocol that's insecure, it's usually how it's deployed.
Only if it's only accessible via proper TLS (otherwise it's easy to read the user/pass with MITM as basic auth doesn't encrypt the user/pass).
If there is no throttling/rate-limiting/banning then this setup allows for a lot of attempts, wether brute-force or dictionary.
As long as "a lot of attempts" take longer than the time it'll take the sun to expand and envelop the earth, that's not really a problem.
Every form of authentication is either subject to "a lot of attempts" or trivial DoS (for when you rate limit the login API so now admins can't log in either). The principles behind modern authentication are mostly "how do we make verification require even more attempts if the attacker doesn't know the password".
"a lot of attempts" is doing a LOT of heavy lifting here.
If your password was a set of random letters (both upper and lower case) and numbers and 20 characters long, then even if you could attempt 1,000 logins/second (a very high number for an online attack), it would take a whopping 2,232,000,000,000,000,000,000,000 years.
If you could do 1,000,000 logins/second, an absolutely absurd number for an online attack, that only takes 3 zeros off that number.
What is "a lot of attempts"? I'm no expert in cryptography, but there's many orders of magnitude difference between a distributed bruteforce of a known hash, and bruteforcing over the web.
Can you please elaborate how it is "asking for it" if we assume the basic auth password is reasonably complex and kept as safe as, say, the SSH login credentials of the same server?
You shouldn't be logging in to a server via SSH using a user+password combo, instead use a public/private key combo which is considerably more complex and can't effectively be bruteforced like a user+password.
Most web servers don't really come with any built in defense against brute force attempts vs Basic Auth gates, so unless you've set something up to protect it, someone with enough time will eventually get in.
> "can't effectively be bruteforced like a user+password."
Only when the password is weak enough to bruteforce swiftly. It will take literally thousands of years to bruteforce strong passwords.
But you only need one weak password to get in
But you only need one password to protect your HTTP auth phpMyAdmin so just make it 30 characters.
> someone with enough time will eventually get in
That's only correct if the password is weak. With enough entropy, it's practically impossible to brute force.
Genuine question that I haven't found a good solution to yet, if I want to just go to any old computer and ssh into my server, do I have to carry around a USB stick with the ssh key on or something? because I sure as hell wont be able to just remember it
The preferred solution would be something like a Yubikey. However:
> just go to any old computer and ssh into my server
You've typed your password into a computer you don't control. Now it's gone. Same for plugging in the USB stick. The Yubikey approach mitigates that.
Assuming you want to do this, the best practice you can achieve is just making the password long.
I mean, the password to the only ssh thing accessible from outside is 17 characters, and root is not ssh-able, only my user with a custom username
There's no secure way to do that. You have no guarantee that the computer won't copy your key or keylog your password.
You can mitigate it by using an MFA method that requires confirming on a separate device like a phone, but that's down to one layer of defense.
I use an SSH app on my phone for remote access, and I go over a VPN. SSH is not exposed to the public internet.
In that case I'd normally recommend a bastion host with SSH MFA and fail2ban. It'd be publicly available and have SSH keys for other machines. Or you could look at setting up a VPN solution with MFA, but never have a password only admin login exposed to the public Internet.
I haven’t used it for many years now, but phpMyAdmin was long a source of compromises. Lots of security holes.
That's my point - if you have a reasonably secure password (let's say 50-100 characters, fully random), it's extremely unlikely that anyone is ever going to even get beyond the basic auth prompt.
Until there's a bug that lets you bypass it.
Then you should also be worried about bugs that let you log into an SSH session without providing your SSH certificate, passkey or whatever. Authentication bypass can happen with pretty much any buggy authentication method. None of this is inherently a problem of passwords or basic auth.
Sure, but phpMyAdmin has a long history of major security holes. It's existence on a server tends to be a red flag.
Again, the premise was that phpMyAdmin is secured behind basic auth. It doesn't matter how secure or insecure phpMyAdmin is, it only matters how secure whatever webserver is that it is served through. phpMyAdmin code isn't even touched before the basic auth login was successful. Only after that, it becomes relevant, in that you either find a hole in phpMyAdmin itself, or you have to break another (hopefully strong) password for the MySQL login itself.
It's not using the webserver's basic auth, it's using their own implementation (https://github.com/phpmyadmin/phpmyadmin/blob/297c1e174b93a9..., via PHP's: https://www.php.net/manual/en/features.http-auth.php).
You can easily put phpMyAdmin behind basic auth as an additional security layer, completely bypassing any PHP execution and letting the web server completely handle the authentication. It's exactly what I have done multiple times in the past. Arguably phpMyAdmin's direct integration is a less secure way of doing it, but do we even know if it's the basic auth itself that was bypassed, or was it just the case of a weak password?
Sure, and I can put the VX gas vials in a safe in my basement, but I'd rather not have them anywhere near me at all.
A password is just plain text, which apart from being bruteforced, can easily be phished. There are so many things wrong with using a password even if it's fairly complex. Instead, stick to passkeys and SSH keys
I was kinda surprised to see that phpMyAdmin is still maintained, albeit only barely. The last release was in January but before that it hadn't been touched for over two years.
This stuff is still packaged with cPanel, which is probably the most common way to manage web servers on the internet.
I wonder how long it's been since that was true. I think that era passed when most small businesses and individuals moved from self hosting to SaaS.
Nearly every website developer servicing small business builds a WordPress site and sets it up on a hosting company's cPanel install with phpmyadmin running by default.
Which are far far outnumbered by people setting up squarespace sites, or shopify sites or facebook pages or twitter profiles these days.
It was definitely true at one point that small scale indie web devs and small business contractors outnumbered big tech in both headcount and servers. I don't think that's been true for a while now.
That’s not what the stats show.
WordPress powers 43% of websites today. Shopify, Wix, and Squarespace together only account for 11%.
https://w3techs.com/technologies/overview/content_management
Here's their "10 popular sites using Wordpress"
- microsoft.com - It's not wordpress, probably home grown
- wordpress.org - This one's a freebie
- digicert.com - Using Adobe Experience Manager, per script includes
- wordpress.com - Another freebie
- mozilla.org - No, using a homegrown CMS: https://github.com/mozilla/nucleus
- nih.gov - It's using Drupal, per a meta generator tag
- forbes.com - No real for or against evidence, though the lack of any wp- paths leans a little more against it being wordpress
- archive.org - It's some type of react app, not wordpress. Probably home grown
- nginx.org - Just... no.
- ebay.com - Would it surprise you, no.
I have serious questions about their methodology.
Similarly, just because sites like Techcrunch use Wordpress, doesn't mean they're doing it by having someone upload files over FTP to some cPanel managed Godaddy account.
Most of those do in fact seem to use WordPress for part of their site:
* microsoft.com – uses WP at devblogs.microsoft.com
* digicert.com – may be a false positive, they link to files at /wp-content/ URLs, maybe they used WP in the past and kept the URLs?
* mozilla.org – uses WP at blog.mozilla.org
* nih.gov – uses WP at directorsblog.nih.gov
* forbes.com – can’t tell, my ad blocker breaks their cookie consent screen
* archive.org – uses WP at blog.archive.org
* nginx.org – uses WP at blog.nginx.org
* ebay.com – may be false positive?
We end up with 2/10 potential false positives, and one unknown (and even then, those are huge sites, who knows if they’ve got WP hiding under some deeply-buried subdomain).
I agree with you that Microsoft and TechCrunch probably aren’t FTPing their files in, but even if we assume that only 50% of WordPress sites are doing so, that’s still more websites than the next 10 competitors, combined!
If you think about it, this makes sense: do you reckon your local small businesses have a TechCrunch-level web presence, or are they using GoDaddy? Now consider that there exist many more local businesses than TechCrunches.
Do you have figures for that?
I guess those installs are the ones the Wordpress vuln scanners are looking for when they spam my server with /wp-admin/ requests.
I serve a cPanel hosting, some people just want something up and running now which cPanel provides.
With Softaculous for automatic installation of scripts it's still widely popular for Wordpress installations. Web hosting is however a very dead market to startup in.
A tale as old as time