Making Mimiri Notes Secure

When we built Mimiri Notes (at the time named Mimer Notes) almost 20 years ago our primary motivation was to create a secure place for us to store credentials, software activation keys, recovery keys, credit card information and whatever else we wanted to have readily available while still keeping it safe from both disaster and bad actors.

At this time there were no password managers, and at work we were just starting to become aware of password hashing and the weaknesses of MD5 and the need for individual salting. In other words this was early in the industry’s awakening to security.

Prior to making Mimiri Notes we were storing our passwords in a text file fully aware of the risks involved but also not really knowing what else to do. Reusing passwords was obviously intolerable and who could possibly hope to remember 50 unique passwords?

So we built a tool that would allows us to keep our passwords, and whatever else we might want to keep safe, safe. At the time we did think about making a product of it and we shared it with a few friends but ultimately decided that the effort of productization was too great.

In 2024, however, when the Zürich IT Consulting market took a nose dive along with the rest the world economy we found ourselves with more time on our hands than we knew what to do with and so Mimiri Notes the product was born.

The motivations remained the same, we still wanted a place that was secure from both disaster and bad actors, we wanted it to be readily available so we would actually use it. And as we had been using Mimer Notes for more than just highly sensitive data we wanted to expand on the usability for generalized plain text notes.

Mimer/Mimiri Notes was always a “cloud first” service - no one had coined that term yet, back then the hottest new thing was Infrastructure as a Service, but that is essentially how we were thinking. There isn’t a lot of disaster resiliency in storing encrypted data on your personal computer after all. And we also wanted to be able to access our data from other places.

In this post I want to discuss the security aspect of building Mimiri Notes in particular but a lot of it is equally relevant for any other secure system.

Making It Actually Secure

When you are trying to build a secure system it is easy to get caught up in fancy algorithms and best practices espoused on various blogs and while these are all relevant and helpful they are no where near enough.

It doesn’t matter if you are using AES with a key derived using PBKDF2 with all the bells and whistles if at the same time you are sending that password in plain text over http. You need to bring it all together and create a cohesive system.

Nor is it enough to make it secure, anyone can put a thumb drive in bank vault and it will be impervious to network attack but it will also be inaccessible to you and every time you take it out of the vault and plug it into your PC you are opening it up for attack.

it has to be secure while performing the functionality you need it to perform, and that combination will invariably be a matter of compromise. You cannot send your password to the service provider without first decrypting it and while it exists decrypted in memory on your PC it is a lot more vulnerable than it is while stored encrypted on a thumb drive in bank vault.

Now, this is a solved problem it is just that each of the solutions comes with a set of drawbacks that leaves simply sending the plain text password to the server as the most common authentication mechanism.

While an increasing number of services are rolling out 2FA (Two Factor Authentication) you are not likely to see your local mom and pops start using it on their web-shop in the foreseeable future. The drawbacks outweigh the benefits by a rather substantial margin for this scenario.

There are other effective solutions too, but they are all a lot less convenient than simple password authentication and simple password authentication works a lot better than the prevailing winds of The Internet would have you believe and will continue to do so regardless of advances in computational power (I have another post about this)

Analyzing the Threats

In order to properly choose our compromises we need to understand what the threats are. And when we designed the security model of Mimiri Notes these were the threats we identified as seen from the end user perspective in roughly descending order of severity:

1. The provider started out with malicious intent
2. The provider is incompetent
3. The provider becomes compromised on the human level (coercion, conversion, change of ownership, etc.)
4. The infrastructure becomes secretly compromised for an extended period of time
5. The infrastructure becomes temporarily compromised
6. Some amount of server data is breached and nobody knows about it
7. Some amount of server data is breached and it is quickly discovered
8. The communication between client and server is compromised
9. The device is long term compromised (by malware)
10. The device is short term compromised (by malware)
11. The unlocked device is stolen
12. The locked device is stolen
13. The powered down device is stolen
14. An attacker gains temporary access to an unlocked client device
15. An attacker is able to observe the monitor
16. The user accidentally shows the client during a screen sharing session

Some of these threats are very broad and some are very specific but let us address all of them in turn

Trust

We will group 1-3 under the umbrella of trust.

The intentions or competence of the provider of any service you use is always hard to verify. Luckily, most of the time that isn’t super important, the blast radius is usually limited to the service in question (this is why using unique passwords is important) and most of the services we use are of limited consequence.

That said, we have heard about an uncomfortable number of security cameras that were, ironically, very insecure and the consequences of that while not universally severe certainly can be.

Unfortunately it is extremely hard as a layperson to make the determination. Generally we are somewhat better at spotting malicious intent than we are at spotting incompetence but if someone is well spoken and says all the right buzz words it is incredibly hard to determine if they are trustworthy and it takes an unusual amount of cynicism to even consider it.

So we asked ourselves the question, not how do we convince laypeople to buy our product, but what would it take to convince us that a provider was both competent and well intentioned.

Up until this point, we had never intended to open source Mimiri Notes. Ideologically we are what could be best described as open source agnostic. And it seemed natural that if you want to make money, proprietary is the way to go, after all why would you open the door for users to circumvent the paywall?

But we realized quickly enough, once we started actively thinking about it that Mimiri Notes has to be open source. No amount of third party auditing - real or imaginary - could possibly assuage the reasonable doubt that any sensible even remotely security conscious person would have to have.

We could have tried to play some kind of shared source game, and tried to remain as proprietary as possible while allowing “review” of the code that supposedly is what actually gets compiled and shipped.

But at the end of the day we decided that if we are going to open source it, rather than trying to eat our cake and have it too we should do it right. And it is not like there are no benefits to open sourcing in its own right.

So we made the decision that not only will we open source it under GPL we will help you compile it yourself and self host it, if you so desire. And change the economic model to work with the community and make it desirable to pay us rather than try to extract payment through withholding service for the freeloaders.

It wasn’t an easy decision to make but once we started down that road it became increasingly obvious that it was the only good option and while we haven’t been ideologically converted to the FOSS mindset we have recognized that you don’t have to come from an altruistic perspective to find real value in it and that this is arguably why GPL exists as opposed to BSD/MIT/etc.

This was mostly done to address our intent and competence, but it has the added benefit of significantly mitigating the third as well: It is much harder for us to become malicious even if we wanted to once we have taken the full step into open source, hiding malicious code becomes much harder, and should we become less trustworthy in the future nothing stops someone else from creating a replacement service and continuing in the original spirit. And this being true greatly reduces the likelihood of it happening in the first place.

It is a clear win for the objective even if it does come with certain financial uncertainties.

That said, we actually do believe it is the right play long term financially as well, but that is a lot less well founded in traditional economic theory.

Compromised Servers

We will group 4-7 under the heading of compromised servers. And the name of the game is defense in depth.

All data on the servers was encrypted before it even reached the servers so even in case of full access to the data it should remain secure provided the user chose a half decent password.

On top of this we encrypt all the backups with ChaCha20-Poly1305 using a key that isn’t present on any of the servers involved in the operation of the service - obviously it is on a server that could also be breached but it offers additional barriers. And it helps mitigate the fact that the backups by necessity have to go off site where the exposure is invariably greater if for no other reason the introduction of yet another party.

The shared secret, i.e. the derivative of your password, is likely to be the weakest link in the chain even though it is run through PBKDF2-SHA512 300'000 times. it is ultimately the least complex thing to verify a password guess against and for this reason the server encrypts this and any other piece of data that could be similarly used with AES-GCM-256 before storing it in the database using a key that is not itself stored in the database or even known to the servers running the database.

This should mean that even if the database or a backup of the database is somehow breached it will be impossible to gain access to the user data even if a weak password has been used (a sufficiently weak password is course still vulnerable to online attack but the threshold for good enough here is many orders of magnitude lower than in an offline attack).

Even in the case of a full and absolute breach, or a conversion of an employee with full access, any data already on the servers is and will remain as secure as the password chosen by the user. However, any of the additional mitigations would be nullified in this case and only the password would be in the way.

Malicious Updates

There is one remaining challenge facing us in case of compromised servers and that is the possibility of a malicious update.

Under normal circumstances all updates are signed using keys that reside only on servers different from the ones used in the operation of the service. However, in the case of a sufficient compromise of either systems or people this could naturally be overcome and an update could be sent out that compromises data or passwords.

This is why we have made update notifications unobtrusive, at no point should a user feel forced into an update and if you are concerned you can and probably should wait a little while before updating.

It is also partially mitigated by the open source nature of the project, but unless you are compiling the application yourself it can be hard to determine if there is correlation between what is on Github and what is in the update the application is telling you to install.

This is an area where more can be done and we do have some ideas and we assign fairly high priority to this. If you have ideas by all means hit us up on Discord, and similarly if you have concerns about an update joining the community on Discord will hopefully turn into a way of checking not just with us but other members.

Two Factor Authentication

Now might be a good time to address what to some might seem like the elephant in the room. Why are you not using 2FA?

While we are considering offering various forms of 2FA, including the traditional token, device binding in various forms, and using one device as a second factor for another, it will never be mandatory

The reason for this is to be found in the goal of Mimiri Notes. To us both personally and as a product Mimiri Notes is and should be a viable last resort to put your life back together again after a disaster, and a 2nd factor is something you can lose. And so is a recovery key to a 2nd factor - I have yet to see one that it was realistic to remember.

Sure, you could write the recovery key on a piece of paper and bury it in a sealed box in the woods a few hundred miles from your home and that would have a high likelihood of working and is a lot less losable than the key to a safe deposit box or an ID but it is also absurdly impractical, and it won’t help you if your disaster happens during a vacation.

And if you choose a password that isn’t itself a disaster it will be more than adequate. Exactly how good that password needs to be will depend on your specific circumstances but unless you are targeted specifically the requirements are really not that high once you factor in the application of key stretching (PBKDF2).

Insecure Communications

With that we come to threat number 8.

We obviously use HTTPS for all communication but that isn’t impervious to man in the middle attacks, and many corporate networks do exactly that to protect the broader system through packet inspection.

Creating an account over compromised communications does come with some risk as the shared secret is sent to the server. However, access to the shared secret only downgrades your security from online attack to offline attack. And while this isn’t a trivial matter, being able to withstand an offline attack is one of our key design parameters.

However, this is not a very reliable attack vector, but it does present a slight weakening under certain circumstances and we will likely improve it once it becomes the most serious weakness remaining.

The login process on the other hand uses a challenge response where knowledge of the secret is proven without sharing it - if you are not in the know: Essentially what happens is that a hash is computed of something the server has chosen (typically including a timestamp and some random data) using the shared secret as the key in an HMAC hashing process. Both client and server perform this computation and the client sends the result to the server and if it matches the result the server came up with you are good.

Subsequent communication is in effect protected by one or more layers of AES-GCM-256. Any action or query directed at the server is signed with 4096 bit RSA and verified by the server individually.

The server has no concept of a session, this prevents a man in the middle from intercepting a session token and executing arbitrary commands on your behalf and has the added benefit of making horizontal scaling of the api frontend a lot simpler.

Compromised Client Device

We will group 9 and 10 under the heading of compromised client device.

If malware is installed on your device that monitors keystrokes and/or the screen or actively targets specific programs looking to extract data from them, a lot of damage can be done in a very short span of time.

Unfortunately there are very few mitigations that are effective against such attacks, the only bullet proof solution is to not install the malware in the first place.

It is bad if you get hit and you notice immediately but it is a whole ’nother kettle of fish if you don’t notice and you have a silent piece of malware monitoring you for an extended period of time.

In this case you will slowly access every secret you have and the malware would be able to intercept each secret individually and no amount of realistic mitigations would be effective.

Mimiri Notes has the benefit of being unknown at this point in time and thus it is extremely unlikely to be directly attacked by malware, but that is only a matter of time.

