6 Comments

  1. mrosco

    It is not surprising that Mozo is being discontinued.  When it was first announced, we were surprised that Awana was choosing to enter an arena that already had robust offerings to handle recordkeeping.  Now they can focus on what Awana does best:  curriculum and program.

  2. Brit

    I am an AWdb user and worked in software development for over 20 years. A lot of work is needed to bring a robust software to the market, both with respect to stability and features. I agree with the previous comment on the withdrawal of Mozo. We use the online version now, but did not switch before we felt it had reached stability and had the required features. Commander Bob’s recommendation at the very end is also well noting.

  3. Mark Sigsbee

    The most import question is their handling of sensitive information.  Have they had independent assessments performed on their applications to confirm that they are secure?

    We clubs cannot afford a lawsuit from spilled data and neither can the developer.

    I don’t see that addressed here.

  4. I think Mark raises an important point about security. Here is the information we provided for last year’s article when Commander Bill posed the question: “… What can you share about the measures you take to secure the data, Personally Identifiable Information (PII), stored by your users?”

    Answer:

    The legacy desktop version of AWdb uses a local database that has tables with PII data encrypted, so even if a club loses the USB flash drive or their laptop is stolen or hacked, the data files are inaccessible without their user name and password.

     

    The cloud version of AWdb is hosted on commercial grade servers located in a data center in Wisconsin.  I asked them about their security measures and they said “We employ a firewall in front of each of our clouds which will broadly block known vulnerabilities and networks known to originate attacks.  Also, when repeated failed attempts are made to login to the server, the IP addresses are blocked and the server is no longer reachable for these networks or IP addresses.”

     

    Regarding our software design, we have taken measures to mitigate risk of unauthorized access to each club’s data, and we follow established best practices:

    – To prevent JSON vulnerabilities: we only return objects, not arrays

    – To prevent Cross Site Request Forgery: we use Token Based Authentication

    – To prevent Cross Site Scripting: we use AngularJS which sanitizes untrusted data and we do not directly manipulate the DOM

    – To prevent SQL Injection: we use prepared statements and parameters in our SQL queries and escape all user input.

    – Our headers use the actual hostname and port of the client, we do not use wildcards

    – The communication between a user’s computer and our server is secured by employing the HTTPS protocol to encrypt the connection.

    – We require users to enter a unique Customer ID as well as a unique name and password consisting of at least 8 characters that must contain a number and a symbol.

    – We do not store all club data a single large database, instead we create and maintain a separate physical database for each church.

    – We pay our hosting provider to run regular managed backups and have a plan in place for recovering data in an emergency.

     

  5. Mark Sigsbee

    @Rick – thanks for your response. My concern with one data center is the single point of failure.  If that provider only has one ISP as their network provider and that network goes down clubs could be left hanging.  There are many small to mid-sized cloud hosting companies that are very eager for customers and have very competitive rates.

    I always encourage developers to have their system pen tested, especially when handling PII.  I am not bashful about asserting that you don’t ever want to be told that you spilled data. I’m sure you see enough about that in the news already.

    Thanks for your due diligence that you have outlined above. It’s very impressive!

Comments are closed.