Knack prides itself on providing a range of security options that you can use to ensure that private information is protected and secure.
By following the best practices listed in this document, you will increase your app security and reduce the risk of a security breach. However, even the best security policies will fall short if they are not followed and/or implemented correctly. We strongly recommend that agent and administrator users be trained to follow the best practices and ensure a secure environment.
If you are ever in doubt about the security of your App, feel free to contact us directly. In the event of a suspected security breach, you should submit a ticket to us right away with any details on the matter you can provide, at firstname.lastname@example.org.
Alternatively, you can open a chat with us right from the Builder.
Planning and Monitoring App Security
Security starts with careful planning and is maintained through routine monitoring. In the following sections, we will highlight some key areas where you should take extra precaution to secure your data.
Understand the security requirements of your data
It is important to note that although most types of data are appropriate to store with Knack, there are certain types we do not recommend to store without taking the proper precautions first. These types of data are subject to additional liability, regulations and legal requirements:
Data subject to United States export control or trade embargo regulations
Social security numbers, driver’s license or other state ID card numbers
Financial account, credit card or debit card numbers
If the nature of your data requires heightened security measures, you should consider our HIPAA or Enterprise plans. These plans offer additional security and legal protections, and can also be customized to meet specific security requirements.
Additionally, we only recommend the storing of financial account, credit card or debit card numbers in a PCI compliant database. Knack is currently not PCI compliant, although this is something we are working towards and hope to be able to offer PCI compliant services in the future.
Encourage users to monitor their user account and data
Since your users are using the system on a regular basis, they can be the "canary in the coal mine" indicating when a hacker has just gained unauthorized access to your App. As an example, in order to secure future access, an intruder may add a new email address to an admin profile and initiate a password reset.
Educating your users to reach out when suspicious actions take place can help to secure your data. If their password all of a sudden stops working or if they see data changing that they didn’t do themselves are signs that something may need to be looked at further.
Keep an eye on the users that are logging into your apps and the user roles being assigned. This can go a long way to ensuring that those who have access to the data in your app are supposed to and elevated access isn’t granted to someone it shouldn’t belong to.
Redact or obfuscate sensitive data from support communications
To best help ensure that your sensitive data remains safe, we ask that you do not include sensitive data in any support communication sent into the Knack support team.
This includes things such as social security numbers, addresses, email addresses and other such sensitive information.
If you need to pass along a CSV file containing any sensitive data, remove any information that’s not relevant to the issue we’re helping to solve. If the issue does involve sensitive data, a CSV with fake or obfuscated data may be a possibility instead.
Routinely audit your Knack App
Routinely check your record data and security settings for signs of suspicious activity. We suggest that you make and follow a checklist once a month (or more frequently) to ensure that no mistakes have been made that may leave your system vulnerable.
Some areas to check include:
Review all forms and tasks that send notifications and check that they are notifying the correct people. See Email Your Users for more on this.
Take some data samples to ensure complete and accurate data is being entered and retained into your App. If on a Pro plan or above, checking the record history to ensure that all data is entered and maintained from the live app, is a good idea here.
Review all of your Live App pages and ensure that they are secured with proper logins and permissions.
Review your User Account records and ensure each user has the correct permissions.
Be Aware of Social Engineering
Be aware that hackers sometimes use social engineering techniques to pressure people into helping them out by giving them a password for an account.
In some cases, they do this by contacting customer service personnel during evenings or weekends when they suspect there are fewer senior staff working. They may even claim that there's been a security breach and that the password needs to be reset immediately to some new value that they provide.
Some hackers have tools that enable them to spoof email addresses to impersonate users from legitimate email domains. As a result, even what appears to be a legitimate email request from a user may not be from that actual address.
Anytime someone claims to be a user of your account, you should independently verify his or her identity by following internal procedures. If such procedures are not in place, consider creating some to help staff members protect data.
If in doubt, never provide any sensitive information or make account changes on someone else's behalf. Legitimate users should be able to reset their password or login to their account to retrieve information themselves.
We recommend that you educate your agents using your app about these types of security risks and also create a security policy that everyone can refer to if these incidents were to occur.
Securing User Access
The best way to keep your data secure is to secure your pages behind logins and practice good security tips when working with the users who can access your pages.
Always make sure to securely reset passwords
The recommended way for a user to reset a password themselves, is to click the "Forgot your Password?" link on the login screen of your App. This prompts the user to enter their valid email address, which will then trigger an email to be sent with a link to reset their password.
If you’re a Knack Builder admin trying to reset the password for your users, always make sure to reset their password using the ‘Reset Password’ functionality, and do not manually set a new password for them. This will also send the user an email with a link to reset their password themselves.
If you're using a third party single sign-on authentication system such as Google, Facebook, Twitter or have set up your own service using SAML or oAuth, passwords can be reset in a similar fashion through those services. Please check their support for more information on how to do so.
Increase password security for your users
Knack provides the ability to enable increased password security on our Pro plans or above. If you're on a HIPAA plan, some of these features will be enabled by default for your live-app logins.
For more information, see Enable Advanced Security below.
Additionally, validation rules can be added to any field, including the password field, if you’d like to create your own customized password validation.
Increasing the password requirements for users can help to prevent rogue users from guessing your users’ passwords and gaining unauthorized access to your data.
You should also educate your administrators, agents, and general users on how to select unique, secure passwords for their Knack or App account. In other words, they should use a password that they are not also using for other systems such as their Email, Google, and so on. In doing so, if another account is hacked and a password is discovered, the hacker's access will be limited to just that one account.
Limit the number of users with elevated access rights
One of the beautiful features of Knack is the ability to limit access to different user roles.
When building out your user roles, security best practices will want to be kept in mind. By utilizing Page Rules and connections, you can limit the data that’s displayed on a page to only those who have the rights to see that data, as well as only give edit/delete or creation permissions to certain user roles.
For example, you may want to display a listing of all schools to any user who logs in, but might only want to let a School Admin edit the school they belong to. By connecting the School to the School Admin, you can set up a view that shows Schools belonging to the logged-in user with links to edit those schools.
Page rules can then let you hide the full listing of schools without editing links for non-Admins and on the inverse, only show the listing of schools connected to the logged-in Admin with the ability to edit, when an Admin is logged in.
We also allow giving additional access to your Knack Builder, by granting Shared Builder privileges.
Shared Builders have access to parts of your App that regular users do not - your builder. For example, all of the security features described in this document, are available to be turned on/off also by your shared builders. By limiting the number of users who have this access, you also limit your risk by not allowing others to change security settings and also prevent unnecessary changes from being made.
Remotely authenticate users with single sign-on
In addition to the user authentication provided by Knack, you can also use single sign-on, which authenticates your users outside of your App. There are two types: social media single sign-on and advanced single sign-on.
Social media single sign-on gives additional login options that you can set up and provide for your customers' convenience. For example, you can make the Facebook, Google, and Twitter logins available on your App sign-in page(s). Your customers can then log in with either their Knack account or one of their social media accounts to gain access to pages in the App.
Advanced single sign-on is different than social media single sign-on. This method allows you to set up your own Single Sign-On provider that you might already be using with other third-party services. Enabling this option will allow your users to login with their Knack account of the custom provider you’ve set up.
Additionally, many identity providers allow the use of multi-factor authentication to further secure your services. By turning those features on with your identity provider, you can enable multi-factor authentication to your Knack App by making users only able to login with the SSO login link.
With some custom CSS, you can disable the Knack account login and force logging in via the SSO method. See Hide the login Form
All user management and authentication happen outside of your Knack App.
For more information about single sign-on, see the following:
Restrict access to records
There are multiple methods in Knack to ensure that each user is only able to access the records you intend.
One method for restricting access to records is by utilizing a search view with some advanced options enabled. By leveraging the field level settings in the search view, you can set Require to YES and set Match Type to EXACT so that way only users who have key pieces of information, will return results.
This requires a user to enter a value in the field AND match exactly the value that is stored in the database before the search results will be displayed. This works well in a scenario for accessing an invoice, for example, where the user is required to enter an account id and email address, both matching existing records exactly.
Additionally, you can limit which records a user logging into your live App will have access to by employing connections between your objects and your user roles and properly setting up your views. For example, you can have a user logging in as a Teacher, who can then only see the Students connected to the classes they teach. Or you can have an Agent log in and allow them to only see Contacts that they’re assigned to.
For more information, see Show Records Connected to the Logged-in User and Show Records Connected to the Logged-in User’s Company or Group
You can also use connections to limit the results that users have access to choose from when editing and creating new records in forms. For example, after a user selects a Company on a form, you might only want them to be able to choose from Employees at that company. By utilizing the ‘Show’ functionality on the connection field, you can do this pretty quickly.
For more information, see Showing Parent-Child Dropdowns in a Form
Always Use Unique & Individual User Logins
We at Knack suggest to never sharing user logins or passwords to the portal between your users, either for Builder or Live App access.
To keep the security of your data the most secure and best make use of our Record History logs included with Pro or higher plans, always make sure to grant unique access for your users. Otherwise, it can be hard to tell who exactly made a certain change if the need arises to investigate, and if one user becomes malicious, you can lock them out without interfering with other users' access.
Secure Your API
You can use the Knack REST API to extend the functionality of your App. However, when not done properly, this can potentially open up your data to those who it is not intended for.
If you’d like to use the API to extend your App, we strongly recommend that you follow secure coding best practices. A good reference for this is the Open Web Application Security Project (OWASP), but of course, you can always reach out to us at email@example.com with any questions!
Use the right tool for the job
This helps reduce the risk of data becoming exposed as it does not require the use of an API key. In addition to this, a view based call to a page behind a login will use a logged-in user’s token to authenticate the calls instead of the key. This allows you to isolate actions taken by this application and to revoke the user’s access if you suspect it is compromised.
For more information, see Using the API
Leveraging Knack Security Features
In addition to the above safeguards, you can also turn on additional security features for users in your live app to help prevent rogue access and keep user accounts secure.
Under our HIPAA plan, some of the following features will be enabled by default with some options to tweak as you see fit. Otherwise, these features are available to customers on the Pro plan and up but are turned off by default.
To help prevent brute force attacks in the live app, you can enable the features here. This will check when a user fails to log in, how many times they’ve tried, and if that exceeds the options set for the App, the user will become locked out for a specified period of time.
Additional options are available to allow users to unlock themselves by resetting their own password and in addition, an email can be sent to the user warning them of this.
By default, three failed logins within five minutes to the Builder will lock out your account. After waiting 15 minutes, or by resetting your password, will the account become unlocked. These are not options that can be changed.
Logs out users from the live app after a set timed period of inactivity has been met.
For all plans, the builder will automatically log you out after 15 minutes of inactivity, and this is unable to be changed.
As an additional security feature, a builder can enable IP blocking. This means that only users from the IP addresses that you manually add to your App are allowed to sign in to the live version of your application.
For more information about this feature, see Enabling IP Blocking
Minimum Password Requirements
Turning on options here will increase password requirements helping users create better, safer, password. All or none of the options can be enabled, but the more options chosen, the more secure the password will be.
The following options are available:
A minimum of 8 characters
No common words
At least 1 number
At least 1 special character
At least 1 lowercase character
At least 1 uppercase character
For all builder passwords, at minimum, the password must contain at least 8 characters and cannot contain any common words. This is not something that can be changed.
In order to make sure that your users are always directed towards the secured version of your Live App, we recommend leaving this on.
This makes sure that if a user is directed towards your app over the non-HTTPS protocol, that they’ll be directed there automatically.
Builder Two Factor Authentication
Two-Factor Authentication, or 2FA, is a two-step verification process that can be enabled to add an additional security level to your Knack account for Builder access. This means that after you login with your email and password, you will be required to enter an additional code to access your account.
You can read more about 2FA here.
You can read more about Knack Security features here: