Last Edit: 03.2024
Language: Typescript React Capacitor

With this app, it is possible to securely store ToDo Lists locally with AES & Triple DES encryption, edit/delete them and search them. It is also possible to decrypt the ToDo Lists using native biometrics (e.g. fingerprint sensor). (More on this under Security) In addition to the security factor, the aim of this app is to enable the best possible organization of various ToDo elements. This is implemented through the mini dashboards in the overview etc., prioritization, categories and end dates for the individual ToDos.

Google Play Store: https://play.google.com/store/apps/details?id=de.scheub.securePlaner
Apple App Store: https://apps.apple.com/de/app/secureplanner/id6478185630

Deutsche Kurzbeschreibung: Mit dieser App ist es möglich To DO Listen mit AES-Verschlüsselung & TripleDES sicher lokal zu speichern, sie zu bearbeiten/löschen und sie zu durchsuchen. Zudem ist es möglich mithilfe der Native Biometric (z.B. Fingerabdruck Sensor) die Listen zu entschlüsseln. (Mehr dazu unter Security) Neben dem Sicherheitsfaktor ist es das Ziel dieser App, die bestmögliche Organisation der verschiedenen ToDo-Elemente zu ermöglichen. Dies wird durch die Mini-Dashboards in der Übersicht etc., die Priorisierung und Deadlines für die einzelnen ToDos umgesetzt.

App Store Screen 1	App Store Screen 2

Start Screen	ToDo List Overview	ToDo List Edit	Settings

First of all: All To Do Lists are stored encrypted with AES256.

• The user's password is first hashed using PBKDF2 with 60,001 iterations and a fixed salt. (With medium security setting only 20,000 and if you select low none at all as there is no password)
• This hash is then passed through 2,000 iterations using PBKDF2 with a different salt for each ToDo list. (With medium security setting only 500 and if you select low none at all as there is no password)
• The resulting hash is then used for AES256 encryption.
• In addition, the data is encrypted with a SHA256 hash based on the device ID using TripleDES.
• No data is transferred to a cloud or similar.
• All data is processed and stored locally on the device. The security measures described below all refer to the high security setting, which is also the default setting.

• Why is PBKDF2 performed twice?

  • So that it is possible to use a different salt for each ToDo list. This increases the protection against rainbow table attacks.
  • In addition, the recommended number of iterations for PBKDF2 can still be carried out without extremely poor performance. This increases protection against Brutal Force Attacks.
  • Such a high number of iterations in combination with different salts for each ToDo list has proven to be very slow and impractical on current devices (e.g. iPhone 14).
  • Furthermore, if a single ToDo list is decrypted, the others are not threatened.

• Why just use SHA256 for the PBKDF2?

  • Quick answer, simply because of the performance.
  • With a SHA512 hash for the login, a current Android flagship smartphone (from 2023) took an average of 50 seconds and a current iPhone around 15 seconds.
  • Since the performance with SHA256 is significantly better with Android around 10 seconds and iPhone 2-3 seconds, this was used.

• Why AES and TripleDES?

  • AES256 is currently the general recommendation. And since the goal was to use an additional encryption with a different password (here the deviceID), it was the right opportunity to use a different method.
  • So if AES256 or TripleDES have security problems, this can work as a further protection measure.
  • It also increases the effort for attackers as they have to decrypt two different methods.
  • Since it also offers no disadvantages (except performance), e.g. a hack of the TripleDES encryption still leads to the AES encryption having to be decrypted, the advantages were seen to outweigh the disadvantages.

The encryption and decryption process is also shown here. The password is already understood to be the PBKDF2 processed hash with 60,001 iterations, as only this is used within the application as soon as it has been generated after opening the app.

Anyone interested is free to take a closer look at this and make suggestions for improvement. The entire encryption/decryption logic takes place in the EncryptionEngine. (Except the logic of the biometric login)

• The password is stored in the KeyStore on Android and in the keychain on iOS if biometric authentication is enabled. These stores are secure according to the OS publisher. If this is not used, the password is not saved either.

• Only the first PBKDF2 hash from the first derivation is used. No password in plain text or similar. This is also the reason for the significantly faster login with a biometric login.

• The password hash is encrypted with TripleDES as it does not usually need to be decrypted frequently.

• The password hash is encrypted with a SHA256 hash from the deviceID/identifier of the device provided by Capacitor before it is stored. (Just to be safe and independent of OS security.)

  On iOS, the identifier is a UUID that uniquely identifies a device to the app’s vendor (read more).

  On Android 8+, the identifier is a 64-bit number (expressed as a hexadecimal string), unique to each combination of app-signing key, user, and device (read more).

• When the ToDo lists are exported, they are no longer encrypted with the SHA256 hash of the DeviceID. However, they are encrypted using AES with a specific word which is hard-coded here.

• As before, the ToDo lists are also encrypted with PBKDF2 and should only be decryptable with the user's password.

