Security is a vital requirement for any registration system, but Regpack goes above and beyond to make sure your applicants data is safe.
That said, questions will inevitably come from your applicants, so we created the FAQ below! If your question isn't answered here, please reach out to the support team at email@example.com
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. 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. 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.
Regpack Security Details
Below is a summary of the security protocols that are in place to protect the information held within Regpack’s digital architecture:
- Our servers are behind a physical firewall that is managed by a dedicated external security team. It is configured on an "is allowed" basis meaning access is denied unless specifically approved.
- Regpack uses a split database mechanism in which key and values are separate from one another. This mechanism creates a low level internal encryption of the data and masks the type of data being pushed across servers.
- Our servers are encrypted at the disk level.
- All sensitive values in the databases are encrypted with a unique key per user. This prevents the view/use the information unless the key, algorithm connected to the specific project, user, server, and time of encryption are all present. The application automatically determines according to a set of variables which units are considered sensitive values.
- Regpack has the best in class WAF (web application firewall) that filters all possible DB attacks at the transmission level. This prevents the ability to access the database through the application. In addition, the system limits the amount of data that is transferred with every request and per IP to prevent the ability to access mass amounts of information.
- Regpack has regular code audits to make sure all code is written with security as a primary objective. All of our code is done by an internal team. Our code review protocols prevents any release into production unless it passes all of our security guidelines.
- Regpack uses the services of Rackspace Managed Security to perform hourly scans to all code, databases, and servers. In addition to the automated scan, our servers are manually reviewed to confirm the integrity of all server elements on a daily basis. Penetration testing is performed on a weekly basis.
- Regpack is PCI compliant level 2 and has passed all audits, since 2010, on the first scan. Our entire system is scanned on a weekly basis through a PCI checking mechanism. In addition, there is a monthly scan done by the PCI compliance approval entity.