Support password memorization

Suggestions
#1

Background

Passwords are one of the most useful things to memorise, yet Anki has no real support for them or other sensitive data. There are basically two options users have:

  1. Create notes with their passwords in cleartext. In case anyone isn’t aware: Don’t do this. Both AnkiWeb and your local collection can too easily expose this information to attackers, or you might even accidentally leak (export) it yourself.
  2. Create notes with a prompt, but no back side. While without a doubt the wiser choice, such a card is only useful as a reminder, and unless you’re 100% sure to have correctly recalled the answer, you’ll have to go and check, which is hopefully more laborious than looking at a note on your desk.

The Solution

Every company you have a password for cares deeply about your data privacy and only stores a secure hash of your password. (Just kidding, but wouldn’t it be nice if they did.)
Anki could offer a dedicated notetype with a Password field to do exactly that: Any content entered into this field wouldn’t be committed to the database, instead it would be hashed and only the result stored.
The notetype would have one card template that prompts the user to type in the answer, but unlike the existing notetype, the back side would only tell the user “correct” or “wrong”, as only the hashes are compared.
The main point is to not store the password itself, but there could be another field to show a password hint, and maybe the card could even let the user try different passwords (to a certain extent), until they remember the right one.

What about an Add-on?

At a first glance, it looks like this feature could be provided by an add-on, or even a custom notetype, but there are a few reasons why I don’t think this would work:

  • Most users can’t read the source code to make sure an add-on doesn’t do anything malicious, so they would have to trust the add-on author. And even users who can would have to recheck after every update. It’s far more likely that people would trust Anki itself—and rightly so.
  • I’m pretty sure there are people who put cleartext passwords in Anki, just because they don’t know any better. An add-on wouldn’t reach these users, but an in-built feature might raise awareness. It would be nice if Anki helped users to protect themselves.
  • I imagine it would be hard to protect against other malicious add-ons. This might even be hard to do for Anki itself, but probably less so.
  • Adding new notes would only be possible on the desktop app, because some kind of custom dialog would be required.

Questions

@all, would you use such a feature? Are there current alternatives I’m not aware of?
@dae, do you think this would fit into Anki?

5 Likes
#2

Looks overly complicated to me. There are password managers and already everyone could hide some password notes in their thousands of Anki notes without it being recognisable that it is a password

3 Likes
#3

Since you’re asking, I personally don’t see any benefits in trying to memorize chunks of meaningless, unconnected information (as passwords typically are), so I don’t think I would use such a feature.

2 Likes
#4

Do you mean the implementation or the application?

I use a password manager, but they can’t compare in convenience with memorised passwords. They have to be set up for every device you use, synchronising them is a security concern in itself, and of course, you usually need a password to access them. :slightly_smiling_face:

I wouldn’t rely on sheer mass as a protection. No matter how large your collection is, extracting something like a credit card number is still trivial. Less structured data will require a more sophisticated approach, but nothing that can’t be automated in this day and age.
Deliberately scattering sensitive information is again a security concern, as you will lose track of it, facilitating accidental leaks. And isn’t it also pretty inconvenient?

Fair enough! I’d also rather not do it, but effectively protecting your data without memorising meaningless information still seems to be an unsolved problem.

2 Likes
#5

I use a password manager and don’t currently memorize passwords using Anki, but if this feature was implemented, I would be interested in trying to memorize some important passwords in case my password manager is not accessible for some reason. I agree that having passwords memorized is more convenient.

3 Likes
#6

Other people have thought about using Anki for remembering passwords, too: e.g. Memorizing passwords with Anki & 1Password · Andreas Fuchs' Journal So there should be some demand for such a feature.

 

If this feature were built in as described I guess that people would ask about the ability to actually reveal/show the correct answer. Such an encrypted note feature is indeed pretty common e.g. in Evernote, Apple Notes, etc. and useful in many cases.

I think there are a lot of people wouldn’t understand the fundamental difference between such encrypted notes and your one-way hashing true/false feature. So you’d have to explain a lot and still get unhappy users that can’t be persuaded by security concerns and those might see this feature as another reason why Anki is much too complicated and ignores the wishes of “regular” users … But I guess this could be solved.

 

Personally I don’t really need it: I’m typing pretty slowly on the keyboard of my phone - especially when it comes to special characters. So for remembering passwords I’d only type them on my computer with a physical keyboards for both my hands. But then an add-on that opens a new console window for me with prefilled text that calls a short custom script that has stored my hashes would work for me, too …

If my assumption is correct that this feature is mostly relevant for the desktop (which might be false if you use anki on a big ipad pro): As far as I see anki doesn’t deprecate features so that new features are rarely built in. I wonder if a couple of official add-ons published by Damien e.g. here would help: This should solve the trust issue and add-ons are not guaranteed to work forever.

2 Likes
#7

Thanks for the article!

Good point. If this feature is implemented, this should be taken into account. I think it’d make sense to immediately clarify in the password prompt that this will not store the password. Seeing the hash in an editor field should also help.

I’d say Anki’s gotten quite a few new features in the recent past. And as for deprecating old ones, there seems to be no feature small enough that not one person will voice their disapproval about its removal here. :slightly_smiling_face:

1 Like
#8

Even though this sounds effective, be aware that this is probably one of the worst ways to hide your passwords, just because an attacker with access to your Anki database would have absolutely no problems trying out all of the fields (or part of them, or combinations) in at the very most days, just by bruteforce. Don’t do that.

I have to agree, I use GNU/Pass as my password manager and it generates password that are often even hard to type, let alone memorizing them.

Due to the previous reason, I would not use this feature, but nonetheless I think there is an obvious alternative that has not been explicitly mentioned so far, which is you could simply encrypt the password before storing it in the database, with a single password that the user could provide, just like most password managers work. You could also store the passwords hashed, leading to the following workflow:

  • Creating a password note: no password required, because you only hash it and encrypt it (GPG has an option to encrypt without a password, and require a password to decrypt, pretty much like public / private keys)
  • Reviewing a password note: you type the password in a field that does not show it (of course), and the result is a true / false message.
  • If the user wants to check the difference: they’re asked to unlock with their single password. That password could be remembered for some time, or for the whole Anki session.
  • Editing a note would not show the password, unless the user explicitly asks for, and then the password is again prompted (unless already typed). The user could also have an option of overwriting a password without being prompted a password.

This seems to me quite seamless: basically you only pay (by having to type the single password) rarely, when it’s absolutely necessary.

However, there is an other issue, that is, how do you prompt a password? What backend do you use? I would suggest giving a look at GNU/Pass about that, because it’s a dead-simple use case of password encryption, it’s almost a command-line library. It does not enforce a way to type the password, it uses GPG, and it stores passwords as encrypted files, so it’s really easy to modify its behavior (and also it’s cross-platform, and there are a lot of comunity-driven interactive password prompt for all the platforms).

An other feature that would probably make the difference for most “casual” users would be the possibility to import passwords into Anki, so that you don’t have to copy-paste hundreds of times. Most notably, importing from a web browser (where most people store their passwords anyways), and from other password managers.

1 Like
#9

Not sure I understand. Do you want to integrate GPG in Anki? This would be a whole lot more work than what I had in mind. I’m not even sure it’s possible, because Anki is an open system, and at some point you would have decrypted passwords lying around.
It would of course be helpful if you could enter a master password to see the password you had forgotten in cleartext. But then again you could just open your password manager.
An import feature would be cool, but also not trivial to do it safely.

#10

There are libraries to make GPG do cryptographic work. It would be “integrated” just like Qt is…

The idea is that, there is a rule that says that you must never implement yourself any cryptographic routine (mainly because if you make a mistake, which is likely because cryptography is hard, it has terrible consequences). This means that, as soon as you want to manipulate passwords, you want (at least) cryptographic-strong hashing functions, and thus probably cryptographic routine, and therefore you need a cryptographic library.

GPG is quite handy for this purpose because:

  • it is free (with meaning: FOSS);
  • it is very safe (because very used, so a mistake is quickly located);
  • it does what is needed to make my “workflow proposal” work.

Not that much. Once you have found the right library, it’s quite quick. (I wrote a password manager in Rust using some GPG bindings, and it was quite short, maybe ~100 lines for the whole logic).

Not everyone has password managers. I would even argue that the target users for this feature are the one who do not have a password manager. And the idea is to make it easy for the user, not just possible.

Yes, indeed, maybe I wasn’t clear enough, so let’s try again.
The use-case is a user that wants to remember their passwords.

Note creation

