At Moula, protecting our customers’ data is a top priority. That’s why we undergo constant security audits and tests to ensure that the data you permission us into is completely secure. To give you a bit more insight on what and how we do this, as well as what industry security standards are, we’ll run through the various security measures we employ.
If your business handles customer data and want some tips, or you’re a customer yourself and want to know more about what exactly happens to your data when you send it off, then read on:
Website Data Security
Website security is such a huge subject that’s constantly changing as technologies evolve. The most important thing to recognise is that security measures have to be continually monitored, tested and upgraded – vigilance is the key. As well as ongoing penetration testing, Moula uses an external security company to audit our security measures and make recommendations.
In addition to this, all web traffic flowing to and from our website is protected by an SSL. A Secure Sockets Layer (SSL) is a way of authenticating and encrypting data and is an important thing to note for any web surfer. You can verify if a website uses SSL by looking at the address bar of your browser, which will show a padlock icon. In the case of high-level verification (EV), like that used by Moula, the address bar or text will also be displayed green.
When any customer (or ‘Browser’) attempts to access a website that is secured by SSL, the two establish a secure connection through a process called an “SSL Handshake”. This happens instantaneously and is basically invisible to the user when it happens. Basically, there are three “keys” that are used to set up the SSL connection: the website server’s public key, it’s private key and the session keys. Anything encrypted with the public key can only be decrypted with the private key and vice versa.
Because using the public and private keys to encrypt decrypt information takes A LOT of processing power, they are only used to create the session key during the SSL Handshake. After a secure connection is established, only the session key is then used to encrypt all flowing data.
- The Browser connects to a web server (Moula) that is secured with an SSL (https://) and requests the Server’s identity.
- The Server sends back a copy of its SSL Certificate to the Browser, along with the Server’s ‘public key’.
- The Browser then validates the SSL Certificate against a list of trusted Certified Authorities (CA’s). The Browser then creates, encrypts and sends back a symmetrical session key (using the server’s public key to encrypt).
- The Server decrypts the symmetric session key using its private key and then sends back an ‘acknowledgement’ (encrypted using the previous session key). This then starts the encrypted session.
- Finally, both the Server and the Browser use their session keys to encrypt all transmitted data.
Permissioning Personal and Business Data
SSL is a good place to start when assessing the credibility and legitimacy of a business’ website security. But what about when that website requests your personal or business data? Well, there are several industry standards around data permissioning and storage that a business needs to adhere to in order to safely collect customer data.
At Moula for example, a customer has a unique login on our website where they can access and manage any information relevant to their loan. However, when they’re ready to input their business data, customers are redirected to their own accounting portal (Xero, MYOB – or even their online banking feeds). This is where the portal will ask if the customer gives permission for Moula to look at their data. The permission can be revoked at any time, and at no point does Moula store any external usernames or passwords.
It is important for customers to be conscious of what data they are permissioning businesses into. At Moula, we can’t access any data that we’re not permissioned into by the customer. The range data we assess usually includes things like bank transactions, accounting data or online sales history – if we require any additional information (for larger loan applications for instance), we will ask customers to permission us into that extra data.
Most businesses use a third-party security portal to provide access to banking data. At Moula, we do this via our partner, Proviso, which has a secure, encrypted process for transferring data.
Open Authorization (OAuth)
One of the most frequent questions we get during the application process is around login credentials and passwords, particularly how we store them. Well, the answer is we don’t actually see them. All our authorization processes are done via OAuth (Open Authorization), which is an industry standard used by various companies, including Google, Facebook and Microsoft.
OAuth essentially allows a customer’s account information to be used by third parties (i.e. Moula) without actually exposing the customer’s passwords. Once the customer gives approval, OAuth issues an “access token” to the third party. The third party can then use this token to access the protected information hosted by the resource server (i.e. online accounting website).
- During the application process, the Applicant wants to supply Moula with their accounting and banking details.
- Moula then requests access to the banking or accounting Server where the applicant’s data is kept.
- The Server asks the Customer to authenticate the data request by logging in (via the server’s API).
- The Customer authenticates Moula’s request by entering their username and password into the Server’s API (Note: this is why we don’t see or store any login credentials – it’s all done through API log in screens.)
- The Server then issues an ‘Access Token’ to Moula, permissioning them into a selection of the Customer’s data.
- Moula and the Customer can now continue the application process with secure and legitimate accounting and banking data.
There is a difference between OAuth and a customer’s login. A good way to visualise this OAuth login process is by using a real-life example:
Take a business where employees gain access to the company building using ID cards. If an external guest needs to visit the business then they will need their own visitor’s access card. If the login is representative of the original employee accessing the building, then OAuth is representative of the guest receiving the visitor’s card and accessing the building:
- External Guest A (let’s say that’s Moula) says to the reception desk that they want to meet Employee B (the Customer) for business purposes.
- The Reception Desk (OAuth) notifies Employee B that Guest A has come to visit them.
- Employee B comes to the reception desk and identifies that Guest A is doing business with them.
- Employee B confirms and records both the business purpose and the identity of Guest A at the Reception Desk.
- The Reception Desk then issues a visitor card (Access Token) to Guest A.
- Employee B and Guest A go to a specified room to have their business meeting.
In this example, the ‘visitor card’ only allows guests access to pre-determined parts of the company building, whereas the ’employee ID card’ allows the employee access to everything. This basically how OAuth’s ‘access tokens’ work – they only allow clients access to parts of the customer’s data.
Hosting Customer Data
On the flip side, if your business collects and stores customer data, what should you do to ensure the security of that data? Aside from the technical steps we’ve already mentioned, there are more internal measures you can implement:
- Ensure that all software versions are up to date.
- Install anti-virus software on all business computers and keep up to date.
- Implement email spam filtering.
- Encrypt any sensitive data.
- Have workplace data security training.
- Ensure there isn’t just one route through which data can be accessed.
You also need to be vigilant when it comes to sharing data within your business. More and more cyber attacks are being conducted and small businesses, in particular, have become a more common target.
Email chains are one of the most important things to be conscious of. You never know what can be forwarded or who can later be attached to an email trail. Emailing also tends to produce multiple versions of documents/files that would be better protected if uploaded to a secure shared drive (including cloud drives).
One of the best methods to protect internal files and documents is to create accounts and manage permissions on shared storage drives such as Google Drive. This way you can avoid multiple people setting permissions on files and have a simple way to manage and revoke access.
Ideally, data should never be moved anywhere it doesn’t need to be. If you do need to share any data – can it be broken down in the form of a report or snippet? If you do need to send anything sensitive, always make sure you encrypt and always make sure you digitally file-shred when finished.
Finally, last but certainly not least: passwords. You have probably heard a million times the necessity of a strong password, and it is true. Algorithms can brute-force hack weak passwords so make sure you regularly change passwords and ensure those passwords are of sufficient strength. Using a combination of letters, numbers and symbols can help strengthen your passwords.
One method for keeping your passwords secure (and keeping track of them!) is to utilise a password manager. These managers create long, complicated and most importantly, strong passwords and keep track of them for you.