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.
Currently Authentication Method implementations are provided for OAuth2 and Basic Auth.
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.
- 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
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.
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
Users can set a PIN code to control access to the app.
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.
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.
(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.