Fetching contributors…
Cannot retrieve contributors at this time
87 lines (59 sloc) 6.09 KB



This document provides an overview over security considerations and features in the ownCloud iOS SDK (2018) and ownCloud iOS App (2018).



A general-purpose API for implementing passphrase- and token-based Authentication Methods:

  • structurally ensures separation of code between general connection-handling and authentication
  • simplifies code review by limiting each implementation to one class each (f.ex. OAuth2, BasicAuth)
  • ensures extensibility


Authentication Secrets contain information such as usernames, passwords or tokens and are generated by the respective Authentication Method implementation.

Authentication Secrets are securely stored in the app's Keychain and tagged as AccessibleAfterFirstUnlock, so they cannot be accessed after a restart until the device has been unlocked once by the user.

Supported methods

Currently Authentication Method implementations are provided for OAuth2 and Basic Auth.

Method selection

After performing auto-detection, found Authentication Methods are filtered and ranked by preference. The method with the highest ranking is then picked for the user.

By default, all detected methods are considered and OAuth2 ranks higher than Basic Auth.

Filtering and ranking can be customized by MDM Configuration. This, for example, allows making OAuth2 the only possible Authentication Method, so no credentials need to be stored on the device.

OAuth2 implementation

The OAuth2 implementation uses SFAuthenticationSession, which is described as best practice by RFC 8252. Benefits of using SFAuthenticationSession include:

  • privilege separation: web content is run in a separate process
  • trustworthiness: apps can't inject code into or access the contents of the web view
  • convenience for the user: cookies from Safari are available to the web content inside the session


URL limits

Using MDM Configuration, server URLs can be pre-filled or "hard-coded" as the only allowed server URL.


Redirects are not followed silently. Instead, they are reported to the user and must be explicitly approved.

SSL/TLS certificates

When adding servers, users have the opportunity to view a detailed summary of the server's SSL/TLS certificate before they are prompted for credentials or authentication via OAuth2.

If a SSL/TLS certificate fails trust evaluation (f.ex. because it's self-signed or signed by an unknown Certificate Authority), the user is given an opportunity to view a detailed summary of the certificate and subsequently prompted to approve or reject the certificate.

In case of redirects across several HTTPS servers, users are given the opportunity to review all certificates of all servers involved in addition to the redirects.

MDM Configuration support is planned for:

  • pre-approving specific certificates and certificates with specific public keys
  • allowing only connections with specific certificates or certificates with specific public keys



Separate directories are used for the data of every server connection:

  • strong barrier against data accidentally spilling between different connections
  • all data relating to a connection can be deleted by deleting the respective directory


The app uses the filesystem encryption built into iOS. Using the CompleteUntilFirstUserAuthentication file protection, data can't be accessed after a restart until the device has been unlocked once by the user.


The Sync Strategies planned to be used in the app focus on preventing data loss locally and remotely.

Secure Document View

HTML and Office document content is viewed in a WKWebView, which renders the content in a separate process. Additional hardening is achieved by disabling Javascript and blocking all network requests, protecting even against lesser known, non-obvious attacks like CSS Keylogging.

PIN code

Users can set a PIN code to control access to the app.


Continuous Integration

CI tests verify that central security mechanisms and assumptions work as expected, covering areas like redirections, certificate handling, common MITM attack scenarios and the secure storage of Authentication Secrets.

SQL Injection

To protect against SQL injection attacks, parameters are never made part of the SQL statements themselves. Instead, placeholders are used and the parameters are subsequently bound to the SQL statements.

So, for example, instead of SELECT * FROM users WHERE name='John Doe', the query would read SELECT * FROM users WHERE name=:nameToSearchFor.


The build script that created the OpenSSL binaries used in the app is available in the SDK's GitHub repository and can be used to reproduce the build result.

(OpenSSL is used solely to provide detailed summaries of SSL/TLS certificates - functionality that iOS is currently missing.)


When logging information, parts of the log message can be tagged as private. If Log Privacy is turned on (it will be by default), these parts will be replaced with «private» before the log message is written.