They create a password-note (or simply type it in a password-field? or in a password-tag?), and put their password in. At this point, if it’s the first time they do something like that in Anki, Anki prompts them to create a Master Password (call it however you like). In the backend, Anki creates a GPG key with this password required for decryption.
Now, the user saves their note. In the backend, encrypts the note with the GPG key (which does not require the master password), and saves in the database the hash and the encrypted password (the hash has to be generated with a cryptographic-strong hash function, with a random salt at least for each Anki program, or even for each password).

Card review

The card is like a type-in, except that what the user types is not shown (instead, black dots or similar). When the user asks for the back of the card to be shown, the password is hashed and compared with the hash. If there is a match, there is a message like “Right password!”, if not, something like “Oops, there is a mistake.” In both cases, there is a button that proposes the user to reveal the password. If the user clicks on it, the master password is prompted. In the backed, this password, combined with the GPG key, allows Anki to retrieve from the encrypted password the plain one, and shows it to the user. The master password is (maybe) retained by Anki some time, just to avoid having to type it several times.

Card editing

When browsing for a password-note, the special {field, tag, card} containing the password is replaced with something that makes it clear it’s obfuscated (black dots, a straight line, whatever). The user can overwrite it (ie. delete it and replace it with something else), and in the backed Anki does the same thing than with note creation, or the user reveals the password (master password prompted, decrypting, …) and once the note is saved again, Anki does the whole job in the other direction (re-hashing, re-encrypting, …).

This way there are plain password only lying around in the RAM. Depending on your OS, this might be safe or not, but since when you type a password it’s in the RAM anyways, it’s not more dangerous.

There are few caveats, though. How do you prompt the master password, or a password in general? I would suggest leaving this as open as possible, ie. it’s easy to replace a “standard” password prompter that would be bundled with Anki, because it’s the kind of thing that it’s better to be left to the user’s system, because it knows better than us what is the safest way to prompt a password.

About the import feature: GNU/Pass has some import utilities for the most common password storing solutions, and since pretty much all it does is what I have already described in this post (ie. it takes a GPG key and uses it to encrypt / decrypt files, each one containing a single password), it’s very easy to adapt them to our purposes.
But this is the cherry on top of the cake, not the core feature.

1 Like
#11

Passwords are something that interest me when I’m not working on Anki, but I’m afraid I think the two are best kept separate :slight_smile: Anki has a large attack surface - not only are you at the mercy of any add-ons you’ve installed, but also rogue JavaScript from decks you’ve imported from others, if the passwords are entered into the reviewer webview. And if we make a dedicated notetype or option for testing passwords, that paints a giant “important stuff here” sign that anything malicious can look for.

The idea of hashing the passwords is not a bad one provided it is done correctly (eg something like bcrypt or PBKDF), but I think it would be much safer to be doing the testing outside of the standard Anki GUI. If you wanted standard Anki review intervals, one option would be to make a small TUI app using either the Rust or Python Anki bindings; you’d likely have something workable in a few hours.

Having said that though, I’m not really sure I’d recommend going down that path. The passwords you use frequently will tend to stick in your head by the nature of repeating them frequently. And the ones you use infrequently - wouldn’t they be better placed in a password manager? Yes, it may take a bit longer to look them up when you do need them, but is that worth the time it takes to practice them, and the potential loss of entropy when you choose a password that’s not fully random but easier to remember?

9 Likes
#12

@BlackBeans, thanks for elaborating. It sounds indeed doable and would be the more powerful solution.
It’s still a lot more involved though. With the original proposal, there is a single point of concern: Getting and hashing the password without exposing it. Your suggestion would mean a couple more critical parts that would need auditing.

I can only partly agree. I think there is a middleground in frequency of use, where memorisation doesn’t yet happen automatically, yet doing it deliberately would still save time in the long run.
It’s also about confidence. Assume I lose my phone on vacation. I’d be completely helpless if I haven’t memorised any passwords, phone numbers, or credit card numbers, with which I can acces my e-mails, call contacts, and get my credit card suspended (because it never rains, but it pours, and I’ve lost my wallet as well).
All this information I’d rather not store in Anki as cleartext.

That said, I see how it would be difficult to protect against malicious add-ons or JS. I think it’d be possible, but I understand that you can’t or won’t impose this responsibility on Anki, in addition to all the others it already has.

Thank you all for your input!

2 Likes
#13

That’s why I suggested that the password prompt be detached from the Anki application.

