|
|
|
|
|
|
|
Learn more about Internet security:
Learn how easy it is for hackers to crack that password you think is so secure or the techniques they use to
break into online systems we recommend the following links on YouTube.
|
|
|
|
|
|
|
|
CloudFlare Security Overview: Click here
|
|
|
|
|
|
|
|
Defending against DDoS Attacks - Cloudflare: Click here
|
|
|
|
|
|
|
|
How NOT to Store Passwords! - Computerphile: Click here
|
|
|
|
|
|
|
|
Password Cracking - Computerphile: Click here
|
|
|
|
|
|
|
|
How to Choose a Password - Computerphile: Click here
|
|
|
|
|
|
|
|
Running an SQL Injection Attack - Computerphile: Click here
|
|
|
|
|
|
|
|
Cookie Stealing - Computerphile: Click here
|
|
|
|
|
|
|
|
Security is a huge concern with online systems and that's why we have spent an enormous
amount of time building security protocols into Community Builder. We meeet and in almost
every case exceed today's industry best security practices. Below is a list of a few of the
security protocols we have implemented into Community Builder.
1. Server firewall: A firewall with all ports closed except those that are absolutely required to run the
site is the only gateway to the actual web and database servers. This reduces the number of attack vectors to
the servers themselves to the absolute minimum.
2. HTTPS: All sites are secured with an HTTPS certificate so data is encrypted from the user's browser to the
web server and back to the user.
3. CloudFlare.com: The CloudFlare service (CloudFlare.com) is used to block inbound IP requests from sketchy
country's like China, Russia, North Korea, etc.
4. DDOS: The CloudeFlare (CloudFlare.com) service also helps prevent Distributed Denial of Service attacks.
5. Strong Password: Passwords must be strong. They must be at least 8 chars with numbers, letters, and symbols.
6. Five Minute Lockout: After 5 failed login attempts the account is locked for 5 minutes preventing brute force
attacks.
7. SHA512 password hashing: User passwords are NOT stored in the database. Only a SHA512 hash of the password
is stored. To make it even more secure, before hashing the password a random salt of random length is added to
the password in a random position before performing the SHA512 hash. Also the salt is not stored anywhere. This
also means that if a user forgets their password they can only request a link to reset their password. Once a
password reset is sent to their email they must click the link in the email which contains a unique key in the
url. The site verifies the key is the same one sent to the user. Once the key is verified they must also answer
one of the security questions they provided an answer for when they created their account. Only then can they
reset their password.
8. SQL injection attacks: To thwart these types of attacks almost all interactions with the database are
performed using stored procedures. This creates a separation between the actual SQL statement and the parameter
values. This means a hacker can never breach the barrier of these two and confuse the computer into mixing the
SQL code and the parameter values. For those few instances where dynamic SQL is used it is ALWAYS passed through
a sanitizing routine that removes unnecessary SQL key words as well as characters that could indicated that
malicious SQL or JavaScript code was injected.
9. XSS or Cross Site Scripting: To thwart Cross Site Scripting attacks (where a hacker attempts to get malicious
JavaScript code to run on your system) all user input is html encoded which converts any JavaScript characters
into the ASCII equivalent character strings which neutralizes the JavaScript from being able to run on the
system.
10. RSA Encryption of sensitive data: Sensitive user data such as (first name, last name, email address, phone
number, and address) are stored in the database as RSA encrypted data. So if a hacker ever breaches the server
and somehow manages to steal the data all they will be able to see of the user's sensitive data is encrypted
strings. The RSA encryption procedure uses a public and private key methodology. The public and private keys are
stored in a separate database on a different machine so there is a separation of concerns of the two data stores.
11. No Cookie Policy: We love Cookie monster but he would likely starve on Community Builder because we have no
cookies. To those who may be unaware cookies can represent a security threat in certain cases. Using XSS (cross
site scripting attacks) hackers can steal your cookies and use them in a variety of malicious ways. Community
Builder does NOT use cookies... at all...period! This thwarts any possible attack vectors that use cookies since
there are none to steal...at all...period!
12. Two Factor Authentication: Two factor login authentication using Google Authenticator will be available soon.
|
