ChoreScout Security Paper
Moroku sells its products and services to financial services companies world-wide and operate them As A Service. Extensive experience of the executive team in implementing secure solutions for banks as well as some of the UK and Europe’s earliest strong cryptographic systems have given the team a very solid understanding of what is required in this space.
We keep this up to date through continual research and reading. A given for us is that security cannot be ‘bolted on’ but must be designed in from the outset of a project.
This document describes some key patterns and principles that Moroku employs across a range of solutions and operations.
General Security Architecture and Principles
Moroku provides cloud-based server applications which are accessible either via web browsers or dedicated mobile applications. The following general principles apply to all our products:
- Do not trust the client: We expect that a client application, be it mobile or browser based, can be compromised to some degree.This means that we should not blindly trust traffic from a client.All data must be validated at the server and no assumptions made about the trustworthiness of the client.
- Secure communications to the server: We expect that our clients will always use TLS to communicate with our servers. We are currently assessing the impact of rolling out HSTS
- All sensitive data encrypted: On the server,any data which may be regarded as sensitive is encrypted.
- Separate privileges: Where systems provide user and administrative interfaces, these are secured separately, access tokens for the systems are distinct and not interoperable. In many cases the administrative host is a distinct host from the application host.
- Avoid security through obscurity: We will never, ever, invent our own security protocols. We will instead rely on proven, tested, public protocols. The security architecture of our applications are made publicly available in many cases. Our applications are secured by design.
- Minimise PI collection: We aim not to store personally identifiable information as far as is possible. This makes it a lot easier to sell to banks but also reduces the value of attacking our systems.
- Strength in Depth: We do not assume that a single measure will protect our systems. Multiple layers of security are implemented. If one layer does not prevent a vulnerability, the next layer of defence should.
Moroku provides public APIs to the GameSystem and ChoreScout servers which allow any third party to access them given an appropriate level of authentication. We serve APIs over TLS and authenticate using a shared secret and an authorisation token. API calls are protected using an HMAC as described below which also prevents replay attacks. This may appear to be overkill but we prefer strength in depth as noted above.
Storage of Sensitive Data
Moroku relies on Ruby on Rails’ Active Record to persist data to a PostgreSQL database. We use the https://github.com/attr-encrypted/attr_encrypted gem to encrypt sensitive fields. This uses AES 256 GCM with per attribute IV and salts for all data.
Source Code Audits
Mobile applications are subjected to static analysis of source code. This is currently manual rather than part of a deployment pipeline but since deployments are manual it can still be executed per release.
We use Brakeman for Ruby on Rails apps. Brakeman is used by the likes of Twitter (where Justin Collins – the author – is employed), GitHub, and Groupon to look for vulnerabilities.
Moroku use Checkmarx for Android and iOS static analysis.
Moroku tracks the OWASP top ten (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2017_Release_Candidate) and actively check that we are not vulnerable in these ways.
Moroku use Burp Suite from Portswigger (https://portswigger.net/burp/freedownload/) to test this internally and commission penetration tests of their server platforms to get third party validation that they are secure.
Mobile App Data Security
Sometimes we need to store sensitive data on our mobile apps. This includes API keys, shared secrets, PINs etc. In this case we rely on the well tested built in security models of the devices which means using the Keychain on iOS devices and a keystore (with PBE) on Android devices.
Chore Scout Registration
Moroku creates an identity for each parent on the Chore Scout Server, once they have authenticated themselves as bank users. Each user registers an email address and a password . This email address is verified by sending them an email with a link to click, validating that the email was entered correctly. Once verified the user is requested to login to Chore Scout, via the application and a new session token is created. Subsequent transactions are authenticated using this token that cannot be replicated.
All Chore Scout branding is replaced by the bank or credit union’s branding.