Impossible to avoid login attempts from multiple ip addresses to my admin

You can unlink it, but the majority of users who ‘lose’ their admin pages would be VERY confused by this, and it would make supporting them nigh impossible.

See it this way.

If you have a safe (the admin directory) in your house. Would you like anyone that you have that and besides, where is located? Even if you have a strong password to open it?

May be new vulnerabilities in the future, so relying your website security just with a strong password is not the best option imho.

Ipstenu, sure there will be problems with some users, but again, if a user is not capable of memorizing an url like mydomain.com/newadmin must be banned from using computers or writing entries ??

Would you want those people in your house to begin with? What about in your garden?

Edit: Not sure this house analogy is quite right.

Of course not, but if they are there, i prefer to have my safe well hidden inside my house, rather than having the safe in the garden, or in the door, where anyone can access without problem.

If you have a safe (the admin directory) in your house. Would you like anyone that you have that and besides, where is located? Even if you have a strong password to open it?

Ah. The analogy is incomplete.

Say you have a house. You have a front door, right? Moving wp-admin is like moving the front door. It doesn’t necessarily give them access to the safe’s content, but it lets them in the house.

You don’t hide your door, you have a good lock (password).

Say you have a house. You have a front door, right? Moving wp-admin is like moving the front door. It doesn’t necessarily give them access to the safe’s content, but it lets them in the house.

You don’t hide your door, you have a good lock (password).

Well, for me, wordpress is the house. Then, i have a safe inside. But i don’t want to show publicly that i have a safe.

But ok, if all you think the best option is to show the access to the control of your website, then maybe is just me that im “paranoid”.

https://www.darkreading.com/attacks-and-breaches/wordpress-hackers-exploit-username-admin/d/d-id/1109538?

Who assures you this wont happen again? And with the same reason, if you have a very strong password of 60 chars with lower, upper, symbols etc… why to change “admin” name?

Lets rely all our security in one password.

And lets waste bandwitdh.

I am not here to argue the same a million times. I was just trying to point, that, with a different folder name, everything is harder for crackers and spammers.

And for sure a spammer trying to log waste more bandwidth than a spammer receiving a 404. Imagine when you are hitted by spammers hundreds of times every day. Its nonsense.

That’s a very good point. If there is an exploit in the admin login page, it can’t be exploited if the attacker doesn’t know the URL.

That’s why it is suggested for things like squirrelmail and phpMyAdmin to use a custom access directory.

And the hole doesn’t necessarily have to be a wordpress bug, it could be a php or apache bug.

I remember when OS X came out there was an apache bug with basic auth that only impacted users running it on an HFS+ filesystem. Anyone could bypass basic auth.

A bug that exploits the admin login page may not even be a flaw in wordpress.

Who assures you this wont happen again?

The person who creates the password has the responsibility to ensure it’s a good one.

Ok, then, your opinion is that all security you need in Internet is a good password. I already know that. Thanks.

If you have a 404 page that weights 1KB then every hit is going to waste 1KB.

If you have a regular wordpress login page, like mine, it will load jquery, css, images etc… 250kb approx. Then with the wrong login, it will load again. Another 250kb (maybe they use cache, maybe not). So it’s 500 times more bandwitdh.

Now lets imagine 1000 attempts per day: 500MB approx. 182 GB per year and for nothing. Not bad…

The person who creates the password has the responsibility to ensure it’s a good one.

But who ensures there won’t be another exploit where the password doesn’t matter, that can trigger the admin login page to authenticate regardless of password?

With the apache on OS X bug I mentioned, password didn’t matter. A web application that didn’t have any bugs but used apache basic authentication was vulnerable because of a bug the web application or the person setting the password had no control over.

But to exploit the bug, an attacker had to know the URL of the password protected area.

This has gotten kind of circular and really isn’t going anywhere. I don’t think I’ll convince either of you but for anyone else I just want to leave off with some points.

1. Security by obscurity does not work, it really doesn’t.

Here’s the thing: this is not security and I think you get that. This idea may mask people making bad decisions but that’s it. And then when their alternate login URL is discovered then… what? Rename the login location again?

2. Don’t connect your WordPress site with a 128K leased line. ??

The idea the bots will stop at 404 doesn’t really work either. Yes, you may save some miniscule bandwidth but if it ramps up to DoS levels then it doesn’t matter what the savings you may get. Your site would be down.

3. Hey, the software is good and gets/had gotten a lot of security scrutiny.

But who ensures there won’t be another exploit where the password doesn’t matter, that can trigger the admin login page to authenticate regardless of password?

…

But to exploit the bug, an attacker had to know the URL of the password protected area.

Now that’s a non-starter. ?? Because that applies to the whole of any software doesn’t it? Why stop with /wp-admin/ or any files? The complete source is available and does get looked at and often reported responsibly. The last patch that was released demonstrates that really well.

4. Patches get considered and trac is really the way to go.

If someone has a patch they’d like to field then please consider the links I posted above. I’ll repeat those though I may have missed one.

https://make.www.ads-software.com/core/handbook/working-with-trac/submitting-a-patch/

https://core.trac.www.ads-software.com/

I have not looked in trac (I myself don’t think this adds value) but this idea have been examined there already.

1. Security by obscurity does not work, it really doesn’t.

Security by obscurity is not a substitute for strong passwords and other secure measures, it is a tool that is used in addition to them. The less exposure, the less opportunity for an exploit to work.

Do you make the hashes to your passwords public? I should hope not. Even though you hopefully have strong passwords and are using an algorithm that has not been broken, you still do not want the hashes public. Public does not need to see them, so they are not made public.

Similarly, admin login is something the public does not need access to.

The idea the bots will stop at 404 doesn’t really work either.

Actually I’ve seen it. When they get a login failure is when they continue the brute force. Often from a different IP address, the URI to a login page is spread throughout the botnet. When there is a 404 you will still get probes looking to see if it is there, but you won’t get the brute force attacks.

3. Hey, the software is good and gets/had gotten a lot of security scrutiny.

No, WordPress has a lot of fundamental security flaws. They don’t want to fix many of them because they are afraid of breaking old moldy un-maintained yet frequently used plugins. That’s why for example the database manager still allows queries that are not secure from SQL injection and why they won’t get rid of the stupid magic quotes emulation.

WordPress allows inline scripts, making it more vulnerable to XSS attacks (you can’t use CSP if inline scripts are allowed)

WordPress encourages scripts in the body node – because it refuses to use something like DOMDocument that makes it easy to add scripts to the head after content has started to be generated. God forbid that libxml2 bindings be required.

WordPress encourages users to install it in such a way that the web server has write permission to directories within the web root. That’s how all those casino etc. worms spread – they find one vulnerable plugin, then insert themselves into other plugins because the web server has write permission to the install.

WordPress is not even close to being a secure product. It violates many standard security practices that were well known before WordPress existed.

WordPress is all about ease of installation and flashy features. That’s why I don’t use it myself and only set it up when someone who does use it needs me to write them a plugin. It is not a secure platform.

If wordpress would manage its update and plugin installation the same way as pear for php, tlmgr for texlive, cpan for perl, etc. you could have secure installation and updates without the web server needing write permission to what it executes and serves.

But wordpress does not want to work that way because security is not a major concern for the project.

https://www.cvedetails.com/cve/CVE-2014-9039/

That is where obscurity is beneficial.

They can’t pull that off if the admin login is not at a URL known to them.

Another real world example of security by obscurity is /etc/shadow

Before /etc/shadow a hacker could compromise accounts by running the password hashes in /etc/passwd against a rainbow table.

But /etc/shadow provides obscurity to the hashes.

Security by obscurity is not a substitute for other measures and should not be used as such, but it can be of benefit in addition to other measures.

We’re way off topic but there’s a lot of misconceptions in your replies.

No, WordPress has a lot of fundamental security flaws.

Nope, sorry incorrect. Give this a read, it may assist you and others in understanding.

https://wpengine.com/2013/05/08/wordpress-core-is-secure-stop-telling-people-otherwise/

That idea is just plain wrong. There are millions of installations and I don’t believe that Bad People? are refraining from hacking them because they suddenly developed a sense of moral responsibility.

That does not mean there is not code that will be determined to be vulnerable. It does mean that the obvious ones have been seen an addressed and new problems get dealt with when found. Quickly too.

WordPress is not even close to being a secure product. It violates many standard security practices that were well known before WordPress existed.

Incorrect again.

Any system that is extendable (in this case plugins and themes) allows the possibility of users installing code that is insecure or even malicious. That does not mean the core product is insecure by any accepted definition. It does mean that users can and do sometimes make amazingly poor decisions. Downloading and installing “FREE! PREMIUM! COMMERCIAL PRODUCTS!” is my current pet peeve and self-inflicted exploits are the worst.

But wordpress does not want to work that way because security is not a major concern for the project.

No, not true again. Security is taken very seriously and when those vulnerabilities are reported they are validated and addressed quickly.

https://codex.www.ads-software.com/Security_FAQ
https://codex.www.ads-software.com/Security_FAQ#Where_do_I_report_security_issues.3F

Security by obscurity-

Does not work and is 100% not accepted by any reputable IT security professional.

Frankly, the whole concept is a dog whistle that many react to. Including myself: I do not put any stock in that idea and never will.

No, WordPress has a lot of fundamental security flaws. They don’t want to fix many of them because they are afraid of breaking old moldy un-maintained yet frequently used plugins.

Nope. That’s a repeat item but I do wish you’d not ascribe negative intentions to the developers. It’s simply not true.

I don’t like how WordPress is designed.

You did not say that one, I am just being proactive. ??

But you do seem to have issues with design decisions and there’s a lot of hyperbole here.

The WordPress development cycle is very open and new people contribute all the time. If you have an idea and want to participate then see those links I posted above.

So you say that everything is perfect in WordPress?

I hope not. That would be uninteresting. (You didn’t write that one either.)

I’m saying that WordPress does keep security in mind for it’s development. It has to because as a leading platforms on the web exploitable code gets pounced upon when found.