Development of a secure application

* Timespan: December 2023 - January 2024
* Description:
  - Supervised university project, with technical production.
  - Production of a secure application designed to manage hotel room bookings, adapted to mobile devices and built using Python and KivyMD.
* Improvement paths:
  - Build an APK file using the Buildozer tool and effectively launch the application on Android.
  - Improve the overall design and ergonomy of the user interface.
  - Improve the organization and structure of programs and media used by the application.

This project consisted in working in pairs to design an entire hotel booking management application intended for the mobile medium, and specifically Android.
We had to :

• Submit specifications detailing the technologies to be used.
• Develop a back-end software interface adapted to the server environment to be used by our application.
• Develop an accessible and ergonomic front-end software interface, adapted to users' needs.
• Provide a user authentication system, thus enabling the tracking of bookings made by each customer, as well as customized user menus.
• Save exchanged data in a database, via an API.

Beyond the subject initially given, the team wished to design a hotel room booking application covering a franchise of hotels rather than a single hotel. Indeed, by using the city names given to each room of our institute (IUT de Luminy), we wanted to further personalize our work while proposing something more advanced in terms of algorithmic processing.

Throughout the project, ensuring data processing security was our main concern.
The actual solutions implemented to secure our application include :

• Restriction of access to our database manager to the local machine (being the server), to minimize the attack surface on our database.
• The use of prepared statements in SQL queries submitted to our database manager.
• Users dedicated to read and write queries within our database, granted appropriate privileges.
• The implementation of TLSv1.2 security protocol to secure data exchanges between a client instance and the server software interface.
  Within the scope of a university project, TLS was implemented using self-signed certificates, which is strongly discouraged in a production environment.
• The recording of hashes associated with customer account passwords, undergoing dynamic salting.
  Includes the recording of salts generated for each customer account.
• At filesystem level, appropriate configuration of read/write/execute rights on scripts and files used by the server's software interface.

Among the main challenges and doubts encountered during this project :

• Managing client instances (front-end) :
  Our back-end software interface had to be capable of handling concurrent connections from multiple client instances.
  For this purpose, multithreading (Python's threading module) was implemented in the server's software interface to manage parallel connections with client instances.
  However, Python's Global Interpreter Lock (GIL) by its very nature prevents any real parallelism in multithreaded processing, especially when such processing is CPU-intensive.
  Furthermore, implementing multiprocessing (Python's multiprocessing module) to bypass the GIL and attempt to improve parallel handling of client instances would have simply lengthened overall processing times, without producing any time benefits.
  Ultimately, relying on multithreading proved to be the most appropriate way of dealing with client instance connections, as the only tasks to be carried out consisted in managing I/O on network sockets managed by the server's software interface.
• Dynamically loaded media management :
  Our user interface had to display dynamically retrieved and loaded images, so that whenever the application was started up, the display matched the data in our database.
  Three major concerns followed :
  1. How can we exchange an image between two remote machines without involving any intermediate software ?
     After fiddling around for a while, we've decided to exchange the filename, file format (PNG, JPG, etc.) and binary content encoded in Base64 for the transmission of an image between the server and a client instance.
     Transmissions were then directly driven by the emission of Base64-encoded binary strings on the network sockets in use.
  2. How can we access the data associated with a specific image on the server ?
     Initially, it seemed intuitive to save the binary content of the images loaded by our application in our database, using the MEDIUMBLOB data type, along with the associated file names and file types.
     But as we looked for ways to simplify processing, we realized that saving our images in our database wasn't ideal, due to the wasted database manager resources (space used, data retrieval, etc.).
     Our database was therefore adapted to store absolute paths for all used images, so that the actual content of each image could be retrieved from the server's file system.
  3. How to optimize image loading within client instances ?
     Indeed, it is quite impractical to systematically fetch from the server the required images to display within a given client instance.
     This would result in a lot of redundant processing and would pointlessly overload the stack of operations to be carried out by the server.
     We've thus developed algorithmic ways to restrict the exchange of dynamically loaded data, while ensuring a consistent display and optimized user experience.
• Managing cascading context-sensitive functions :
  Our application needed to process and show users information based on menus which behaved and displayed in a way that was dependent on other menus.
  Typically, the application first invited customers to choose a destination city, then a hotel depending on the destination city previously selected, then a hotel room type depending on the rooms available in the selected hotel, then choices of feature combinations related to the hotel room type chosen in the selected hotel... and so on.
  We've thus applied to each software interface appropriate logics to handle cascading contextual menus, according to the needs of each menu/context defined.
• Managing the messages exchanged between a front-end and back-end software interface :
  When it comes to exchanging data between the server and client instances of the application, we needed to define specific messages to deal with different types of data, leading to different transmission operations.

Here are some of the ideas we wanted to explore further if we were given more time to develop our application :

• Implement distracting loading screens in the user interface when exchanging large amounts of data with the server.
• Improve the application's accessibility by adding features adapted to people with visual impairments.
• Add detailed privacy policies and terms of use within the application.
• Provide additional account and booking management features in the customer account interface.
• Provide additional hotel room management features in the janitor account interface.
• Improve the design of the hotel janitor interface.
• Standardize and manage text fields to anticipate language changes, which would certainly have required the use of JSON files.
• Provide database backup mechanisms and dynamic resalting scripts to safely maintain customer account passwords.
• Implement TLSv1.3 instead of TLSv1.2 to secure data exchanges between client instances and the server software interface.
• Use SSL/TLS certificates issued by a widely trusted certificate authority.

Finally, our main regret remains our failure to deliver a functional rendering on mobile support.
Errors encountered when building an APK file just kept popping up, and eventually no working APK file could be generated to effectively push our application to Android.
However, it's worth noting that if our application had been tested on Android, the instructions and statements used to manage dynamically loaded medias in our application would have certainly needed to be tweaked.

This thrilling work was carried out with my colleague Aymane El Moutaouakkel.
However, while it had been planned and submitted as a pair project, I designed and developed the entire project on my own, due to my colleague's shortcomings identified early on.
It would have been impossible for me to deliver a serious product by systematically checking his algorithmic productions.
Throughout this project, my personal goal thus became to help my teammate in developing his algorithmic knowledge and abilities, by leveraging my own methods and programs as a learning basis.
As a result, my teammate could genuinely experiment and take the time to build up a solid foundation in programming, while at the same time gaining an understanding of the concepts and mechanisms implemented in the resulting application.

Documents and deliverables