Is it a bad idea to bypass login wall for a specified IP address?

Question

I have a website that is available on the public internet. The website requires authenticated login before any of the content can be accessed.

I've been asked if I can remove the login wall for users on a single static IP (the organisation's office) to allow them to read the content. Login would still be required for any write operations.

This feels like a bad idea to me, but I'm struggling to come up with a concrete reason not to.

Auditing read access to the content isn't a concern for the client.

Ignoring the possibility that the IP address could change, are there any reasons why this is a bad idea? Are there any ways this could be exploited?

Answer 1

You don't have to worry about spoofing the IP from a different connection, because returned TCP packets would not make it to the attacker in that scenario.

So all you have to worry about is how easy it is for the attacker to make use of that IP:

• Is that IP shared between multiple computers in the office?
• Can that IP be used on WiFi? How well is the password kept when a visitor says 'can I use your WiFi'?
• Are all the computers with access to that IP well secured, and have competent users?

If the IP is not well kept, then you should ask

• In addition to IP, can you have a cookie stored on the single machine that is authorized?
  (i.e. a limited-use Remember Me feature)

I commend your client for not using the Remember Password feature as is so tempting to do.

Also, how secure is your content?

• What are the damages of the content being viewed by unauthorized persons?
• What type of attackers would be attracted to your content?

Answer 2

As others pointed out, IP spoofing alone is not a problem here since the threeway handshake for TCP will not complete.

BGP hijacking combined with IP spoofing could result into a somewhat theoretical attack here if you're using public addresses in your access-list. In that case the attacker would spoof the IP-address in the access-list so traffic is coming from the trusted IP, and he would insert routers in to the global BGP tables to reroute return traffic to his network. This way, a threeway TCP-handshake would be completed.

As I said, this is far from a common attack since it requires some additional skills and access to networks without proper route filtering, but it can be done. BGP Hijacks are not uncommon. Although most of them are accidents, BGP hijacks have been used for attacks.

So to finally answer your question: if you value your data, don't just trust a connection based on the source IP-address.

Answer 3

I'd say IP spoofing is pretty much on the table here. Nothing stops people which have access to the datacenter infrastructure (e.g. employees) to forge IP packets with the password-free address, and capture the reply by altering the router configuration, or connecting to the right spot and listening in promiscuous mode.

The OP is effectively giving access to the website to their hosting provider or anyone who would be able to hack the said provider.

Answer 4

As the other answers already has shown, it is possible to circumvent this security system. But it requires some effort. The next question is, what you are going to protect and what the easier access is worth and what is the cost when the protection is circumvented. Because you can expect it to be circumvented.

This protection is commonly used. For example in acedemia to allow read access to journals from within the university network. This allows easier access to the journal for professors and students. If 1% of the people accessing the journals are illegit, it is negligible. If 0.01% of the people accessing the PII of your customer data base are illegit, you have a big problem.

Answer 5

All answers above are excellent, but are technical. Using the security management as point of view, think about the information that you are protecting.

If NO authentication is required to read that information (in a public or private point of view), that means that you aren't interested in protecting it.

If is an office, more than one people have access to it, there are several security considerations that the office maybe don't even consider (firewall, no password/wep protected wifi, anyone can plug a device on the network), that means that you rely on a third party about the access of this piece of information.

Now you have to do the calculations, how much it will cost if this information goes to the wrong hands ? That worth users being able to access it without password ?

Let's create two scenarios:

1. This is an internal list of foods that the internal restaurant prepares aka menu.
2. This is a list of customers with their credit card data.

Obviously those two scenarios are extreme, each one in this own way. But the fight of usability vs security will last forever. I once received a request like "let the user log in, even if the password isn't correct, but almost correct". That because some CEO, who can't type his password right, get angry when the application reject this login attempt.

Make an analysis of all risks, costs, pro/cons, you don't have to accept them, if you think that it's too risky, bring that to your CEO/CISO, and let him decide for you, than there will be no blood on your hands when something bad happens. Plus, they usually have a different point of view and importance about the business.

Answer 6

Here's a bit of a tangent, but I think it's good advice - making security exceptions is often a slippery slope. You'd be wise to not disclose the existence of your little bypass to anyone who doesn't strictly need-to-know - or sooner or later you will have all sorts of requests to disable security on X/Y/Z, because you made an exception before and it didn't break anything!

I could just be pessimistic about users though. Rather than disabling the login on the server side, could they not install a password manager on their side? As a bonus it would allow them to use actually mathematically secure random passwords.

Answer 7

It's definitely a bad idea.

Following are the scenarios where it can fail:.

1. Does every employee in the organisation have login credentials? Are the other employees trustworthy? You should consider the possibility that the new employees can also download all the content and then distribute it to people who don't have login credentials.

2. If an employee leaves their laptop loitering around, anybody can read the content if the employee is connected to the VPN.

There can be further attacks possible based on the kind of implementation of the web application.

Answer 8

Looking at the IP address is just a different way of authentication. If it is a good or bad idea depends.

Doing that usually means going to a less secure mode of authentication. Using username and password you authenticate the end-user, while using the IP address you authenticate a network device (which many people can use). That increases the risk that goals of confidentiality are violated. That is because you open new attack vectors that can be used by an attacker (e.g. attackers or unauthorized employees inside the client's network can read content; mistakes in proxy configuration can expose content to public; cross-site scripting attacks may become more probable/practical; your CMS behind the wall is probably more susceptible to attacks; ...).

On the other hand you make accessing the data easier, which increases the level of availability (also a security goal) due to several aspects (e.g. cannot forget password; reduced risk of errors during authentication).

You also end up with increased user acceptance. Don't underestimate this point! Bored users tend to undermine your security by choosing weak passwords or similar human behaviour.

If your customer thinks the relation between increased risk to confidentiality and the advantages on the other hand is acceptable let him decide and take that risk. Switch to IP based authentication and work with a happy customer.