IP Authentication: the good, the bad, the future

At work I usually work on applications which will be used by groups of users. Groups like companies, university libraries and so on.

These groups are usually tied to a geographical location or at least a specific network, so a useful feature of the applications they use is IP authentication.

Why would a company want to use IP authentication? The good points are:

  • They have their own network (VPN included) and they want easier authentication. You usually need only a username and to have the right IP address for this to work.
  • They want increased security: Restricting use of their account to specific IP addresses.
  • The service they provide is based on geographical/network location: This is true for libraries mostly but also for companies. Everyone who is at a computer in the university’s library has access to the online services the library has subscribed to.
    • Also, increased security: The users don’t need to be given any passwords or other kind of access. They just need to be physically present in the library and they have access. They also cannot steal or pass any passwords to someone else.
    • Less management overhead for the institution: They don’t need a username/password for every person, they don’t need to check every person. If someone is in the library/company they are presumed to be trusted already, checked by some physical security checks.
  • Transparent for the user.
  • Similarly to security tokens, it’s authentication by something you have (the IP in this case), usually more secure then authentication by something you know or who you are. An IP also can’t be stolen as easily as a security token.

So of course there are a lot of advantages but also some bad disadvantages:

  • Not everybody has a static IP address/range.
  • Management overhead: Someone still needs to add/check the IP ranges for specific users. IPs (version 4) are not that user-friendly for non-technical people. Let’s not even think of IPv6 which just looks wrong (complicated) for a lot of people
  • IPv4 versus IPv6: At some point you will have to support both which means some development/testing effort. I know for example that I will have to change the code in my applications to correctly handle IPv6… but have others even tested with IPv6?
  • Good for large institutions: They usually have a large reserved IP block or a gateway with a static IP.
    • Bad for large institutions: They usually have a large reserved IP block or a gateway with a static IP => It’s a lot harder to filter users. If the whole university has the same IP block and you only want to allow access from the library it might not be as straightforward as you think. Same with a single gateway: you give access to some part of the company, you give access to all of it.
  • IP portability: If you have people working on the road they either have to connect to the company VPN (which might not always be possible) or do their work without access to the applications authenticated by IP. Bad luck for people using mobile internet devices and always connecting from different IPs.

The future will bring some changes in this area. The future will bring IPv6 as a requirement for all applications so people will re-evaluate IP authentication.

With IPv6 you will not need as much NAT and gateways isolating everything. Even internal computers will have their own IP addresses so limiting the access to certain users will be much easier.

Maybe some will even give up on IP authentication when they look at an IPv6 address and ask “what the f*ck is that?” and move to something more user-centric (well..user’s machine/browser centric) like SSL Client Certificate authentication.

I for one still like IP authentication because of the transparency for the user. But I would not force anybody to remember/manage lists of IP addresses.

My current idea: Make authentication by hostname. You don’t type an IP address in your browser so why should you when giving some user access to your application? Dynamic DNS services have been along for quite a while and with CNAME records you could have hostnames like “johndoe.salesteam.companyname.com” always pointing to the laptop of John from the sales department. And you don’t even need to know if he’s in the company, he’s at home or if he’s on the road using a mobile internet connection. And this still offers the ’something you have’ guarantee, since the domain (and thus any subdomains) will be owned and administered by the company.

One of the simplest and nicest authentication mechanisms based on hostname/dns I’ve seen is the XMPP(Jabber) Server Dialback protocol, check it out for a good read.

Leave a Reply