@bitwarden
Soo... I have recived some notifications of support tickets from you, for an email address of mine that is not connected to a Bitwarden account.
Should I be worried?
@Seetee Hi Kenneth, that definitely sounds odd! Can you please reach out to our support team directly so we can investigate? https://bitwarden.com/help/
š Announcing Passbolt v4.8.0 "Angel - Massive Attack" š¶! This release of our password collaboration manager introduces the first version of our Manifest V3 Chrome extension, new tools to purge audit logs and check failed email queues from the command line for better SMTP debugging. Significant performance improvements are included, with more to come in v4.9. š ļø
Doing software engineering (well-ish) is pretty hard to imagine without working in version control, which most of the time means git. In a practical setup of git thereās the question of how do I get access to the code it stores ā how do I ācheck things outā? ā and optionally how can others verify that it was indeed me who did the changes ā how do I āsignā my commits? Recently Iāve changed my mind about whatās a good combination for these two aspects, and what tools am I using to do them.
Access Options
In broad terms git repositories can be checked out either though the HTTP protocol, or through the SSH protocol. Both have pros and cons.
Having two-factor authentication (2FA) made the HTTP access more secure but also more setup (no more direct username/password usage, rather needing to create extra access keys used in place of passwords). Credentials were still in plain text (as far as I know) on the machine in some git config files.
The SSH setup was in some sense more practical one (creating keys on your own machine, and just passing in the public key portion), though there were still secrets in plain text on my machine (as I donāt think the majority of people used password-protected SSH keys, due to their user experience). This is what Iāve used for years: add a new SSH key for a new machine that Iām working on, check code out through ssh+git, and work away.
When Iāve recently came across the git-credential-manager tool that supposed to make HTTP access nicer (for various git servers and services), and get rid of plain text secrets. Of course this is not the first or only one of the tools that does git credentials, but being made by GitHub, it had some more clout. This made me re-evaulate what options do I have for SSH as well for similar security improvements.
Thus Iāve found that both 1Password and KeePassXC (the two main password managers I use) have ssh-agent integration, and thus can store SSH keys + give access to them as needed. No more plain text (or password protected) private keys on disk with these either!
Now it seems there are two good, new options to evaulate, and for the full picture I looked at how the code signing options work in this context as well.
Code Signing Options
When signing my commits to authenticate authorship, itās possible to use PGP/GPG (the āclassic wayā), or now also SSH keys (as detailed, for example here or here).
The GPG setup is well established, and also links my commits to my identities used elsewhere (e.g. signed emails sent to mailing lists that care about it, with the key linked from this siteās frontpage). This of course is not always needed or desired, but it decouples the identity from the code hosting platform. Thereās some serious downsides as well, though: GPG signing keys are not supposed to be numerous (just a single one), and thus if I use multiple machines to work on, I will have to take my private keys with me between machines, for example making copies of them. Or if not making copies, then have them on hardware keys (that have other problems with backups and all that, if I got it right the last time I tried to understand the process).
The SSH key commit signing is much newer (need git version at least 2.34), but itās also simpler: add a key to my git hosting service, sign commits with that key, and thus the service can match things up and show that match. I can add as many keys as machines Iām working on if needed, no need to transfer or copy keys between machines, and I can also choose use some keys for login only or code signing only.
A third party trying to verify these signatures, though, would need to get the keys from the hosting service (Iād find it surprising if people would distribute their commit signing keys out of band the same way as they do with GPG public keys, since there are likely more of them). Hence it git hosting services will need to make the userās keys available (as they do at the relevant username.keys URLs, e.g. mine on GitHub and GitLab).
Also canāt forget to add the relevant keys to the list of allowed signing keys locally, and all the other relevant setup (see e.g. the GitHub and GitLab docs). There are a bit too many places to update, but itās mostly set-it-and-forget-it. After that, once started to sign commits, adding the --show-signatures flag to the commands that support it (git log, git show for example), should show the signatures.
My Winning Combo
Looking at the opions above, thereās a matrix of options that we can use, and hereās what I think about them:
GPG signature
SSH key signature
Git Credential Helper
Extra setup
Simpler
SSH clone
The usual
Most convenience š
Convenience matrix of Git access (rows) and commit signing (columns) optionsReally, where I want to be is just SSH keys for everything, even if they are imperfect, but they have the most number of puzzle pieces to fit.
SSH Key Security
While previously SSH keys were really just held as files in your ~/.ssh folder, most likely, recently Iāve found (tada!) that the password managers I use can also store & serve SSH keys: see in particular 1Passwordās SSH documentation and KeePassXC docs (scroll to SSH Agent Integration on that page), though Iām sure other password managers can do this too.
1Password
The two password managers listed above handle things quite similarly. 1Password is a bit less hands-on, though, the default settings work pretty well.
With this things generally work, and relatively easy to reason about things. When things are less clear, it might be just a debug check-away away from seeing the keys added to this alternate agent:
KeePassXC, being open source, is my preferred solution of the two, though unsurprisingly itās the more awkward one to set up. The main differences from 1Password include:
needing to generate the keys externally to the password manager (rather than having built-in ssh keygen) ā this is a con on usability but a strong pro on basing security on the established tool, rather than potentially questionably reimplement it
uses the main SSH agent, so no extra setup is necessary in most of the tools ā this is a potential pro on usability for configurations, but a potential con that the worflow and config of loading keys into the agent needs a bit more understanding to be both ergonomic and safe to oneās level of paranoia
the key use confirmation defaults to āokā on pressing Enter on the pop-up (rather than Cancel) ā this is a pro on usability, but con on āfailing openā rather than closed
Itās still a pretty simple workflow, and itās quite interesting to see how many things KeePassXC learned to do as well.
Experience
Thinking about the various threat models to my SSH crendentials, this setup adds one more layer to the defence in depth, and it does feel more relaxed already (relaxed from a point of stress I didnāt quite know I had before).
Picking the SSH key based login and signing feels like using the most appropriate tech for the moment, and there are still knobs for people to adapt it to their security levels (different SSH keys for login and signing, passwords on the keys themselves, etcā¦)
This setup works very well when I want to be notified whenever a toolās using the SSH key so it would be more obvious if a stray process is trying, say exiltrate the keys. On the other hand this breaks down when git itself is running background processes, such as git-maintenance, so thatās not something that I could use here. So far out of (literally) thousands of codebases & repos Iāve used that maintenance setup exactly once, for convenience. For me it is not a major loss, then.
The one bit that feels a step backwards is that having the SSH keys in the password manager and carrying it around counteracts the āseparate key for each systemā arrangement. This might just be part of getting used to new processes, and not an actual downside.
Further Thoughts
In cybersecurity yesterdayās best practices might be inadecvate today and ālast weekāsā practices might be outright dangerousā¦ Gonna keep revisiting this setup more broadly and in terms of details, as I learn more.
Itās a good question why even do code signing (besides having a āverifiedā check mark, which alone doesnāt mean much if not part of a verification process), though this needs some more space to unpack. For the time being Iāll assume that signing is better than not signing, if nothing else than as a forward looking prep for better audit processes down the line.
Thereās really a question around having too many things in a single password manager: nowadays it can be the complete āroyal flushā of password, TOTP, SSH key, recovery codes, passkeyā¦ and likely more bits that I might not be using yet? This does make me uneasy, and likely a scale on which usability and security will adjust over time (such as. bundling and unbundling various cybersecurity aspects).
I might also actually misunderstand various things above, if so, Iād be very keen to hear, just drop me a line!
Any of you aware of a #PasswordManager that works with GNOME, Mozilla, and Thunderbird that actually gets out of the way?
What I'd like to see is my password store being automatically unlocked by my normal login password, locked when the lock screen comes on, and re-encrypted when I change my login password.
I know I can do some of this with Seahorse and pam_gnome_keyring, but this doesn't help with the Firefox/Thunderbird password manager.
KeepassXC + syncthing/nextcloud if your only mobile OS is android. There is a keepass client for iOS, but I don't know if it's trustworthy.
If having an available-anywhere web interface is important to you (or if not having it's own sync system is a deal-breaker) I got a family member on BitWarden, and they're pretty happy with it.
LastPass users targeted in phishing attacks good enough to trick even the savvy
Password-manager LastPass users were recently targeted by a convincing phishing campaign that used a combination of email, SMS, and voice calls to trick targets into divulging their master passwords
š Discover how ZIT RLP, a regional center for university IT in Germany, has enhanced their machine credentials collaboration and security by integrating #Passbolt's open-source password manager. Watch the video to learn more about their journey: https://hubs.li/Q02tXlkb0 š
Frau Yaki, zum millionsten Mal lege ich ihr ans Herzchen sie soll doch bitte einen #Passwordmanager benutzen und sie siht mich an und sagt: Du bist mein Passwordmanager. Tja, kannste nix machen.
š Introducing the first stable release of #Passbolt Windows Desktop App! š
Secure password sharing is now available as a production-ready desktop application for Windows.
It successfully passed a security audit by #Cure53. Discover more about the technical foundation, password collaboration features and security details of this release in our latest blog post: https://hubs.li/Q02sGt0V0
Upgrade to Passbolt 4.6! This release enhances password collaboration through features like the automated Health Check of a Passbolt setup for admins, SSO support for Microsoft AD FS enabling easier access, and essential performance improvements. š Ready to take a closer look? Watch our latest video https://hubs.li/Q02pLfq10 and check out the detailed release notes https://hubs.li/Q02kDVy00.