Create :ip_address, :ip_address_hash and :ip_address_encrypted Fields

[nelsonic]

According to EU GDPR, an Internet Protocol (IP) address is an example of "personal data": https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-personal-data_en

In some cases people have _fixed_IPV4 address (or long leases) which means they are uniquely identified by their IP for a long time.

From an individual "user" (person using our App/API) perspective, we need to make effort to encrypt or hash their IP address when storing it for session purposes.

Equally, if we are building an API-based app where other servers will connect to our service, their IP address will be static in many cases and often "whitelisted" for higher request volume.

We envisage the following 3 scenarios/requirements:

• [x] :ip_address - store IP Address in plaintext for speed (no hashing/encryption step) on a load balancer where we will store no other personally identifiable information. This is purely for checking the volume of requests from IP addresses to confirm that we are not being "attacked". A normal application should not use this field unless they are taking other measures to protect data.
• [x] ip_address_hash - hashing IP addresses is useful when we want to confirm that a request came from the same computer¹
• [x] ip_address_encrypted - useful where we need to store IP addresses in an encrypted form for security/privacy but still want the ability to decrypt them for forensics purposes. (e.g: to understand when a "bad actor" preformed an action on an account, what was the IP² ?)

All three of these share a common validation function:

• [x] Create a Fields.validate_ip_address/1 function that validates both IP v4 and IP v6 addresses using a standards-complaint RegEx:
  • https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
  • https://stackoverflow.com/questions/53497/regular-expression-that-matches-valid-ipv6-addresses

Note: I question if validating an IP address for each HTTP request is a useful exercise or if it's simply consuming compute cycles without any appreciable security benefit ... Please share your thoughts on this below if you feel that validating IP addresses which can be "spoofed" by an attacker is worthwhile or not! My instinct is to create the function and build "proactively defensive security", and then if we see a performance bottleneck in our app or a person using Fields complains that it's "slow", we can refactor or create a "no_verify" configuration option ... 🤔

¹ We are fully aware that it's relatively easy to "spoof" an IP address so we will not rely on this for transaction-type requests, but if the requestor has the same browser/device, IP address and request token, we will generally accept the request. When higher stakes are involved we will require an OTP sent via generated by an "Authenticator" App to be included with the request. See: https://github.com/dwyl/auth/issues/33

² Knowing a malicious user's IP address is of little use if they are minimally sophisticated and are using a VPN to mask their IP. 🙄 But for argument's sake, let's say that the VPN has a static IP (or range) we can at least use that in forensics. E.g: if many requests for auth are coming from the same IP address we can temporarily block it. And being able to decrypt and see what that IP address is will help us investigate if it merits a permanent block on our load balancer.

[nelsonic]

@SimonLab please estimate how long you think this will take to complete (apply a label) and then get on the case as we need this for Auth. https://github.com/dwyl/auth/pull/77/files#r429267428

Note: I'm not going to "block" the PR that is in-review but it would be really good to get this into Auth ASAP so we are not storing IP addresses as plaintext and we have some validation on the IPs. 👍

[nelsonic]

https://hex.pm/packages/fields/2.6.0 contains the new fields. 🚀 Thanks again @SimonLab ☀️