• When importing the data, the data must be decrypted with the user's password, otherwise it should not be visible.

• The secure encryption of data/ToDo lists cannot be guaranteed.
• The application has been developed to be as secure as possible from the developer's point of view.
• It is open to anyone to review the security measures here and report any security vulnerabilities identified here. (This is why the application is open source)
• The Crypto-JS node package is used for encryption. If this has security gaps or similar, the data here is insecure!

• Android/iOS: The app is distributed in the Google Play Store and Apple App Store with the help of Capacitor.
• Windows: With the help of Electron, it is distributed in the Microsoft App Store as MSI. Installation. (Without support for Windows Hello/fingerprint scanner)
• Mac: It is possible to use the Electron app from the repo. However, it is recommended to simply download the iOS app from the Apple App Store for M1 MacBooks. This app also supports Touch ID etc. directly.

The Jest testing framework is used for testing. The tests here are always written in Typescript.

The goal is actually to have about 80% test coverage of the lines. This number appears to be enough as this is a freetime project. This seems to be sufficient, as there are already 197 tests...

The components used are divided into four categories:

• UI-Elements
• View-Componets
• Container-Componets
• ServiceLayer

Note: Some of the modules are used from other Web Apps like the Encryption Engine or the Impressum/Imprint Modules. As a result of the use from the modules, some files have an the name "note" instead of "todoList" inside and there is also one configuration file:

• app_texts: Contains texts such as the description, imprint text, data protection text etc.

In addition, the separation is not 100% sharp, partly because of these modules, but also because the final architecture only turned out that way during development.

UI-Elements At the topmost level, UI-Elements are the fundamental building blocks of our interface. These are the atomic components that include buttons, input fields, and other basic interactive elements. They are styled and abstracted to be reusable across the application.

View-Components View-Components are composed of UI-Elements and form parts of the application's screens. They are responsible for presenting data and handling user interactions. These components are often reusable within different parts of the application and can communicate with Container-Components for dynamic data fetching.

Container-Components Container-Components serve as the data-fetching and state management layer in our architecture. They connect View-Components to the Service Layer, managing the application state and providing data to the components as necessary. They may also handle complex user interactions, form submissions, and communicate with services to send or receive data.

Service Layer The Service Layer is the foundation of our application's client-side architecture. It abstracts all the handling wth the ToDo Lists (LocalStorage handling included), the fingerprint logic (e.g. password storage in secure storage), helpful functions (e.g. formatDate,equals) and the encryption engine logic.

There is a large ToDo List service which is also subdivided into smaller services. This design was considered practicable here to make this very large service easy to maintain in the future. This was not necessary for the others and they are simple export functions.

Note: The App.tsx, the interfaces and props are hidden here to make it easy to keep an overview. (The architecture image is not completely up-to-date and therefore does not yet include the logger service, for example. However, it still gives a good overview and includes almost everything)

node_modules/builder-util-runtime/out/httpExecutor.d.ts:9:5 - error TS2411: Property '"accept-charset"' of type 'string | string[]' is not assignable to 'string' index type 'string'.

9     [key: string]: string;
      ~~~~~~~~~~~~~~~~~~~~~~

For whatever reason, this NPM module is not 100% compatible. The easy fix is to simply change the location in the error so that the file type matches. Just adjust the module inside the Electron folder under node_modules by adjust the line:

export interface RequestHeaders extends OutgoingHttpHeaders {
    [key: string]: string | string[]|number | undefined;
}

is adapted to this: export interface RequestHeaders extends OutgoingHttpHeaders { [key: string]: string | string[]; }

In the project directory, you can run:

Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits.
You will also see any lint errors in the console.

Launches the test runner in the interactive watch mode.
See the section about running tests for more information.

Returns the complete test coverage rate in the form of a table for all files.

Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.
Your app is ready to be deployed!

See the section about deployment for more information.

This command will synchronize the iOS and Android project and bring it up to the current status of the web app.

This command will open XCode with the current Capacitor project so that you can build the app directly.

This command will open Android Studio with the current Capacitor project so that you can build the app directly.

Generate the JSON with the licenses of the NPM packages used. This can then replace the existing license json under modules/legal/usedLibs.

Note: this is a one-way operation. Once you eject, you can’t go back!

If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.

Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.

You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.

According to the command npm list You can see the deeper NPM modules used and which of these are used in the licenses.json.

├── @babel/[email protected]

├── @babel/[email protected]

├── @babel/[email protected]

├── @capacitor-community/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @capacitor/[email protected]

├── @emotion/[email protected]

├── @emotion/[email protected]

├── @mui/[email protected]

├── @testing-library/[email protected]

├── @testing-library/[email protected]

├── @testing-library/[email protected]

├── @types/[email protected]

├── @types/[email protected]

├── @types/[email protected]

├── @types/[email protected]

├── @types/[email protected]

├── @types/[email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

├── [email protected]

└── [email protected]