There are things we could do and in time we probably will harden Mimiri Notes as much as practical against such attacks but ultimately we can only do so much, if you can access the data so can the malware. We can limit the window of opportunity but sooner or later you will need to access the information of interest and at that point no amount of extra layers of security will help.

There is a lot you can do yourself to actively protect against malware but that is a huge topic in its own right that maybe some day I will write a post about, but that day is not today.

Loss of Physical Control

We will group 11-14 under the heading of loss of physical control.

If your device is stolen by someone interested in the economic value of your device the effort they are willing to put into accessing your data is likely to be quite low and so even basic mitigations are likely to be effective.

The primary client side mitigation we employ is to never persist any unencrypted data to disk.

Unfortunately we have very limited control over what the operating system does in terms of swap and hibernation, and while we have never heard of an attack taking advantage of this it seems likely that a sophisticated attacker could potentially extract information like this and as a result I would highly recommend using full disk encryption if this is a scenario that concerns you.

If your device is captured in a locked state but powered on you operating system is likely resistant enough to be functionally equivalent to a powered down system.

Now, in all these cases the password you use for your operating system and/or full disk encryption needs to be not terrible, how not terrible it needs to be depends on the specific implementation - BitLocker in combination with TPM should be pretty effective so long as your password is not something absolutely atrocious like 1234 or P4ssw0rd!, and I would expect other competent solutions to similarly reduce the effective requirements of the password but this is something you may want to research a bit if you are concerned.

The really hard case to mitigate is if your device is stolen while powered on and unlocked.

On iOS and Android we have implemented a lock where after the app has been suspended for over 60 seconds biometric authentication (e.g. FaceID) is required to unlock it again adding an extra layer of protection against loss of physical control.

We are planning on adding something with a similar effect on PCs. (I will update this post when that happens)

But if you lose control of your device while using Mimiri Notes as it stands at this point in time you lose.

We could and we probably will at some point make it possible to add an extra layer of security to specific notes that the user considers to be highly sensitive but this does come at the cost of usability.

It would be advisable to log out of Mimiri Notes before entering into a situation where there is a high likelihood of loss of physical control.

Loss of Environmental Control

Lastly we will group 15 and 16 under the heading of loss of environmental control.

If you are sitting alone in a locked room minding your own business there are a lot of things you won’t have to worry about. But if you are at work or you don’t live alone there are a lot of opportunities to do something so simple as observe your monitor.

If your secrets are plainly visible on the monitor anyone walking by could observe them and so could security cameras. Likewise, if you are screen sharing and you need to access some of your notes you may open Mimiri Notes and find it showing a password for everyone to see.

It is perhaps worth understanding that Mimiri Notes started out as essentially just a set of organized encrypted text documents, not as a password manager.

But seeing as we are using it for passwords it seemed prudent to harden it at least a little against prying eyes and we introduced a syntax for hiding passwords from plain view effectively letting it show up like p`********` instead of the plain password.

The user can still copy it or reveal it as needed but at least it isn’t plainly visible.

The other significant mitigation we implemented is: Hiding Mimiri Notes from screen sharing so you do not accidentally flash it to everyone watching.

Unfortunately, we have yet to figure out how and if it is even possible to do with X and Wayland, but on both Windows and MacOS this is a readily available feature.

We will continue to add mitigations like these as we get ideas.

In Conclusion

Mimiri Notes is not perfect and, like any security product that has to operate in the real world, it never will be.

But we do believe we have managed to make a tool that if handled correctly can be safe enough for any scenario that any normal person is going to find them selves in.

We haven’t done a lot to protect the user from themselves and we don’t plan to do so at least not in any coercive way, if you want to use 1234 as your password we will warn you but we will not stop you.

If you want to share your screen and show Mimiri Notes, you can, but we try to help you to not do so by accident, similarly no one forces you to use the p`` syntax for password but it is available to be used.

We believe in education and that you should, and do, know better what is best for you in your circumstances than we ever could.

Mimiri Notes