2

I am working on a site that has an online health and safety course where you buy x number of serials to use. 1 serial per candidate. We don’t store credit card details and payments are processed securely by a third party. At the moment we do collect/store the address of any sign-up in a mysql database.

Even though it is still quite a new site with fairly limited budget I, as the developer, am trying to make the site as secure as possible. I would like to remove the address/telephone numbers from the database so if there was an intrusion there is less and less for the perpetrator to attempt to steal. We don’t need the address/tel stored in the db for any of the functions to work and as it is a digital product we don't need to send out to postal address. But we do want to keep the info and store locally if/when needed for marketing.

It's easy enough to remove the address/tel from the DB and update the payment process so these details are emailed instead to my client, who could then copy and paste all addresses as they arrive into a local spreadsheet and delete the email. But as I have read, it is taboo to send plain text passwords etc via email.

So, would it be acceptable to email 'addresses/telephone numbers' after payment in plain text which my client could promptly transfer to a local spreadsheet? Would this be considered more secure than storing such info in a database (which potentially could always be compromised)? Or is there some other method one would recommend in this situation?

4
  • 2
    Keeping the info on the client's machine (possibly full of malware) is much worse than on a properly secured server. And even if you still want to send the details off to the client, don't use e-mail - it is transmitted in plain text. Mar 9, 2017 at 16:33
  • In the grand scheme of PII, why are you concerned about storing addresses and phone numbers? In the US, this information is either part of the public record, commercially available through the credit bureaus or freely distributed anytime you sign up for literally anything. It's hardly a secret.
    – Ivan
    Mar 9, 2017 at 18:12
  • @Johnny he specified why he wanted to remove it, and it is a legitimate concern. Just because the data is public does not mean that the correlation of that public data to the fact that the person is a member of the site should be public (Ashley Madison, et al).
    – schroeder
    Mar 29, 2017 at 10:26
  • @schroeder Unless "online health and safety courses" are a euphemism for "escort services," that isn't applicable. If that level of discretion is required then he needs to ditch the marketing idea and just never store the data, period.
    – Ivan
    Mar 29, 2017 at 12:39

6 Answers 6

4

While I think it's great that you're trying to secure your application, I am wondering: You're trying to protect your users from a database breach, and you're worried about postal address and telephone number. Are these two items really the most important things to secure? Usually, if you have a firstname and lastname, you can get these two data points from a public phone book. This doesn't strike me as very valuable data, unless your service is trying to keep users anoymous (but then you should also remove a user's name and username from the database and just identify him by a random number).

What I do like is the idea to not store data you don't need at all. André is right about pointing out that mailing addresses to someone in plaintext isn't very secure either, but I do like the idea to move the data to the person that actually needs it, and then remove it from your posession. This means you can't be held responsible in the event of a data breach, because you simply don't have the data.

Three ideas

1) What you could do to solve your problem is to create a second database on a different host that basically just stored the personal information of your clients, and build a microservice around it to store and query adresses based on a user id.

This would isolate the address database from the rest of your application and add another layer of protection, but it still wouldn't really solve the problem, because an attacker which can gain access to your database will probably also be able to figure out how to query the remote address service.

2) You can get an almost equivalent amount of additional security by encrypting the addresses and phone numbers in your database. If an attacker just steals the database, he won't be able to do anything with the encrypted fields, but obviously, he could also steal the encryption key. There's no way around that if you want to store data and keep it accessible.

3) The third solution uses public key cryptography to protect the addresses and phone numbers: You encrypt the addresses and phone numbers on your server using a public key. You don't keep the private key on the server. Only the owner of the private key can then decrypt the encrypted data, and since the private key isn't available on the server, it means that an attacker can't get at data that's already encrypted (but he could install a routine to pick up the addresses and phone numbers of new customers before they get encrypted). The downside of this solution is that your application has no access to the encrypted data, either.

0

I agree with the comments by André and Pascal: the database is likely to be more secure than somebody's workstation. However, if you really want to retain the data in the organization but not have it on the database machine, here is another option:

  • Create a HTTPS webpage, secured by a good password on a good server.
  • Periodically, have your client go to that webpage.
  • His visiting the page will cause all the PII in the database to be written to a file that gets downloaded to his machine via the browser.
  • Following the download, the PII is wiped from the database.
  • This could be scripted via curl using bash-crontab (iOS/Linux) or Task Scheduler-PowerShell (Windows), so that he doesn't have to remember to do it.
  • The data is encrypted in motion via TLS-HTTPS, and then it is out of your hands.
2
  • I really want to remove the address/tel columns from the database altogether. I like the idea of the HTTPS page with secure login I am wondering would it be ok to instead of writing the PII to MySQL we instead write to and store a CSV file temporarily on server. The client then downloads the PII and has a check box to remove the CSV after download, would that be considered secure (as opposed to emailing in plain text)? Mar 10, 2017 at 12:38
  • @RobertSheppard That would definitely be better than emailing. The important thing is to secure the server and the web interface in all the usual ways. Mar 10, 2017 at 15:09
0

There are now a number of commercial products (relatively affordable) that can handle your exact situation.

Some solutions have column-level encryption coupled with column level access control and privilege management. That means that for each column in your DB you can define who can have access to it, who can encrypt/decrypt/ from what type of application/ and at what time. This could be much cheaper than having to develop a website just for this problem (human resources, time and maintenance cost).

1
  • but then you need to have db accounts for those who need access
    – schroeder
    Mar 29, 2017 at 10:29
0

My advice is to start with the two foundational questions (functionalities):

  • what will the data be used for?
  • what do you want to protect the data from?

The answer to the second question is easy: you want to protect them from theft if someone could get access to your system. That mean that ideally, it should be impossible to get them from the system that has stored them.

If I have correctly understood, the addresses/telephone numbers are not used by the application but for marketing. If that means that they will be used only occasionally an from a limited number of users, I think that the 3rd idea from Pascal is the best here:

  • you store the addresses and phone numbers in an auxiliary storage (server, database or at least a different table) - as they are short data, you can encrypt them directly with a public key
  • the private key is only accessible to the marketing application. Here as it does process personal information you will have to secure that part, but as you did not say much about it, I really cannot say more either - and IMHO it would be a different question

That way the application under you responsibility is perfectly secure, and you do not put additional constraints on the marketing part because as they use personal data they shall secure it anyway.

0

I agree with others here that while your aims are laudable, this information is of limited value. I also agree that the server is likely to be a safer place to store the information than someone's desktop PC - but we don't actually know anything about the client's infrastructure.

Given the relatively low sensitivity of the information and the usage model, I would go with giving the service account no read-write access to the tables holding this data, but instead to a stored procedure to apply writes - then provide an alternative UI where the client can supply the password for a MySQL account with read (and wrote?) access to these tables. i.e. good old-fashioned privilege separation.

The data is still exposed in the underlying data files (and backups) but avoids the complexity of code and processes around managing asymmetric keys.

-2

One thing you could do would be to encrypt the records with the user's password. I agree this isn't really a great option because of how short user passwords typically are, but hey, that's on them right?

2
  • 1
    But the "user" is not the person whom will be retrieving the data for use.
    – symcbean
    Mar 29, 2017 at 10:20
  • this suggestion breaks what the data needs to be used for
    – schroeder
    Mar 29, 2017 at 10:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .