My requirements and solution for a safe storage of personal secrets.

Introduction

I have secrets. Everybody does.

Not just passwords, but their context, and many other kinds of codes. And secrets which aren't even related to computers.

A few years ago, disappointed by the solutions I had found, I formalized the requirements, or rather a list of the ways secret storage can be unsafe, and started to build the best solution I could.

Here are my considerations for a computer software safely storing texts with minimal risks of either having the texts leaking of having them lost. This is a long list, not really untertaining, and some points even overlap a little, because I first wanted to be exhaustive, covering even the points no software today addresses. To compensate, I'll try to keep each point to the minimum.

Points to Consider

Here's my check-list, describing both the attack surface and the requirements. And how SafeCloset answers, or not.

Speed

If the program takes seconds to launch, or if its ergonomics make it slow to read or change its content, you won't use it.

This was a priority of the design of SafeCloset and I think the result is satisfying.

Inability to store your secrets

If the software has been designed only for passwords or short strings, it may be unable to keep all the context you need to use those secrets, or your secret poems, or whatever you want to keep safe.

Safecloset accepts any text.

Inability to store non textual media

This could be a requirement, hence why I list it here. It's not a need I personally have and SafeCloset isn't designed for non textual secrets.

Inability to find your secrets

I have hundreds of secrets, mainly because I have such a bad memory that I must write down even trivial things like door codes. This means I wouldn't be able to retrieve my secrets without an efficient and convenient search.

SafeCloset searchs keys with a fuzzy algorithm (the one I had devised to search my whole disk in broot).

Systemic software flaws (language/framework flaws)

It would be crazy today to write a secret store in a language like C or JavaScript.

In 2023 and in the few years before, there's no real alternative to Rust there.

SafeCloset is 100% in Rust.

Core encryption algorithm flaws

Nowadays, this isn't really a problem anymore, as libs and documentations are numerous enough. The choice must still be correct, though.

SafeCloset crypts its drawers with AES-GCM-SIV, with a random one-use nonce and the password/key of your choice. This gives an inherently long to test decrypt algorithm, making brute force attacks harder.

Inability to run the software due to system configuration

If the software needs a dynamic library, a runtime, or a very special environment, you may lose the ability to run it.

I think the secret storage program must be compiled and only use statically linked libraries.

Inability to run the software due to hardware capabilities

The program must run on the hardware you're likely to easily find now and in the future.

SafeCloset only needs a small terminal, colors don't matter. It's fast enough to run on hardware already obsolete, with low memory. It doesn't use any rare instruction or hardware.

Inability to replace the software

If the languages or frameworks of the software go abandonned, it must be possible to rewrite it in other technologies. This means it's of paramount importance to have the storage format open, clearly described, independantly of the language.

SafeCloset's storage format is based on simple, open, and widely used serialization formats and is described in the repository.

Unavailability of the usual operating system

You may need to either migrate to a new system, or to use a different one temporarily. Your program must not be limited to a specific system or runtime.

SafeCloset is compiled for various platforms, among them obviously Windows, Linux, & Mac. My advice is to keep the executables of all the platforms together with the data file (you should still not normally launch the programs which were left without surveillance as they might have been replaced with tampered ones).

Network

Network transport needs more care than people imagine (TLS is too often compromized, for example, especially on corporate computers). It can be secured with a proper protocol, though.

SafeCloset solves the question by not using any network exchange.

Cloud Availability

Any long term vision excludes relying on a cloud provider or on a cloud based service. There's no other way to own and keep your valuable secrets.

SafeCloset is not cloud based.

File Loss & File Steal

Secrets must be backuped in several places with regularity. Just like any critical piece of data.

That means there should be one single small enough file, and that this file being intercepted must not be a problem, because you can't ensure the physical security of all backup locations.

Observation of successive versions of the storage file

An attacker having an entry point in one of the backup locations is something "normal". An attacker must not be able to determine anything about the content from successive versions.

SafeCloset solves this first by the inherent properties of AES-GCM, but also with having the encrypted data be mostly a random bag of bytes whose length and content changes at each saving. This makes it impossible to guess the size of the real content, and whether there's more or less than in a previous version.

Software Maker compromission

If you store vital secrets, you must be sure the software maker can't observe your activity or your data (this also ensures nobody has interest in pressuring the software maker, which is obviously interesting to me).

The software must thus not communicate with the maker, which must have zero knowledge of the users and no mean of transmitting them anything.

Text Editor

The more you know text editors the more you know how terrible they are security wise. Did you think about what would happen if a misconfigured backup solution was transmitting your editor's automatic backup ? Yes it's a nightmare. From automated backup files to plugins exporting data for ML training or any other plugin reading the text, a standard text editor is just totally incompatible with security.

An almost immediate conclusion is that the program ensuring the storage must also be the editor.

Native widgets

Widgets coming with the Operating System are hard to control. You don't always know how they're customized and the involved components.

