Safety recommendations


Several safety points have been brought to our attention when using ODK collect:

  • MD5 hashing algorithm, too unreliable
  • TAPJACKING PROTECTION ( android:filterTouchesWhenObscured="true")

Could you please indicate whether patches (or security upgrades) are planned for this purpose or whether they will be implemented in the near future. What are your recommandations in terms of security?

thank you in advance,


:wave: hey @Jean-Yves_Devaux. As this is your first time posting it'd be great if you could introduce yourself in this thread.

There is a write up on ODK security considerations in the docs here.

In terms of your bullet points: it would be interesting if you could clarify the "attacks" you're worried about. What would be compromised? How does someone compromise it? What could they do with it?

Thank you @seadowg for your answer.

in a few words to introduce myself :
I work for a publisher in the telecom sector.
We are located in france, vietnam, slovakia and slovakia.
We use the ODK solution to track information.

introduction :
web application firm suggesting ODK collect for visit report collection to one of our clients

In terms of your bullet points:
weak hashing algorithms (MD5) : "it can be vulnerable to collisions and other security weaknesses, and should not be used", feedback from our client security team
for tapjacking : client feedback is "When user touches the screen, application may pass the touch event to another application below its user interface layer that the user does not see, serving like a proxy to pass unintended touch activities. This attack is quite similar to clickjacking but for mobile devices." and they advise us to use android:filterTouchesWhenObscured="true"

they also alert us on temporary file creation and want to make sure it is deleted when they are no more required.
and last one is linked to raw SQL queries, "Inclusion of input into raw SQL queries can potentially lead to a local SQL injection vulnerability in the mobile application"

it is very precise feedback and we would likely get your expertise on these topics.

B. Regards

What particular us of MD5 is the team concerned about?

Seems like a valid concern. Would need some research but I could see this being added as long is it doesn't effect any existing features in the app.

Not quite clear on what this refers to. Would be great to have examples.

Makes sense as general advisory. Did the security team find any ways to inject SQL and cause problems?

I think as a general point here if you're having teams do security analysis on ODK tools it would be really helpful to share their reports and even better have them involved in discussion on this forum. That way there can be an understanding of what attacks the team is concerned about and there can be a community discussion around if that's something the app might be able to mitigate. I'd argue it's pretty much impossible for any team to guaruntee their codebase is immune to particular classes of attack but it's very possible for them to work with security teams to get to a place where everyone is confident that enough is in place that the app is "good enough" for a use case.

Bear in mind that Collect is a free, open source and available as-is/without warranty. As far as I've seen there isn't any form of ongoing security analysis or pen testing on the code base so could always use contributions from security people :grinning:


The concern is about using MD5 for cryptography purposes. Our team is currently checking some places in Collect app where MD5 is used, and assess that it is not used for cryptography.

In RFC 6151, the IETF suggestion is :

Where the MD5 checksum is used inline with the protocol
solely to protect against errors, an MD5 checksum is still an
acceptable use. Applications and protocols need to clearly state in
their security considerations what security services, if any, are
expected from the MD5 checksum. In fact, any application and
protocol that employs MD5 for any purpose needs to clearly state the
expected security services from their use of MD5.

1 Like

We only have a "not so much detailed" report from the security audit, probably resulting from an automated scan, but I will be happy to share it with you if there is an interest.

FYI, there is also a publicly available report on LGTM for ODK Collect : no SQL injection found there on latest check.


As far as I know that's correct!

Would be interesting! Are you able to share it here on the forum?

I had never seen this site before. Thanks for linking!

here are the conclusions of our team assessment :

For encryption, ODK Collect app implements the ODK XForms specification, and from the specification it's clear that MD5 is only used for computing digests for :

  • computing a seed value when building initialization vectors for AES encryption
  • computing signatures of encrypted records, which are themselves later AES encrypted before saving/sending
  • non-cryptographic checksums in other libraries

As written in specification, the sensitive content (XML file and uploaded files) are encrypted with AES/CFB/PKCS5


security audit.pdf (50.2 KB)

disclaimer : we don't necessarily share conclusions of this document, which is provided "as is"


Thanks so much for sharing! I'll have a look through and see if there is anything that we should raise as an issue on the Collect repo

1 Like

You're welcome.

We've also found an article that explores security and privacy attitudes, practices, and needs within organizations that use Open Data Kit (ODK) :

Cobb, Camille et al. 2016. “Computer Security for Data Collection Technologies.” In Proceedings of the Eighth International Conference on Information and Communication Technologies and Development - ICTD ’16, Ann Arbor, MI, USA: ACM Press, 1–11. (April 9, 2020).