Ask HN: How do you share passwords simply and securely?
I saw lots of password sharing (especially at work, between family members or friends, purposely or non purposely) with plain text in the wiki, or restricted permission of doc.
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)
88 comments
[ 2.6 ms ] story [ 132 ms ] threadhttps://github.com/bitwarden
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.
https://flashpaper.logsnitch.com
Here's Ryan's code:
https://github.com/rawdigits/go-flashpaper
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/
Example paste: https://0bin.net/paste/pfznjakZKHYGZyHS#rSk3vYexHzFn-NPPtfJT...
For other cases we have a company-wide install of Hashicorp's Vault, which has a secret-wrapping/sharing feature.
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:
https://onetimesecret.com
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.
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.
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.
It includes an audit trail.
* 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.
This is what I use for my own passwords and I'm able to sync them across devices, which is nice.