Hacker News Reader

Comment by cbg0 | Hacker News Reader

Hosting a copy of phpMyAdmin behind basic HTTP authentication in 2025 really is asking for it.

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.

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.

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".

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.

> 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.

> "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.

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

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.

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.

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.

I guess those installs are the ones the Wordpress vuln scanners are looking for when they spam my server with /wp-admin/ requests.

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.

Do you have figures for that?

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

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

Reply on news.ycombinator.com