Indeed, that’s a very problematic point. The only solution to this would be to handle all the logic in Anki core (ie. the Rust part), so that functions responsible for this could never get replaced with arbitrary code. However, even then, it would be very hard to ensure truly your passwords are safe.

This is something interesting, not much for the password topic, but more in general, I think it would be cool to detach completely the Anki logic from the client / GUI logic (maybe it’s already the case?), so that anyone could build up their own Anki client / interface.
This would mean, for instance, documenting the bindings, or even making a small tutorial on how to write a (very minimalistic) Anki interface from scratch (I personally haven’t found a proper documentation on the available Rust bindings).

1 Like
#14

The move of Anki’s business logic into Rust is pretty much finished, with a few exceptions. Although Anki’s backend is not on crates.io, I don’t see a reason why you couldn’t use it with your own UI.
A tutorial for that seems unlikely, as the development focus is naturally on Anki itself, and the Rust docs are indeed rather sporadic, but maybe with the help of cargo doc it’s nonetheless possible without too much digging through the source code?

#15

Well, there are few reasons. The first is that, so far, I haven’t achieved building Anki :frowning:, so it’s a bit hard to start developing. The second is that it’s a bit annoying that the Rust core is bundled with everything else: it’s not on crates.io (as you pointed out), and the repo contains much more than simply the logic core, so I have to manually extract what is interesting (luckily enough it’s easy to make it work with cargo).

I kinda feared it would end up with this, as Rust documentation with cargo doc is usually quite good, but it’s really descriptive (if you have a component, it’s easy to retrieve what it does, but if you are looking for a component that fits a purpose, you have to look through everything, so for common operations it’s just easier to look at somebody else’s source code).

The goal of this kind of tutorial would be mainly to familiarize people with the code base, not really to teach how to write an Anki client (it’s more of a pretext), but since that’s cool anyways, it would be a good pretext.
It also consolidates the separation of the core logic from the GUI part: if you are able to have two, completely independent interfaces (even if one of them is just a few-hours-work dummy interface), it means that the architecture of the project is solid.

1 Like
#16

I suspect your CC company would be willing to put a hold on your card even if you can’t remember its number, but still, I take your point :slight_smile:

One alternative to trying to memorize all that info would be to put it in a separate password manager that’s file based. In the event of an emergency, you only need to remember the password for that emergency file, and the URL it can be accessed from.

Did you post any errors you’re getting on the forum already?

2 Likes
#17

Nope :slight_smile: I tried long time ago (to build Anki), and did not try again since them (I don’t have enough time for that). The problem was that Bazel was interfering with my distribution, so the problem was not mainly with Anki, but with me not understanding how to make Bazel and Nix work together. I’ll figure it out when I’ll have more time (the fact that Anki isn’t already build-packaged for NixOS makes it particularly difficult).

#18

At my age, I’ve stopped using passwords that are difficult to remember.

I prefer to remember a simple “template”, which I store in Anki, and change frequently.

Here’s a template from about 5 years ago:

This is fr google123

That template is based on an idea from here:

There are other sites with good ideas. The theory is that length is better than complexity to beat the crackers.

Note the following:

  • “fr” is misspelt for “for”. To hinder dictionary crackers

  • The “123” is simple padding to produce a 9-character atom. For Anki, I would need to add 12345. The number of characters in the atom can be 9, 10, or 11, and changes on a regular basis.

  • For company names that are longer than 9 characters, I simply use the first 9 chars, or whatever the current length is from the template.

  • Most sites accept spaces. If they don’t, I use a “fill” character, which changes frequently.

  • There’s an easy bit missing at the end of the template, which tells me the date that the password was created. I use that to increase the overall length, and to let me know when to change the date. The bit at the end is stored on my iPhone. (Anki is also on my phone.)

  • Two members of my family know all this stuff - on a 50-50 basis.

  • All my passwords are in LastPass.

Thanks

1 Like
#19

If you put encrypted passwords in Anki and need a master password to handle them, you’re turning Anki into a password manager. So might as well use one of the ones already out there. One or more posts in this thread alleged that they are awkward to use. Since I have used both Apple’s “Keychain” and on KeePass on Windows, I strongly disagree that they are difficult.

#20

.

.
Is this a new, independent opinion ?

Or is it a response to an earlier post ? If so, could you quote the post please.

Thanks
.