That's why I decided that SafeCloset would not have any native or external widget.

Shell

The more shells evolve, the more they keep an history of what they see and the easier it is to add hooks.

It's clear a secret store must never receive its input from the shell nor export to it the secret.

That's why SafeCloset, while it would obviously be convenient for automation, doesn't even offer a way to send a secret to the standard output.

Browser

This is probably the least trustable piece of software you have.

SafeCloset doesn't accept queries coming from the browser or any of its extensions. At some point you'll probably still have to enter some passwords in your browser, and I have no solution for that, but not accepting queries means only the intended passwords are given to the browser, and only when you want.

Terminal

If the terminal is modified, it might spy on your rendered secrets.

I have no solution at present for that. My only advice is to take care of the choice, installation and update of your terminal.

Screen Observation

A screen can be observed either with physical spying (somebody present, a camera, screen emission analysis, etc.) or through compromission of the system.

SafeCloset doesn't provide a complete protection against such observation but mitigates the problem by making it easy to not display the password and to not display, on command, the secrets you're not interested into.

Keys Observation

A key logger on the computer can see the passwords you type.

I have no idea how to deal with this kind of attack except protecting the computer and not installing a keylogger yourself.

Brute Force

A brute force attack would normally not be done through the original program but using a different one which would know the secret storage format.

The only defences I know against that are encouraging long and hard to brute-force keys, and making a guess computationnaly expensive through the right choice of crypto algorithm. SafeCloset does both.

Tampering with the program's binary before installation

Package repositories, the download area of the software maker, should be considered with suspicion.

My server could be compromised. That's why SafeCloset binaries are made available in only one place: GitHub release directories.

Replacing the software with a modified one

If an attacker controls your system, they can replace the program with another one sending the content when you open the closet.

SafeCloset provides no solution against that. Your system must be kept safe enough.

Clipboard Spying

If the clipboard is used to copy codes and passwords from the secret store to other programs, it's an obvious target for an attacker who could either spy on it with some control of your system, or just paste the clipboard's content when you leave the computer.

Not allowing copies would probably be worse for security, as it would discourage long passphrases.

SafeCloset doesn't really solve the problem. It shows a message in the status bar to remind you about this risk when you copy some string, though.

Memory Scan

A compromised system might let a spying program scan the computer memory and read the decrypted secrets it contains.

SafeCloset doesn't protect against that, partly because such a compromised system is almost a lost cause anyway, and because none of the solutions I had found advertised to this problem were more than a placebo.

Safe box left open

If the safe box can stay open after you've looked at your secrets, then you're permanently at risk because you may have an accident, being called urgently elsewhere, etc.

SafeCloset automatically closes after some short inactivity timeout, and this feature can't be disabled.

Programs staying in RAM with key and|or content

If your passphrase or your closet content stay in RAM for a long time, they can more easily be accessed.

For example, if the computer goes to sleep mode, it may dump the RAM to the disk for restoration, which makes it usually easy for attackers to scan its content.

SafeCloset automatically closes after some short inactivity timeout, this feature can't be disabled and there's no resident service.

Flaws in dependencies

There must be an effort in reducing the number and size of external dependencies and in selecting only high quality ones.

Injections through dependencies

Modifying a library and having it injected in program defining it as dependency is now a classical attack.

SafeCloset locks the version of its dependencies and fetches them from crates.io, which makes this kind of attack impossible unless crates.io is severely compromised.

Bugs in the secret store program

A bug in the program may have serious consequences, from freezing it open to writing data badly encrypted, or just losing your data.

The program and its dependencies being written by experienced programmers isn't enough a guarantee. The language must be the least prone to critical bugs. That's why SafeCloset is written in Rust and is open-source. It was also a requirement for the source code to be clear and short.

SafeCloset itself has unfortunately not been formally and independently audited. That would have been a plus.

Being forced to open the box

There may be several scenarios in which authorities or armed people may force you to open the storage. Not knowing what the future will be, I find it desirable to make it impossible for an attacker to know if you gave all the content.

SafeCloset lets you hide drawers inside drawers, and hides the real number of drawers.

Merge & Synchronization

Moving everywhere with your copy of the data file, or having the secret store installed on several computers without relying on a network access, means you may end up with several versions of your data file, and you may need to synchronize them.

While this may very well be done "by hand", because you know the changes you made, it can be made more convenient with some tooling.

SafeCloset proposes an "import" function which lets you select and open another file and safely merge the differences.

SafeCloset

This list directed the design and realization of SafeCloset.

I think I made a fine job... for the set of requirements which I think do matter. Most people have a different vision, usually putting a lot of trust in private companies and their own ability to configure their shell and editor, or not considering acceptable some decisions I made like running the program in the terminal. You can say this list is opinionated, and so is SafeCloset.

If you can suggest improvements to either the list or the way SafeCloset answers its concerns, please contact me!