Thread

I’m about to start working on a site where users will have to enter personal account information and credit card info into a form. This info will then be exported as either xml or csv, and imported into the client’s custom management software (this software has nothing to do with the website, I’m just using EE to collect the information).

My thought was to use EE’s membership module (or perhaps Solspace’s User module) and add a bunch of custom fields for the account and credit info, but I’m concerned about security. Is there a way to collect this info securely and to encrypt the sensitive data? Also, what would be the most secure way to get the data out on the back end? I was thinking of the CSVee plugin, but again, I’m concerned with security. I’ve never set anything up like this before (SSL, encryption, sensitive data, etc.), so any help/suggestions would be greatly appreciated.

aircrash, you might like to review this thread in the general forum - I would not recommend this course of action, based on that information.

Thanks, that’s kind of what I was thinking. The credit card is optional anyway, and the client could probably be persuaded not to collect it, but I still need to collect other account info that will need to be secured.

The way their site is currently set up, the data is encrypted and stored in a db, and then every night it is collected (supposedly securely - I don’t know the details) and transferred to their back-end system for processing, and the db info is deleted. They are concerned about the security of this method, and are looking for alternatives.

Ok, true internet security is a multi-layered issue, not usually very friendly to non-programmers or security novices. The little I’ve done, it’s been tricky to feel good about.

What you need:

1. HTTPS and POST operations for all posted forms with the sensitive data (check your host to see if they provide domain-specific certificates)
2. MySQL encryption is a specialty setup in most cases, so you must ask your provider if they support it; use PHP OpenSSL instead (preferable, or the mcrypt library if available)
3. Use AES encryption (look down at Other Languages, bottom of the page)

Beware of encode(), base64(), sha1(), md5/md3(), and crypt(); those are NOT very useful for what you’re doing. For AES, you will preferably like a 128-bit level encryption, but higher is better; 256 is a good standard.

EDIT: Ingmar’s comment below is accurate re: 128 being sufficient for nearly all needs. However, I believe MySQL data encryption needs to be carefully thought out and tested, especially if the database server is on another machine and cannot be called and delivered data through a secure port/tunnel. Localhost setups are usually sufficient, though. Still check to make sure AES function are available in your setup, as well.

Understanding what is happening and the way that it all works, in the end, is the hard part. Encrypting information is only one link in a chain of necessary steps.

I got started some years ago with this book (examples are in Java, but the concepts are the important part):

Web Services Security

Really, though, if you’re trying to actually secure data you’re putting in a server (personal information), and the job requires it, you need to get someone experienced in doing this, someone with solid references. This is not a plug for yours truly; to be honest, I’d not take on the hassle. I just don’t do it too often.

😉

Web security (encryption, transmission, confidentiality, validation, verification, veracity) is not “easy”; in most cases, people have to remodel their thinking just to figure out what’s going on, and the planning is complicated. You’re probably better off hiring a security consultant to hold your hand, or reading extensively on AES encryption/decryption using public/private keys.

There’s a lot of places where transmission and storage security can break down. Also, storing credit cards locally is probably a bad idea, but sending it without proper security protocols to another server can be just as problematic.

Interestingly, leaving a note for people to call a phone number with their credit information may lead to a significant security breakdown, using a really simple social engineering attack vector: Someone hacks the page with the phone number and changes it to another that calls them instead, where the clients happily hand it over.

Simple, effective. Weak FTP password security leads to a novel side-channel attack. Hmm…

No amount of encryption will save that scenario from happening; encryption is only one significant part of many significant parts. Not saying that’s likely, but you should get the idea that security is a matter of limiting or possibly mostly eliminating (like using HTTPS) known weaknesses along the roundtrip, as you can never rid yourself of all weaknesses altogether.

In financial controls, there is a phrase for that concept: Reasonable assurance.

Beware of people who claim absolute assurance, as that’s snake oil. To read more on this, check out Bruce Schneier:

http://www.schneier.com/
Snake Oil

At least read the snake-oil article. 😊

Security is, essentially, only reasonable in execution. The only secure bit of data anywhere is the bit that *no one* can decrypt. If that were rational, it would be really, really simple, and 100% effective.

And completely useless to mere mortals. 😉

The hard part about web security is proving it’s working, and that you don’t break it over time or think it’s working, only to accidentally publish your private key, for instance. This is why experience is useful. Chances are, you’re fine with the member data not being encrypted, unless the client demands it, in which case they should foot the cost of a reputable consultant.

PS: Subscribe to Bruce Schneier’s Crypto-Gram newsletter. Very entertaining, very challenging to common security understanding and orthodoxy (I love the movie-plot threats stuff he does), and he’s a great writer, so it’s not over most people’s heads, no matter your background.

Woha, thanks for all of that. I’m definitely going to look at having someone else handle this part of the job.

It’s important to tune the amount of security allocated (read: cost) to the relative value of the data under protection.

Consider: If company X spends $5000 dollars on project security, if the data they’re protecting can be had with a simple $20 query to a data collection service, maybe the data security cost is imbalanced to the true value of the information that is derived from the data under protection.

Economics of Information Security

Strong cryptography is very powerful when it is done right, but it is not a panacea. Focusing on the cryptographic algorithms while ignoring other aspects of security is like defending your house not by building a fence around it, but by putting an immense stake into the ground and hoping that the adversary runs right into it. Smart attackers will just go around the algorithms.
 
http://www.schneier.com/essay-028.html

Conversely, if they spend $5000 dollars on a security consultant to configure an encryption protocol for data storage, while their database admin is stealing the data with superuser access to the files and keys, no amount of encryption will prevent that superusers access. They should spend more on background checks and less on encryption toolkits, and flavor to taste.

It takes analysis to get there, though, and a working over of all the risks that need planning for, and the relative costs and risk-cost balance trade offs (risk appetite). This is what the consultant should do; he should advise on where to best put the resources for the most likely attack vectors according to Likelihood, Impact, and Effectiveness of Controls for that area, after doing a drilldown using a holistic approach to risk management.

Don’t hire an “encryption consultant.” Hire a security consultant, one who’s interested in the entire ‘chilada, not just a specific field they might feel comfortable with. And if the company only has X to spend, that needs to be spelled out.

Chances are, the security needed is not anything beyond simple perimeter security (site/file system access password strengths and hardening to external attacks from site penetrations, for instance), and good script processing (like EE provides, where you wash all submitted data). This is trivial stuff to understand, but it pays off. Just doing these things are often the hard part.

The more novel an attack vector, though, the more likely it is to be costly to control and monitor effectiveness (which provides reasonable assuredness), and the less that control is to be truly effective without significant time and investment from pre-production to deployment. Most small to medium companies can’t afford this process, and truthfully, most don’t really need it, if they’re careful in their planning.

Safe practices (like not storing data someone wants to steal, for instance, like credit/bank account information, and not trusting submitted information) makes more sense, and is less costly to not only provide, but for users to understand.

Good luck. 😊

Is there a way to collect this info securely and to encrypt the sensitive data?

In principle, yes, but not without some custom coding. You can store data encrypted in the database, MySQL has two functions for that:

AES_ENCRYPT(string, password)
AES_DECRYPT(string, password)

Key management would be the principle issue here, of course.

The way their site is currently set up, the data is encrypted and stored in a db, and then every night it is collected (supposedly securely - I don’t know the details) and transferred to their back-end system for processing, and the db info is deleted.

That sounds good to me, actually.

OK, a few points.

MySQL encryption is a specialty setup in most cases, so you must ask your provider if they support it;

Encrypting the whole database, yes, but simply storing encrypted values in the database is painless, I’ve done it before.

I agree, AES is the way to go, but AES-128 is more than sufficient. Especially when it comes to cryptography, more == better does not always hold true. (And, hey, the NSA says 128bits is good enough for documents classified as “SECRET”, so it’s good enough for my data. 192bits = “TOP SECRET”, by the way.)

Encrypting information is only one link in a chain of necessary steps.

Quite so. Since you quote Schneier later on: “Security is a process”. And, yes, proper security is hard.

Thank you Ingmar. 😊