Customer trust and data security are critical to everything we do at Studo. We go to considerable lengths to ensure that data is handled safely. Offering secure and reliable services is fundamental to us. 

We want to share some of the details of what we do to keep things secure and some of the work that we’re doing to continuously improve the security of the Studo App and the Studo infrastructure. The following overview includes details outlining how we continually prioritize security at Studo to ensure trust for our users.

Pentests, Vulnerability Scanning and Bug Bounty Program

Studo uses third party security tools to continuously scan for vulnerabilities. Our team responds to issues raised. External partners who studied at the leading security institutes in Europe regularly perform detailed penetration tests and code-audits on the Studo infrastructure and Studo App to resolve potential issues. Studo also runs a “bug bounty” program, which gives security researchers a platform for testing in a protected environment and submitting vulnerability reports. At the bottom of this page you can find the details of the Bug Bounty Program.

Process automation

We follow the best practices defined by 12-factor for the Studo infrastructure. We have functioning, frequently used automation in place so that we can safely and reliably rollout changes to the Studo infrastructure. We usually deploy multiple times a day, so we have high confidence that we can get a security fix out quickly when required.

Secure network access

HTTPS is used throughout the entire platform, providing a secure, encrypted connection that ensures the security of any data. Real time updates utilize secure WebSockets (WSS) that are always encrypted as a transport protocol between the locally on the users device installed Studo App and the Studo infrastructure, adding an additional layer of security. We implemented a zero trust network architecture as a security model - it has no backdoors into our production systems.

Data security

  • Studo backs up stored data (such as PRO version status, user created calendar events in the app) daily and stores them separately from the main infrastructure.
  • All our infrastructure servers encrypt data at rest. The servers can be accessed only through TLS connections.
  • Our infrastructure provider contractually guarantees that when a disk goes to maintenance, all data on it are erased.

Infrastructure

We use Scalingo to host the Studo infrastructure, which provides a secure network and computing environment, including but not limited to firewalls at network, application and instance layer, data encryption DDoS mitigation etc.

The data center is located in Paris, France, and operated by 3DS Outscale. Since both Scalingo and 3DS Outscale are EU based companies, the GDPR fully applies to them.

Data center details

You can find complete information on the 3DS Outscale website: https://en.outscale.com/.

Secure Password and Credentials Storage

Passwords entered in the Studo App are never processed or stored by the operators of Studo and are only accessible by the locally installed app on the user's device. Therefore students do not forward any university username or password to a third party.

Passwords entered in Studo Connect (which are different to university credentials and authenticate partners such as student organizations) are stored using a PBKDF function (bcrypt) only in a hashed format.

Payment details

Studo is not in the business of storing or processing payments. Therefore we do not store or process any payment details of app users. The Studo PRO version can only be purchased in the corresponding store (Google Play Store on Android and App Store on iOS).

Uptime

Scalingo, the hosting provider of the Studo infrastructure, ensures via SLA an uptime of 99.9%. Databases and computational containers are operated in a fault tolerant multi-node setup. Furthermore, the Studo App is designed as an offline first application: All the needed information students need during the day (such as calendar events, bookmarks…) are stored locally encrypted on the user’s device. In case a user makes a modification to a personal calendar event, the data is first stored locally and then backed-up to the Studo infrastructure. In case this back-up fails, an automatic retry algorithm will back-up the updated information at a later point in time. 

Failover and recovery management

If one of the servers is detected as unavailable, Scalingo’s internal scheduler will dispatch the containers running on this server all around the cluster. Containers run on different hosts, as a result other containers will still be present while the unavailable container is restarted on a new server. In case the whole datacenter is taken down (electricity issue, fire…), our hosting provider sets up a recovery plan to resume the activity in another datacenter. Servers are replicated which lets us restart all containers in a second datacenter as fast as we can. In this case, downtime is unavailable, but processes have been set up to reduce downtime and recover the fastest possible way.

Permissions and Authentication

Access to the Studo infrastructure is limited to authorized employees who require it for their job. Managing the infrastructure can be only done by 2FA and ultra-secure passwords generated by password managers. 

Studo is served 100% over HTTPS. Studo runs a zero-trust corporate network. There are no corporate resources or additional privileges from being on Studo’s network and the corporate network has no backdoors in our production system. We have Single Sign-On (SSO) use 2-factor authentication (2FA) whenever possible and have strong password policies to ensure access to internal services are protected. We discourage use of shared accounts on any system and use LastPass to securely generate passwords. Master passwords are enforced to have at least 20 characters. We review which accounts can access systems and the permissions they have regularly.

Confidentiality

