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?

  • 12
    The IP address can clearly be spoofed in the request, but I don't believe an attacker would be able to receive the response without some sort of network interception. Is that correct? – tommarshall Aug 24 '16 at 11:51
  • 5
    That is correct. TCP connections require two-way communication to operate. – George Bailey Aug 24 '16 at 11:57
  • 2
    Uhrm, if the access to that specific information is to be really restricted, then instead of using IP address the logins are better because this way any access can be audited. Otherwise there won't be option to see who was accessing what. If the IP address is still required to be whitelisted, then this could be extended to everyone else, so only whitelisted IPs can use the website. However if this can't be done, then everyone needs login since this is public website with many users. – Aria Aug 24 '16 at 12:01
  • 17
    An option you should probably pursue is to ask why they need the log in removed. The answer could reveal possible alternatives. – jpmc26 Aug 24 '16 at 20:43
  • 2
    At what level will you be granting/denying access? Reminds me of blog.ircmaxell.com/2012/11/anatomy-of-attack-how-i-hacked.html. – Bart Aug 25 '16 at 14:14

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?
  • 3
    Good answer: the fact that an office may well have vulnerable wifi or machines is a pretty slam-dunk reason, even without positing a MitM IP attack or BGP hijacking. Given that all three attacks are possible, there seems good reason why a static IP alone should not be considered sufficient. – Dewi Morgan Aug 24 '16 at 17:27
  • 2
    Also, how sure are you to keep this IP? I might be unlikely that the static IP is suddenly taken, but will they notify you when they change their IP or worse, go out of business? Or maybe sell it due to managed incompetence? Depending on the worth of your data, a good offer to an it-illiterate manager might shake up a few things. – Sebb Aug 24 '16 at 21:16
  • 2
    Indeed, if you do not have a competent IT person at the client's location then you would not be able to answer the first 3 questions of my post. As for going out of business, I assume they would stop paying the OP at that point and the service would be discontinued anyway. Certainly credential cleanup (including this IP address feature) is an important maintenance procedure when closing account access. – George Bailey Aug 24 '16 at 21:21
  • 3
    @DewiMorgan: In practice, it is difficult to perform arbitrary BGP hijacking without nation-state resources (or at least ISP resources). OP's threat model does not appear to be sophisticated enough to distinguish between nation-state actors and other adversaries, so it is unlikely they are actually secure against nation-state adversaries anyway. – Kevin Aug 25 '16 at 6:02
  • 5
    Maybe it goes without saying, but you don't mention "is the organisation's office the only office on that IP address, or are their neigbours and/or other clients of the ISP sharing it?" And even if that's OK now, it might not always be unless they have written down somewhere that the IP is theirs alone. – Steve Jessop Aug 25 '16 at 15:46

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.

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.

  • That's not just spoofing, that's full-on MitM or BGP hijacking. – Shadur Aug 27 '16 at 11:22
  • 1
    @Shadur The attacker doesn't need to do MitM, because the IP address is the only thing needed for authentication in this scenario. BGP hijacking is the right term here, thanks! – Dmitry Grigoryev Aug 27 '16 at 12:50

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.

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.

  • 1
    +1 for the story about the CEO who can't type his password right. [facepalm] – Simon East Aug 27 '16 at 21:34

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.

  • 2
    I think this is a little too much of a tangent. It looks like the OP is asking about technical security issues, not policy issues. – schroeder Aug 28 '16 at 20:16

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.

  • @billc.cn for point 3, there would be no point if all the requests had to be authenticated and the user attacker didn't have credentials/tokens etc. For point 1, the attack's motivation would be reduced if everyone needs authentication – Limit Aug 24 '16 at 12:10
  • @techraf even accessing the content requires you to authenticate – Limit Aug 24 '16 at 12:11
  • If some bit of code can be placed, then it can also be malware that hijacks a session that is already logged in. (Basically if code can be placed on the user's machine, then any web security discussion is pointless.) – billc.cn Aug 24 '16 at 12:14
  • Hi @Limit, thanks for your response. 1. In this scenario all of the users on the IP address currently already have access to the content via login, so I don't see how this is relevant to the IP address whitelisting. 2. This is true, but there's no VPN in this specific example, so a laptop would have to be on premises. 3. If there's malware in the network then that could detect login and do this already. Again, I don't see how this is relevant to the IP whitelisting. – tommarshall Aug 24 '16 at 12:17
  • Hi @tommarshall I edited my answer to answer your observation on the first point. And like others said, point 3 is not really valid here so I removed it. – Limit Aug 24 '16 at 12:24

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.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.