Security is a vital requirement for any registration system, but the Regpack system goes above and beyond to make sure your applicants data is safe. That said, questions will inevitably come from your applicants, so we’ll attempt to address them here in advance (these are actual questions below – we get some good ones!).
“But your website is not HTTPS, how could it possibly be secure?”
Often, applicants will mistake the security of your website for the security of Regpack, so first let’s review the difference. Regpack provides you with an iframe code which you embed onto your website. This provides applicants with a safe place on your website where they are able to enter in their important information, but it doesn’t confer our security to the entirety of your website (see “man in the middle” for more). Because of this, applicants will often look for the HTTPS designation in the URL bar of your site, and if they do not see it, will become concerned (rightly).
To address this concern, we’ll provide you with a template site that demonstrates the security of our iframe. To access it, make sure you are logged in and go to the project settings section under settings – then on the embedding tab, you’ll see your template link (feel free to add a logo). This let’s skeptical applicants verify our security for themselves, but rest assured – this security is the same security that is applied to the iframe embedded into your website!
“What if someone gets a “privileged network position” between the applicant and your registration site?
A man in the middle attack looks like:
your applicant’s computer -> bad guy’s computer -> your registration website
Although this is not something Regpack is not responsible for, it could happen if your site is not HTTPS
Technically this is correct, however a “man in the middle” attack demands extensive work -especially when dealing with a system as complicated as Regpack.
In order to do this, an attacker would need to completely copy the Regpack system in terms of appearance and functionality (to trick your applicants into thinking they had arrived). In addition, this type of attack is correct for *any* link on your site and not only an embedded iframe. If they have a link, a “man in the middle” can alter that link and send users to a totally different site that imitates the link they wanted to go to. Just to get a practical sense of how much of a threat this poses to your applicants, keep in mind that often banks don’t have their front-end marketing sites https certified.
That said, if this is something that concerns you, or your applicants are turned away by it, the resolution for this is turning your site into https with a certificate. This can be done through a number of online vendors (GoDaddy, for example), and tends to cost a few hundred dollars on the low range.
Again, technically a “man in the middle” attack is possible, but in order to pull it off the attacker will need to go through very extreme measures and will need to put in a lot of work. Imitating Regpack is not easy!
“How are my payments secured?”
More technically, the Regpack system functions on servers that are SSL 256 bit enabled. All information is processed through the SSL protocol in order to ensure that the data transferred cannot be viewed by a non-authorized third party.
The system has a split database mechanism where credit card information is not saved together with user information. Credit card details are saved on a PCI-1 compliant server that is accessible only through a secure API that demands a username, password and is available only to a selected number of IP addresses therefore ensuring the credit card data can be accessed only within the Regpack network together with the accessibility to our third party vendors.
The data is accessible only through the application itself thus ensuring that even if the database is compromised the credit card information is not. This mechanism also supports the idea of “no human eye” where sensitive information cannot be accessed and understood without the use of inner algorithms created in the system.
These algorithms are created on the fly according to the specific situation at hand which acts as an additional layer of security.