All Studo employees contracts include a confidentiality agreement.

Encryption

All data sent to or from the Studo infrastructure is encrypted using 256 bit encryption. Studo infrastructure API endpoints are TLS/SSL only and score an “A+” rating on Qualys SSL Labs tests. This means, we only use strong cipher suites and have features such as HSTS and Perfect Forward Secrecy fully enabled. We also encrypt data at rest using an industry-standard AES-256 encryption algorithm.

Security Vulnerability Reporting Policy

If you believe you have found a security vulnerability in Studo, we encourage you to let us know right away. Report via mail in English or German to security@moshbit.com. We will attempt to respond to your report within 1-2 business days. We will investigate all legitimate reports and do our best to quickly fix the problem. Before reporting though, please review this page including our responsible disclosure policy, reward guidelines, and those things that should not be reported.

Responsible Disclosure Policy

To encourage responsible reporting, we commit that we will not take legal action against you or ask law enforcement to investigate you if you comply with the following Responsible Disclosure Guidelines:

  • Provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and a Proof of Concept (screenshot, video or sourcecode).
  • You give us reasonable time to investigate and mitigate an issue you report before making public any information about the report or sharing such information with others.
  • You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) unauthorized access, modification or destruction of data, and interruption or degradation of our services.
  • You do not exploit a security issue you discover for any reason. (This includes demonstrating additional risk, such as attempted compromise of sensitive company data or probing for additional issues.)
  • You do not intentionally violate any other applicable laws or regulations, including (but not limited to) laws and regulations prohibiting the unauthorized access to data.
  • You do not modify or access data that does not belong to you.
  • For the purposes of this policy, you are not authorized to access user data or company data, including (but not limited to) personally identifiable information and data relating to an identified or identifiable natural person.

Bug Bounty Program Terms

We recognize and reward security researchers who help us keep people safe by reporting vulnerabilities in our services. Monetary bounties for such reports are entirely at Moshbit's discretion, based on risk, impact, and other factors. To potentially qualify for a bounty, you first need to meet the following requirements:

  • Adhere to our Responsible Disclosure Policy (see above).
  • Report a security bug: that is, identify a vulnerability in our services or infrastructure which creates a security or privacy risk. (Note that Moshbit ultimately determines the risk of an issue, and that many software bugs are not security issues.)
  • Your report must describe a problem involving one the products or services listed under "Bug Bounty Program Scope" (see below).
  • Submit your report via mail to security@moshbit.com.
  • If you inadvertently cause a privacy violation or disruption (such as accessing account data, service configurations, or other confidential information) while investigating an issue, you must disclose this in your report.

In turn, we will follow these guidelines when evaluating reports under our bug bounty program:

  • We investigate and respond to all valid reports. We prioritize evaluations based on risk and other factors, and it may take some time before you receive a reply.
  • We determine bounty amounts based on a variety of factors, including (but not limited to) impact, ease of exploitation, and quality of the report. If we pay a bounty, the minimum reward is €50. Note that extremely low-risk issues may not qualify for a bounty at all.
  • In the event of duplicate reports, we award a bounty to the first person to submit an issue. (Moshbit determines duplicates and may not share details on the other reports.) A given bounty is only paid to one individual.
  • We reserve the right to publish reports (and accompanying updates).
  • We will provide you if needed with test accounts to Studo, feel free to ask us.
  • In case the finding of a security issue is part of an academic work (such as Bachelor/Master thesis): After resolving the issue we can provide you additional information for your work.

Bug Bounty Program Scope

To qualify for a bounty, report a security bug in Studo or one of the following qualifying products:

  • Studo App for Android and iOS (we pay out double rewards for bugs found in the Studo App). If needed, request a demo-account via security@moshbit.com
  • Studo Chat - chat system within the Studo App. If needed, request a demo-account via security@moshbit.com
  • The in the Studo App at some universities linked career platform Talto
  • Infrastructure of Moshbit
  • Domains studo.com, *.studo.com, studo.co and *.studo.co
  • Self-hosted open source Campus QR application

If you are unsure whether a service is eligible for a bounty or not, feel free to ask us.

Out of Scope

  • Spam or social engineering techniques
  • Denial-of-service attacks
  • Secuity issues in Android or iOS operating system or smartphone/tablet-vendor specific software
  • Old versions of the Studo App
  • Trickery to get the Studo PRO version for free, as long as it is not a security issue and only leads to missing payments to Moshbit.
  • Security issues in third-party services that Studo integrates: University websites, university mail services, news websites. These are not managed by Moshbit and do not qualify for our guidelines for security testing.