ChoreScout Security Paper




Design Approach

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 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.

Pen testing

Moroku tracks the OWASP top ten ( and actively check that we are not vulnerable in these ways.

Moroku use Burp Suite from Portswigger ( 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.

1. FAQ

Where is the ChoreScout server?

ChoreScout is a cloud-based service hosted on Heroku, a platform which is in turn hosted on Amazon Web Services in the US.

Can we have a private cloud?

Yes. We are able to provide Heroku ‘private spaces’ instances for banking customers, at an additional setup and ongoing cost

What account data does Moroku store on the ChoreScout server?

Moroku does not store account data on the ChoreScout server. A cryptographically hashed version of the account number for each parent and child account is stored on the server but it is impossible to reverse engineer the actual account number from this information. For detailed information, please see the data architecture description in the second part of this document.

What financial data does Moroku store on the ChoreScout server?

For each child, Moroku stores the target value for their savings goal and the progress that they have made towards it. Moroku also stores the history of allowances paid to the child and what proportion of the allowance was spent vs saved.

What personal information is stored on the ChoreScout server?

Moroku does not store any data about the child other than the first name or nickname that the parent enters for them when they registered the child, e.g. Timmy. No age, gender, surname or other personal information is stored. The parent may opt to associate an image with the child which may be of the child in which case this image is stored on the server too. The parent is not required to provide an image.

Coming to personal data of the parent, ChoreScout server stores the email id which is used for registering the user in ChoreScout server.

How does ChoreScout integrate with core banking?

The ChoreScout child app does not integrate with the core banking platform at all. The ChoreScout Guardian app integrates with core banking using the same security infrastructure and APIs that the existing native mobile banking app uses.

What services does ChoreScout use on core banking?

The ChoreScout Guardian app. uses the existing security/authentication framework to register with core banking. It then retrieves a list of eligible accounts that is accounts from which the allowance can be paid and accounts to which the allowance can be paid. All accounts must be visible to the parent via e.g. internet banking.

When an allowance is to be paid, ChoreScout uses an existing API to request a transfer of funds from the parent’s account to the child’s account. The ChoreScout app cannot transfer to any account which is not visible to the parent on Internet Banking

How is data secured on the ChoreScout server?

The ChoreScout server is accessed via an API which is secured by TLS. TLS provides privacy while an additional layer of hashing at the message level.

What crypto function and strength is being used?

Hashing is done using SHA-256 before passing values with the TLS API. Values stored in device are securely saved within Android and iOS provided secure layers. Keychain for Apple and Keystore for Android follow latest industry security protocol when it comes to encryption and access rights are sandboxed to the application in concern.

Databases storing sensitive data are encrypted with keys stored in secure encrypted layers of the app. ChoreScout app pin, bank member id and temporary access tokens are some values that are stored locally using the secure layer. We do not store the internet banking password.

Is this stored in local memory only or can secure enclaves be utilised if available in hardware?

The sensitive data is all stored in secure enclaves provided by the platform. Android has Keystore and Apple provides keychain for this purpose.

Is data stored on servers salted/peppered? What other security steps are taken for this stored data?

We salt and hash Chore Scout passwords and account numbers. We do not store internet banking passwords

Who has access to these servers (ie login, root or otherwise)?

User login is possible through API and currently API is exposed only to ChoreScout apps. Each client gets their own sandboxed organisation access where in each user can only access their own data.

Admin access is available for the development team but all the sensitive data is encrypted using keys from the user’s device which cannot be reverse engineered.

Is there any kind of password recovery system?

There is a two step registration. ChoreScout registration followed by bank authorisation. The bank authorisation is managed by the core banking system so ChoreScout is not authorised to provide a password recovery system for internet banking login password. The ChoreScout server password is provided with a forgot password feature.

If so, how is this facilitated?

The ChoreScout server password is provided with a forgot password feature wherein the user can enter the email id to get a secure link for resetting the password. This can be done from the parent app alone. The child app does not need a password to login. It gets linked to the parent account’s corresponding child using a secure linking token.

Can someone login to the app on a different device and be able to retrieve credentials to authenticate with the bank?

No. Logging in to ChoreScout might give access to ChoreScout data but authenticating to bank is a necessary step of each app identification. This bank authorisation is independently done with the core banking system which is not accessible through the ChoreScout server.

Only the parent app can access the core banking system and none of the details for core banking authorisation is shared with the ChoreScout server. Without this identification the app will not clear the registration flow and app would be useless.

Is 2FA available for login?

2FA is available for the bank authorisation step and is configured based on bank’s security protocols. Post the bank authorisation login the security code is shared in whatever channel the bank communicates with their customers. The user can then share this code to be validated by the independent core banking server. None of this communication is ever shared or saved with the ChoreScout server or the app.

What version of TLS is being used?

We enforce a minimum TLS version of 1.1 but will use whatever the latest stable version supported by the client.

Define what kind of “native encryption” is used on the PostgreSQL database?

Encryption is only occurring for transit data via TLS and on the device. To get access to the PostgreSQL database you would need full admin access which in turn infers that you would have access to all the keys you needed to decrypt all the data.

On the app we use AES256 and SHA2 with 64 byte (512-bit) encryption key.

What redundancy measures are in place for data, and what security measures are taken for data at rest?

Moroku, like many small software businesses, rely on a number of cloud providers for source code management, runtime platforms, version control and defect management. Adopting this approach allows us to focus on our core differentiator; building great solutions, while outsourcing the scalability, availability and reliability of our systems (both internal and external) to expert vendors.

Having said that, large companies do go bankrupt and even big cloud vendors have outages and lose data so Moroku implement an additional layer of protections on top of the reliance on vendors.

Runtime Platforms

For details on Heroku’s customer commitment see

Moroku uses Heroku’s PostgreSQL database implementation for their production systems. Heroku says this about their deployment: On top of this, Moroku runs daily backups of production databases (via pgdump) which are downloaded and stored offline in the event of a critical failure they can be restored to any PostgreSQL instance whether at Heroku or elsewhere.

Source Code Management

Moroku uses Atlassian BitBucket as a hosted solution to manage their software repositories. BitBucket is a Git based system and as such it is possible to clone these repositories into any instance of Git (including e.g. GitHub or a local repository). In fact this is the way in which normal Git based development works.

For any work in progress, each developer on the project will have a full version of the repository on their computer. Pushing this source to a new repository is trivial and these repositories could be cloned and running within minutes.

Info on BitBucket cloud is here:

Primary DR Plan

In the event that Heroku suffer a catastrophic outage with total loss of data-centre/database, Moroku would aim to restore to IBM Bluemix.

IBM Offer a similar Ruby on Rails Build Pack and the Moroku developer team have migrated apps from Heroku to Bluemix and back again a number of times.

Moroku has a Bluemix account with access to the RoR buildpack.

The specific stages involved would be:

  • Provision a new production PostgreSQL instance via Bluemix
  • Restore the most recent pgdump backup from Heroku
  • Construct a new, bluemix deployment file containing the application settings from Heroku plus the new database specifications
  • Push the server application to Bluemix
  • Update DNS records on PointDNS to point to the new live version

When Moroku migrated its POS platform, Marrakash product from Heroku to Bluemix, the deployment took under 24 hours from a standing start and we believe that this is a reasonable amount of time given that :

  • Moroku’s systems are not business critical to their customers
  • An outage of the magnitude required to take out Heroku’s Amazon data-centres would likely have an adverse impact on our customers requiring them to prioritise the restoration of other, more important services.

The recovery time could be further reduced by having pre-prepared configuration files and performing test deployments periodically however at this time the risk/reward ratio of this compared to the opportunity cost of taking engineers off of product development does not make sense for Moroku.

What versions of OAuth do you support?

The ChoreScout server has capability to implement all existing OAuth standards, but these are not currently implemented.

Is the data stored on servers siloed by bank or otherwise separated? If so, by what means?

Please refer to the Chore Scout Architecture and Integration Paper

Are transfers in the app subject to the same restrictions as a standard bank transfer (ie cap on amount of funds able to be transferred per day), or is a lower limit set on these transfers?

Yes – this is managed outside of ChoreScout by the Core Banking system.

What data is stored on the parent’s phone and how is it protected ?

The parent’s phone stores a local cache of children ( first name, goal, payment history, pocket money details) as well as a cryptographically hashed account key for each child. It also stores the cryptographically hashed parent account key and a cache of chores.

All of the preceding data is stored in the phone’s conventional data storage. In addition to this, the phone stores account number and name for each bank account that is in use as well as whatever cryptographic tokens are needed to securely access the core banking platform (this various from platform to platform). These items are stored in hardware backed cryptographically secure storage on the phone. For iOS this means in the keychain. For Android, it is the hardware backed KeyStore.

What data is stored on the child’s phone and how is it protected?

The child’s phone stores a local cache of goal, payment history, pocket money details and chores. All of the preceding data is stored in the phone’s conventional data storage.

2. Security Architecture Overview

  • The account data are stored securely in the core banking platform and exposed to ChoreScout only via existing APIs and security infrastructure.
  • During registration, the Guardian app. Prompts the user for authentication details (vary depending on core banking platform but usually at least a member number and password). The ChoreScout app connects to the banking API, authenticates the user and registers this device. In return the banking API provides some form of secure token which can be used to access the API in future without requiring the member number/password to be entered again. The Guardian app also requests a list of accounts on which the parent has transacting capability.
  • The Guardian app stores the secure token and the account name/numbers in local cryptographically secure hardware storage. The parent is asked to nominate the account from which allowances will be paid. When the parent creates a new child, a similar process associates a bank account with the child.
  • The Guardian app registers the parent and any related children on the ChoreScout server. Account numbers are cryptographically hashed before being sent to the server where they function as unique account identifiers. The API for interacting with the server provides privacy via TLS. It is not possible for a parent to access data about a child which is not their own. Registration on the ChoreScout server takes place using the email id provided by user.
  • On the ChoreScout server, data is stored in PostgreSQL databases using native encryption for sensitive columns ( access tokens).
  • The child accesses the ChoreScout server via the same, TLS API.