Are there existing tools (or non-existing tools) that can simplify password sharing experience securely?
(Password manager seems a way of securely sharing password, but it usually requires registration and is guarded behind a paywall. Not simple enough IMHO)
https://cure53.de/pentest-report_bitwarden.pdf
This takes care of the paywall problem, at least.
Alternatively, age (https://age-encryption.org) or Magic Wormhole (https://github.com/warner/magic-wormhole) should be viable choices.
Things like iOS/safari autogen/auto save has done A LOT to make passwords secure for the middle tier, but older gen is still a challenge.
I don't know about exporting.
The import and export are not always frustration free but it does work. Do keep the old copies around for a while just in case something is amiss.
Considering that the world has changed and the vast majority of password security issues today come in through the network, and not the front door, it's amusing to think that pen-and-paper is probably one of the better options these days. After all, if the bad guys have physical access to the computer, there's pretty much nothing you can do to stop them, anyway.
Assuming someone has access to the host, dumping passwords or keylogging them isn't very hard, therefore defeating the whole point.
Then I realized, it's open source, and you can host your own instance if you want to trust onetimesecret a bit less:
https://github.com/onetimesecret/onetimesecret
Then I realized (further) there is a fork that has been containerized and prepped for use on OpenShift (and ostensibly Kubernetes upstream, as well?)
I have not set up my own hosted versions of these, but the fact that it's Open Source makes me feel hopeful that it should be trustworthy. And if you want to be lazy and don't run a hosted service, there is always the public version:
Finally I realized, you can protect the exploding secret with a password, which I presume encrypts and decrypts in a localized context, in the browser (so data is not stored unsafely on onetimesecret's infrastructure in a way that it could be recovered by an adversary, without the shared secret at least, which granted could still be compromised.)
If it matters to you, you will need to verify all of that for yourself, but I think that all of those details are facts, (at least if I was onetimesecret I wouldn't have published the source unless all those things were true.)
I really wouldn't trust that KDF.
SHA256(x) is a hash function that transforms some string x (of any length) into a fixed size output.
SHA256(x) is deterministic. Every x maps to one 256-bit output.
SHA256(predictable junk) is going to look random, but will actually be predictable. This becomes security theater.
I mean the process of putting secrets in a web site is fraught, but:
a) KDFs in general are deterministic, not sure about your point here.
b) As long as you have sufficient input entropy, using SHA256 to mix some stuff down to key size is fine. You don't need a heavyweight KDF unless your input entropy is really bad.
File an issue if you're really sure, I guess?
This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
This is where the entropy is sourced from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
The global secret comes from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
self.key comes from gibbler.base(36): https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
At no point is anything touching /dev/urandom, which is how cryptography keys should be generated.
(Additionally, HKDF-SHA-256 should be used for splitting a master key into multiple sub-keys.)
I don't know if I want to file an issue for this on Github or not. Usually when the crypto is this bad, there's a lot of cargo-culting and I don't have the emotional bandwidth to deal with a vim-crypt style debate.
I take it all back.
We mainly used it on Slack. We made a slash command (/secret) to easily share passwords on Slack.
So the only thing you need to do is write /secret YourPassword.
After that, you need to be authenticated via Google SSO as we added a proxy. Yes, we know, the password goes through Slack.
https://flashpaper.logsnitch.com
Here's Ryan's code:
Employees should have their own user accounts for every service used, managed by some identity provider.
Anything else is hard to audit, hard to (de-)provision, and it's not secure.
---
This of course doesn't apply for sharing between friends, or with really small businesses, where only a few people share them.
* The AWS root account credentials.
* Redis
* Password protected certs.
* The Ansible vault password.
* The local admin account on your LDAP/AD server.
* IPMI devices that only have a single account.
It includes an audit trail.
This is what I use for my own passwords and I'm able to sync them across devices, which is nice.
It's fully frontend encrypted, so Jam doesn't know what logins you save and it can't read your secret credentials. The cryptography is based on 1Password's design (https://1password.com/files/1Password-White-Paper.pdf). I'd be happy to share details if people are curious.
Jam's focus on sharing comes through, right now, in the UI and default behavior. For example, when you save a new login, your friends in the system can proactively request access. To visually illustrate that: If I save a new login to Jam (like so https://i.imgur.com/syM2bep.png) then my friend gets a notification about that account, can see what it is (https://i.imgur.com/ZUKwfBB.png) and can request access (https://i.imgur.com/3SCcBm5.png).
It's in private beta right now, it's free to use, and I'm looking for as much feedback as possible. I'm happy to add people from HN right away, just email me at john at jam dot link
Example paste: https://0bin.net/paste/pfznjakZKHYGZyHS#rSk3vYexHzFn-NPPtfJT...
Do not expect complete security-- the apparent ease of use comes with a lot of caveats. Ref: https://news.ycombinator.com/item?id=9110146
Then there's the excellent magic-wormhole for the more enterprising amongst us: https://news.ycombinator.com/item?id=14649727
Signal's disappearing messages is probably a better but different alternative to sharelock: https://signal.org/blog/disappearing-messages/
If "Simply" is very important, go with PrivateBin. Keybase is not hard but it's a bit involved to create an account and manage your keys on multiple devices and such.
If you are at work I recommend setting up your own instance of it. I threw together a simple single-node instance of it that runs in a container (Docker) with systemd supervising. It uses nginx as a proxy and has built-in support for Let's Encrypt (because you are using TLS right?). I open sourced the scripts: https://github.com/FreedomBen/privatebin-setup
If anybody is wanting to setup their own PrivateBin using those scripts and my images, let me know and I will document it better. I just haven't put in the time because until this moment I didn't know if it would actually be useful to anybody.
[1]: https://keybase.io
1. If only one person needs a password, they should always create a password themselves. For example, you might hand them a newly provisioned laptop with a temporary password to login. The first thing they should do is change the password.
2. Multiple people using the same password is bad practice. Whenever possible, each person should receive their own user with their own private password if they need long-term access.
That said, sometimes a shared password is a simple practical solution. You could:
- Write it down on paper and hand it to them
- Use a password manager that allows sharing. Several password managers can do this (LastPass, 1Password) but it is a paid feature (inexpensive though at $4/month or less).
- Host a password manager yourself, such as BitWarden. You will need to ensure it's configured correctly and securely, host it somewhere you control/trust, and maintain it.
- Use a secure/anonymous (file) sharing service. I couldn't recommend one myself.
- Use GPG/PGP or similar, to encrypt messages and send them via email.
At my job, we use LastPass with shared folders for certain credentials. At home, I write passwords down to share with my family.
And here is a guide on email encryption (https://emailselfdefense.fsf.org/en/).
You can invite someone to a team by email, and they need to install the app, pick a username, and follow the join team instructions.
It's probably technically not as easy for a one off situation as onetimesecret.com, but the app download, setup and chat are pretty familiar UI models for many people.
In the long run, it gives you multiple ways of sharing that secret. Encrypt it and stick in the wiki, use an encrypted git repo, exploding messages via team chat, etc.
That being said, a real password manager is the proper tool here. I personally like LastPass, and it does require registration but has "1-to-1" sharing in the free version.
All you need to do is use a simple slash command
`/secure ...` and you'll be able to securely send images, files, or text through slack.
Check it out here: https://slack.securesend.quantfive.org/
Is it possible to use our own hosted Firefox send? Thanks!
Just run this command:
/secure -set-url https://securesend.quantfive.org/
Will ping you when that's ready!
HelpSpot Vault . Encrypted expiring text. Make it easy and secure for customers and coworkers to share information with you.
Encrypted in your browser Encrypted on the server Unique EXPIRING secure link
For other cases we have a company-wide install of Hashicorp's Vault, which has a secret-wrapping/sharing feature.
I know that I deleted my account as a result of it, and a couple of days ago there was a lot of noise about it in the discussion of https://keys.pub site:
Encrypted on client-side, the only thing server receives is the pass. You can check the request.
You can use the public version or host yourself.
Whatever tool you want people to collectively use, everyone should have their own account to authenticate, there’s absolutely no need to share a password ever. It’s a lazy insecure solution implemented by people who either can’t be bothered to do it the correct way, are too cheap to pay for a multi account subscription and rather compromise their own security or simply unskilled and don’t know that everyone can use their own account.
In the real world, just as there are plenty of services with poor password practices (e.g. restricting people to numeric PINs when longer-length alphanumeric passwords would be much better) there are also services that don't offer multiple user profiles tied to the same account.
It's fine to point out that these services should implement such a feature, but OP's question is about what to do if you need shared access to a service that hasn't yet implemented such a feature.
We develop iOS applications. We have an organisation developer account with Apple that allows us to give each of our team members their own login, complete with varying permissions levels.
On a fairly regular basis, Apple updates their license agreement. This requires the account owner to read and agree to the new terms before we can make changes to our account. This is the one permission that cannot be delegated. It has to be the account owner and nobody else on the team can do it. Furthermore, that account must be protected with MFA.
We also develop Android apps. We have a similar account on the Play Store. We'd like to connect our API servers to the Google Play developer account so that we can verify receipts for in-app purchases to determine that they are authentic. Doing so requires the account owner to enable this API. No other team member is allowed to do it.
The account owner is on holiday / off sick / hit by a bus. How do we do this?
Any competent service provider should be able to set up something similar.