Hah, I saw this just after sending a newsletter issue on my password management solution, which is based on passage [1] (a fork of password-store [2] that uses age [3]) and YubiKeys.
The main feature is some protection against post-compromise exfiltration: even if an attacker fully compromises my laptop, they can't extract the whole vault.
I was waiting for a solution to store age keys on a security key, and it's great that it's now possible with YubiKeys.
I currently use smart cards to store my GPG keys, which works even on Android, as there are some that support NFC, so I can use them with the OpenKeychain and Password Store apps. I need to have passwords available on mobile, as often when I'm traveling I don't want to lug around a laptop. The QR code solution you suggest doesn't seem optimal.
Would it be possible to achieve the same workflow with age and NFC YubiKeys? I suppose it would need a native mobile app for that to work.
If using the OpenPGP applet over NFC is possible, then it's almost certainly possible to use the PIV one with age keys too!
The Andorid password-store app is working on an implementation of age in Kotlin (https://github.com/android-password-store/kage) and I think they already support passage stores. Maybe you could open a feature request for age-plugin-yubikey compatibility? If you do, feel free to tag me, and I can help make sure the formats are well specified.
According to the github linked in the top level comment, it's pronounced like the Italian "Aghe", which translates to "needles". "Aghe" sounds like "Ah-gay". Not sure why they picked that name.
The hard part of building a (good) password manager is not actually the encryption backend (gpg, age, etc...), or the frontend (CLI, dmenu, GUI...), or the sync (git, CRDTs, whatever), or even integrating the biometric unlock -- but correctly integrating it with every app and website that expects to take your passwords.
AWS console has three fields (account, user, password), most websites will take your password and/or MFA code on a separate page, some apps will use Electron, some will use native widgets, some will use NON-native widgets (like GTK/Qt on Mac/Windows), some apps (like games) will be running in full screen...
It's a world of madness and I have huge respect for the password managers that actually try to solve these problems (even if most do it only half-decently).
I've yet to see password manager I'd trust to mess my browser with. I don't want autocomplete. I want convenient and controlled access to my passwords and that's about it. Every password manager wants to run its non-opaque JavaScript on my login pages which I can't allow.
What I need is:
show button on top bar if current website has stored passwords. At this point no logins/passwords are requested from the password manager, only website URLs (or even hashes).
After I click this button, request and show list of logins saved for this website. Let me choose login if there are multiple. Otherwise alter browser context menu.
Now when I right-click on text input, add items like "Insert login: vbezhenar" and "Insert password for vbezhenar".
And only when I choose "insert password" - actually request password from the password manager.
That's the only sane UI. Until I find it or write it myself, I'll continue to copy-paste passwords around.
It's a sad state of things where password managers are still not as usable as text file.
This seems _pretty_ close to how Bitwarden works. In fact, unless I'm missing some requirement, it's close enough that you can do that yourself if you just manually click the "copy username" and "copy password" buttons instead of the usual "just fill crap from this login" button. Those buttons aren't any harder to reach either, they're just smaller.
Not entirely sure, to be honest. I guess you could just not even install the browser extension and just use the separate application. It'll probably be less secure (don't think it'll know what page you're on, so it can prevent phishing) and more annoying, but if that's a hard requirement it should work.
Maybe I’m missing something, but why would you trust any app to securely store your passwords (or store them at all) but specifically mistrust their browser extension?
1. Browser extension interacts with every website by design. And it means that every website has a direct path to access my passwords if extension is buggy. I don't know how to solve this issue without special browser API, but requiring user to click for every step before sending actual data might reduce that attack surface compared to convenient automatic mode.
2. Web apps are wild and doing wild things. Even humans might find it hard to fill the form correctly. Extension can only observe DOM. Who knows which inputs it will fill with my passwords? I don't trust myself to write that kind of auto fill code which would work reliably. And if I don't trust myself, I definitely don't trust others to do so.
I don't claim that extensions are malicious. That would not make sense indeed. Just that extensions are things I don't trust to be implemented correctly, especially with convenient auto-pilot mode.
Keepass and derivatives like KeepassXC (preferred) have configurable autocomplete which emulates a keyboard and seamlessly moves between UI fields using any key presses you want. By default it switches windows with Alt Tab and Tabs between fields.
I really don't understand this trend that has popped up int he last few years of putting the Password on a separate page from the username. The Password manager usually catches it but sometimes does not. It just needlessly adds an extra step/page to the log in process.
This is sometimes for SSO. If your user logs in with some form of SSO, after the username entry, you get redirected to your IdP, instead of prompted for a password.
It allows you to determine the authentication method based on username. Some users may need SSO, some may need email login, and yet others may simply use a password.
As others have said, it depends on the authentication method.
Some users may not even have a password. They'll be sent an email or sms with an authenticated link. So to put a password box in front of them may be confusing.
But it's definitely annoying to those of us with general passwords.
for what it's worth, the pa -> browser input "integration" feels a lot better than you'd think, but takes a little bit of effort to setup.
check out the contrib/ dir for some supported programs - get one of those in your $PATH, and set up a hotkey to launch it.
now, whenever you press the hotkey, a list of your passwords will show up, which you may type to filter. when you press return, the password you selected will be automatically typed into whatever you have highlighted, whether it's a password field in a browser, or vim. the neat thing is that the password never touches your clipboard since it's typed directly by either wtype or xdotool.
the workflow really only takes a second or two once you have it setup, and feels very nice, imo!
> The hard part of building a (good) password manager is ... correctly integrating it with every app and website that expects to take your passwords
What's wrong with plain old copy-and-paste? (I know there are probably some security concerns under X11, but Keepass, for example, will automatically clear the clipboard after a few seconds at least.) I use Keepass and 1password.com, but I don't use any of their autofill features; I just copy a password when I need it and paste it to where I need it.
I think a user-friendly, secure, and reliable sync is the much more difficult part of implementing a good password manager.
I currently have 429 items in my PM (it happens to be 1Password, specifically because it's extremely good at figuring this crap out). I almost never have to search for anything; even if I do, I can easily update the entry, so that it understands the context, in which a given credential can be valid; e.g. I can use my Blizzard login both on "https://battle.net", and in "app://sc2" (StarCraft 2). If I have a main+alt account, it will allow me to choose from the two, not 400+.
It's the same as with using contactless payments with a smartwatch, it saves you 10 seconds here, a minute there - and over the course of your day, day after day - it starts adding up.
> I think a user-friendly, secure, and reliable sync is the much more difficult part of implementing a good password manager.
CRDTs solve this problem quite generally. I've never tried actually implementing sync from scratch in a desktop/mobile app, but the theory behind CRDTs is quite easy to grasp and makes a lot of sense. I'd say it's quite a bit harder to sync plain, old files, because the only metadata you have available is things like names, access/modification times, etc and they tend to be huge binary blobs, like photos or music, so the problem of automatic conflict resolution gets quite interesting.
BTW look up Apple's CloudKit. I've done a "let's pretend we're on a 1990s Internet" challenge[1] a while ago, and it's amazing how reliably everything syncs, even if the devices are online for maybe 1% of the day.
I've been using a homegrown solution that is very similar to this, for about three years now.
The way I access it is via Blink app on iPad/iPhone, the terminal on mac, WSL on Windows. Copy and paste the password, clear the clipboard (done automatically when using the terminal). It takes a few extra seconds but works anywhere, and I can add password-specific notes for cases like your AWS example.
Putting the password in the clipboard is the least safe part, but I definitely prefer this over giving some random app full access to my browser / system.
That's specifically the part I was extremely unhappy with, as a former pass+dmenu user, who has migrated to 1Password. It's a cold, autumn evening, we're down from the mountain hike and running to catch the last train home to return from the trip, and I need to buy the ticket either before or as soon as I'm on board; my stiff fingers are trying to make things happen on a phone with a small screen, poor reception, and a slowly dying battery. I need that password *now*.
It would be nice if a password manager could take care of detecting a page reload/change and auto fill the rest of the form, but I guess the risk of skipping through pages without any user interaction is too large for users (including myself) to trust it. I think the problem rather lies in how difficult modern UI makes it to sign in sometimes
This is precisely why I stopped using KeePass, the browser extensions just weren't good enough.
Bitwarden is significantly better, though it also occasionally does the thing where the prompt to save a new password disappears, because of redirects or something.
I've retrained myself to always just create the account first in BW instead of rely on that prompt mechanism. Once the account is created in BW, you can just auto-fill it into the u/p fields.
It would be nice if there was something like ad blocker filter lists for password managers so that every new password manager doesn't have to keep this up on its own. Maybe there is and I haven't run across it.
Yes, and I would add password device sync for multiple operating systems and browser extensions. Without sync, hundreds of unique, unmemorable passwords are not much value.
That's true, the simple & fast UI (TUI/GUI) helps a lot. However, I would not extrapolate it to a huge problem. I am person, who have written own pass/passage implementation [0], just because I disliked how many steps I need to make to select the password for the form input, modify it or sync secrets.
Initially, I had used the `gopass`. It is probably the most convenient way to start using the password-store. It is cross-platform, 100% compatible with pass & pass-otp. To copy the password, you basically type the part of the file you are looking for. If you type "gopass show github", it will display a TUI, where you can select the file you are looking for (let's say you have two files "personal/github.com.gpg" and "work/github.com.gpg"). Unfortunately, the search function was far from perfect, and it had a problem with typos like "gtihbu" at the time, when I was using it.
To get rid of this issue, I decided to adapt pass/gopass to use `fzf` [2]. In the same time, my .password-store/ dir was rapidly growing that made me think about implementing pass from scratch. I improved the implementation to have better caching, synchronization between machines/mobile, but more importantly - a simple `secret [arg]` command that will execute `fzf` to list all known creds and simplify selection of the password. Of course, it accepted an argument that was limiting the results, which is great when you need to get back to the previous credential to retype something.
The introduction of `fzf` made it really convenient, and I decided to add more commands with fuzzy search, such as:
- `otp` - limits results files containing TOTP/HOTP token, calculates and copies it to the clipboard.
- `secret-edit`, `secret-remove`, `secret-show`... aliases to sub-commands that open `fzf` command in multi-selection mode, so by utilizing space key I could select what files are meant to be modified, removed, displayed etc. Quite handy for mass-edit.
- `secret-qr` - similar to the gopass' feature, but it made a simplified way to create and display QR codes dedicated to share contacts, WiFI SSID+password combination (etc.) to someone who was asking for creds from me.
Awesome, but alt-tabbing to the terminal got me annoyed after a few years of using it that way. I started pursuing for more sophisticated interface. I decided to give `rofi` [3] a try. I managed to fork that repo and also adapt to my convention of using password-store, but I left i3 for a macOS.
Currently, I have started working on a browser extension that takes care of suggesting password-store creds (based on the path, input parameters, location on the website etc.) similarly to what uBlock Origin does. That configuration is passed to my pass implementation, so on the github.com, my browser have only "work" and "personal" auto-suggestion, when I am focusing the text input.
I plan to create a similar app to Shortcat [4], but it will preserve the information what credential has been asked for the focused app. I think, with VoiceOver assistance, it is more than possible to mitigate the need for alt-tabbing to the terminal for electron/native apps.
[0]: It is a private repository, maybe when it will be polished enough I will open-source it.
Edit: About the AWS login form. I strongly recommend giving `aws-vault` (https://github.com/99designs/aws-vault) a try. It helps you skip the login form with a simple command e.g.: "aws-vault login acme-corp --duration 2h". I find it better than `aws-mfa` on my dev machine.
From a cursory scan, this looks like it doesn't support key wrapping -- the private key ("identity" in age's parlance) is stored unencrypted on disk.
This is arguably a non-issue for most use cases (disk access is "game over" under most threat models), but it's nice to have e.g. for sharing configurations between multiple machines over a public channel (like a dotfiles repository). It would also bring this roughly up to "spec" with what other password managers do (i.e., in terms of requiring a "master" password that unlocks the vault).
Thanks for sharing your rationale! I tend to agree -- the practical alternative for Linux anyways is some kind of key agent, and it's unclear to me (having written a few password managers at this point, including an age-based one[1]) that the attacker model for an agent is any different. The only advantage is the "public" channel one I mentioned, and that can of course be done out of band.
And since I forgot to say it earlier: excellent work!
This is interesting. I’ve been using Bitwarden for a long time now but I didn’t realize how convenient a command line password manager would be. Still though, not being integrated with iOS is a non-starter for me but I really like this idea.
It would be cool to see the other apps like Bitwarden adopt a CLI to use passwords with other command line tools. Kind of like the Apple Keychain API but easier to work with in a *nix environment.
Encrypted volume synced with syncthing, everything basically stored as plain text and (like you, i think) a few shell scripts to throw passwords into the clipboard.
Would your thing work with a simple synced volume?
What? Call it "paw" then. No one is gonna see "pa" and think it's pronounced "paw", and no one is gonna hear you say "paw" and think the invocation is "pa"
None of the above. No one pronounces "aw" like the a in Apple. And most people do dinstinguish between "a" and "aw" by pronouncing the latter more like the a in "awe".
"pa" would be pronounced between these two, depending on speaker:
/pɑː/ — if I had to use "normal person's IPA", "pah" would be my attempt. This, to me, is the more common pronunciation. Should rhyme with "bra" … assuming you pronounce that like I do.
/pɔː/ — like "paw" or "awe". This is a region-specific dialect, to me. This appears to be the one you're familiar with.
If papa is a stand-in for father, I'd pronounce it with a long a, as in father. If papa is a stand-in for grandfather, I'd pronounce the first a as in apple, and the second as in paw. But of also spell it papaw. Seeing 'pa' in its own, I'd never think it was pronounced like paw, unless I was reading something written in Hungarian.
What regional dialect of English are you using that the word "pa" is pronounced any differently? To my West Coast / NorCal ears, urying to use a stressed, second-a-in-"banana" pronunciation, is really weird, as is schwaing it to the point of "uh". The unstressed-short a (the other two 'a's in 'banana') sounds the best, and is perfectly reasonable to describe phonetically as "aw".
I would write that as either "faw lah lah" or "fuh lah lah" or maybe "fuh luh luh". The "paw" sound is undeniably how I'd refer to my father, not "puh", or "pah", though I could imagine like a New England accent using the latter.
Or, who really cares how people pronounce it? It's very unlikely for there to be many scenarios where someone was trying to find this, but couldn't, just because they heard someone say it wrong. Most people will find it through textual means. I don't get the obsession with projects specifying the pronunciation in the README. If anything it just means you failed at naming your project.
I don't think age does any real password extension. So if you are used to something that does (GnuPG's 0.1 second extension for example) you might want to add an extra word or two to your passphrase.
Pet usability peeve triggered here. If we create a system that completely depends on the strength of a password/passphrase we have to give the user concrete advice on how to create a password/passphrase that will be strong on that particular system.
This password manager seems to use private keys, so there is no passphrase used for encryption here.
However, generally speaking, age uses scrypt for password key derivation, with a default work factor of 2^18 (1 second on modern machines). Unlike GnuPG's S2K, scrypt is both CPU and memory hard.
Then how short can I make my passphrase? It should be shorter than with GnuPG but no one knows how long to make the passphrase for GnuPG either...
This gets back to my original peeve. This sort of thing has to be worked out for the user. I looked through the available documentation. Was I as a user expected to look through the source code and figure it out for myself?
My understanding is that, even with a CPU and memory-hard KDF, the standard recommendation is to use a strong and difficult to guess password. It’s meant to be a layer of protection against cracking, not an opportunity to use a shorter password than you normally would.
Questions like these are indistinguishable from trolling. You've responded to the direct, common-knowledge answer to your question by repeating the question. Please stop doing this.
I can't edit my post so I am replying to it. It has been a while but I should still apologize...
I managed to get two things wrong in one post. As a result I ended up disparaging the Age project for no reason and causing confusion about the Pa project. I continued the confusion in subsequent replies.
I will try to be better about this sort of thing in the future and am sorry.
I'm not following. This encryption model here is a master private key, so there's no master password involved. Are you referring to the generated passwords? If so, the default seems reasonably long (and is outside of age's scope anyways, since it's just the encrypted content).
If you feel yourself technically proficient enough to comment on cryptography (mostly PGP apologia), then you should be capable of looking at source code to figure out whether or not something "does any real password extension".
If anyone else (i.e. "a user") made this mistake, I'd be more sympathetic. But not for you.
You don't get to have your cake and eat it too. Are you a cryptography expert, or aren't you?
If yes, then failing to bother to check the source code is a faux pas.
If no, then I expect you to stop trying to argue as a cryptography expert the next time someone points out that PGP is bad cryptography.
I don't care which you choose. I only ask that you stick to it.
This, too, is a troll comment. Obviously, they're using scrypt, and so your claim upthread (and here) that they might not be doing any "work extension" is pre-falsified. Please stop trolling on these threads.
My age+YubiKeys Password Management Solution — https://words.filippo.io/dispatches/passage/
The main feature is some protection against post-compromise exfiltration: even if an attacker fully compromises my laptop, they can't extract the whole vault.
[1]: https://github.com/FiloSottile/passage
[2]: https://www.passwordstore.org
[3]: https://age-encryption.org