Anki Encrypt [support thread]

[Eltaurus]

A support thread for Anki Encrypt add-on and the associated Card template.

Anki Encrypt is a toolkit for adding a layer of security to data stored in Anki Cards, which might help keep information private when Cards are synced via cloud, or potentially exposed in other ways, such as being reviewed on a workplace PC. More info on the GitHub page.

How to use

After the add-on is installed, the Encrypt button should appear on Anki Editor’s toolbar:

When the button is pressed with any of the Fields selected, it opens a separate window to enter a string of data:

After pressing Ok, a hash, generated from the string, is inserted into the previously selected Field (the original information is not stored anywhere!):

Reviewing Cards

With the provided Card template, reviews work similarly to Anki’s Basic (type in the answer) Note Type, except the typed answer is not immediately shown, and on the back, the Card only indicates whether the submitted answer was correct or not as a whole, but doesn’t reveal the true answer in any way:

Also, a hint for the learnable data can be added to the special Field and peeked at during the reviews by hovering the cursor. The submitted answer can be viewed on the back in the same way to check for any typos:

Security concerns

Algorythm

The hashes are generated using SHA-256 with a 16-byte salt and are practically irreversible:

1. Brute-force attacks are ineffective due to the size of the hash (provided the hashed data itself is unique enough!)
2. Rainbow table attacks (in case the same data is leaked somewhere else) are protected against by the use of salt
3. Birthday and length-extension attacks are possible, but pointless in the context of the Anki Cards (they can only make a Card to display an incorrect answer as correct, but not expose the correct answer itself)
4. The hashes are even reasonably resistant to quantum decryption, which should make them future-proof in the face of “harvest now, decrypt later”

Guidlines

0. Do not use short or common strings of data. The rule of thumb is to use at least 10 characters (for a random sequence) or at least 5 unrelated words (for a passphrase). Hashes generated from less secure data can still be reversed by brute forcing through a character set or a dictionary, respectively. Also, the hints added to the Cards should be personal enough to not make the answer obvious to anyone but the author

The main risks associated with the use of the Cards do not come from leaking stored hashes, but from exposing the information typed during the reviews. To lower the chance of malicious programs reading the answers, the following rules should be followed:

1. The Encrypt Cards should be put into a separate root Deck. Do NOT mix them with Cards of other Types downloaded somewhere else (even as a subdeck). Malicious Card scripts can persist throughout an Anki review session and gain access to information typed on subsequent Encrypt Cards. A return to the Deck screen, when switching Decks, resets the webview, avoiding this issue when a fresh review is initiated (as long as untrustworthy Cards do not appear in the new session)
2. Install only trusted add-ons. Anki add-ons can read the info entered during the reviews on the desktop app. Add-ons can also modify Note Types, inserting malicious scripts into originally safe Cards and compromising reviews on mobile apps and separate clean Anki installations through them
3. Not using automatic add-on updates eliminates the possibility of a supply chain attack, which might compromise previously trusted add-ons
4. Using an anti-virus to prevent external programs from accessing typed data (this is a general prescription, not limited to security of Anki)
5. Applying obfuscation to the memorized data, instead of learning it as is, can help reduce the risks listed above

Memorization

1. Because the stored hashes are irreversible, the Cards cannot help recover the original data if it is forgotten. They can only aid in memorizing things more reliably than by using any other way not involving SRS. For this reason, it is practical to choose review intervals for a Deck with encrypted data as small as possible and use an external password manager to deal with failed reviews
2. By the nature of the data memorized with such Cards, the Leech action of the respective Deck is better set to “Tag only”

[dae]

This is certainly better than storing passwords in plain text, and I think you’ve documented the risks fairly well. I would recommend you implement a salt, as rainbow tables can be a real risk with the password lengths the typical user uses.

That said, I still think the majority of users would be better served putting their passwords in a password manager instead. They are built with security in mind, and don’t risk you losing your password if you forget it.

[Eltaurus]

@dae

I think you’ve documented the risks fairly well

I’ve also added a warning regarding cards’ JS, following your comment here. Can you comment on whether returning to the Deck screen is enough to purge unwarranted JS from the webview? It seems to work this way on Desktop, according to my tests, and on AnkiDroid, it shouldn’t be the issue in the first place, as the current reviewer resets the webview on each card flip, afaik. However, I don’t know anything about how this is treated in Anki Mobile.

---

@dae

the majority of users would be better served putting their passwords in a password manager instead

That might be, but as described in this comment, a password manager by itself is not a perfect solution either. There are also cases when retrieving the information quickly is important, and nothing can beat having it directly in your memory.

[dae]

Yes, navigating to the deck list/overview screen currently loads a new page, so should clear out any current JS. This may change in the future, though hopefully we’ll also start isolating card content into an iframe.

[Eltaurus]

The add-on and the template are updated to use hashes with salt. The unprocessed typed answer, inserted by Anki on the back of typing cards, is now hidden by default using css to avoid accidental exposure.