In order to manage the Go.Learn mobile app, you need to keep a few technical and security requirements in mind. This article provides security notes and the answers to the most frequently asked questions about security in the Go.Learn app.
Security Notes for the App
- Data transmission is secured using the HTTPS protocol. While using a standard ECS solution, the certificate is issued by Go Daddy Secure Certificate Authority (opens in a new tab) and uses 2048-bit RSA cryptography together with SHA-256 hashing for data signature. Users are allowed to use their own certificates in the case of custom-named domains. HTTP protocol for custom domains is not supported on Go.Learn.
- The app access info is saved in the Keychain in secure mode, and it is accessible from the app only.
- Passwords are never saved locally.
- The offline login feature uses hashing functions to permit access.
- Courses, training material and asset data downloaded to play the content in offline mode is securely stored within the isolated storage. This data is not saved in the SD memory. Please note that you cannot access this content using another app.
- SSO tokens are never saved within the context of the GoLearn app. SSO tokens are immediately converted into HTTPS access keys, then destroyed and removed from the device memory.
- Refer to the Go.Learn Permissions table (PDF, 25KB) to know which permissions are required by the Go.Learn mobile app.
Security Questions & Answers
This section is a collection of the most frequently asked questions about security in the Go.Learn app. In case your Information Security Officer needs more detailed documentation, you as the Superadmin can contact Docebo via the Help Center or through your Account Manager if your plan includes this option.
Which programming language and/or framework was used to create the application?
The app relies on many external third parties libraries, but they are not up-to-date with the latest version. Why?
As for the updates of the libraries, it's an operation that is partially out of Docebo's control. In the context of React Native apps, you cannot control directly the dependencies of an app, you can simply choose the packages you want to add to your app using RNPM (React Native Package Manager), then the package manager decides which libraries (and versions) will be included into the app according to the packages you use in such a way to prevent conflicts.
Is the app protected by any code tampering prevention technique?
Yes, the Android app is protected by ProGuard, while the iOS app is implicitly protected by its environment.
Does the app implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc.)?
The app doesn’t access any of these services, so it doesn't even ask for the required permissions to access such resources.
How do data handling practices work? Which data may be collected through the app and how may it be used?
The Docebo mobile app is an integral part of the Docebo platform solution, and as such it is compliant with the practices described in Docebo Data Processes Addendum (PDF, 255KB).
Is user authentication required?
Yes, of course.
How does the user authenticate?
Username and password are required, or as an alternative, Single Sign-On (SSO) is supported.
Are any passwords being stored on the client?
No, absolutely not. Even in the case of the offline login, the app saves the irreversible SHA256 of the password.
Is the encryption key derived — even if securely — from the user's login credentials?
No, absolutely not.
Does the application store user credentials? If so, how are they stored? How does the application store session keys, passwords, device enrollment data, etc.?
The application never saves passwords locally. All the other sensitive data are stored in the system keychain.
What would an attacker be able to do if they got the user’s credentials?
An attacker could use the access key to make API calls, log into the platform, download training material, take courses.