Ask HN: How do you share passwords simply and securely?
88 comments
Bitwarden is 100% FOSS and was audited by Cure53.
https://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.
https://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.
Bitwarden is amazing. It's still a young project, but the fact that it's FOSS and that you can host it yourself, gives it a real compelling reason for personal and enterprise use.
Password managers are a godsend, but it’s still very challenging getting the older generation to use password managers. Anyone who says otherwise hasn’t given it a try.
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.
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 am using KeePass synced with Dropbox. Does Bitwarden have a way to import these as well as export out my stuff in case I opt to change to another password service?
Their help docs contain information about importing passwords from KeePass: https://github.com/bitwarden/help/blob/master/_articles/impo...
I don't know about exporting.
I don't know about exporting.
Yes, it supports import from Keepass. I did 1Password -> Bitwarden and then settled back on KeePassXC.
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.
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.
I was doing KeePass over Dropbox for years. Keeping android in sync was a pain. The integration was too disruptive for my wife to adopt. Dropbox also started limiting the number of devices I can have synced. Bitwarden solves all of that. Cleaner UI, easier to use, always synced between devices, etc.
Yes, I have done it.
Bitwarden is quite young, but after a couple of years of solo-deving they are finally expanding, and the next year or two might see it get a lot of extra features that are very helpful - atleast if info that was talked about in their customer forum is accurate.
I use it both at work and personally.
+1 for Bitwarden. I host it myself, it's got great support for apps on IOS / Android. The browser extension works well.
Decades ago, tech-savvy people used to make fun of office workers who would put their passwords on Post-It notes stuck to their computers.
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.
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.
While post notes offer natural resistances to any non-physical threats, they lack the comfort and usability of having your password on your PC.
Assuming someone has access to the host, dumping passwords or keylogging them isn't very hard, therefore defeating the whole point.
Assuming someone has access to the host, dumping passwords or keylogging them isn't very hard, therefore defeating the whole point.
Just don't do a video interview at your desk or take any pics of your workspace.
Those who cannot remember the past are condemned to repeat it. A known case happened to TV5Monde in 2015 https://www.bbc.com/news/world-europe-32248779
If you do this please make it stronger than password123, letmein, monkey12.
Agree! I actually tell family and friends to write passwords down in a notebook if they’re not savvy enough to use a password manager. What’s old is new again!
So when I saw people using onetimesecret.com to share sensitive credentials at work (this is a free tool hosted by a third party that IMHO there was no reason to believe is trustworthy) I was a little bit taken aback, because to me this seemed only marginally better than putting the password in an email, and in many ways potentially much worse.
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.)
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.)
https://github.com/onetimesecret/onetimesecret/blob/8ba0511e...
I really wouldn't trust that KDF.
I really wouldn't trust that KDF.
Absolute layman here. Care to elaborate?
Sorry, I don't know how to best ELI5 the problem space as well as I probably should.
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.
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.
This looks fine to me?
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?
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?
That's the ticket though: I suspect the entropy is really bad.
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.
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.
Yeah I had a look and this is... not great.
I take it all back.
I take it all back.
We are using a hosted version of onetimesecret for internal usage.
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.
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.
... aren't you then sharing it with the Slack (the service, not the room) too?
Ryan Huber wrote and open-sourced a single file web app called flashpaper for sharing secrets. Here's a version of it I've deployed - it's public to the internet, anyone can create a secret and share it via a one-time-use link:
https://flashpaper.logsnitch.com
Here's Ryan's code:
https://github.com/rawdigits/go-flashpaper
https://flashpaper.logsnitch.com
Here's Ryan's code:
https://github.com/rawdigits/go-flashpaper
Flashpaper is great if you have a trusted server and a trusted operator running it. Seriously, don't use a random flashpaper server on the internet if you want to keep your secrets secret.
Weird that it wasn't mention yet, but you should NEVER share passwords between people at work.
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.
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.
I mean you're right but that doesn't describe the reality.
* 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.
* 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.
You do need to share passwords to common accounts.
This is just not how corporations work, every corporation needs some type of secret sharing. CyberArk is a billion-dollar business.
It includes an audit trail.
It includes an audit trail.
Nobody else on my team wears a tinfoil hat like I do, but I'd be happy with https://www.passwordstore.org/ with the data stored on a private git repo that we can all access.
This is what I use for my own passwords and I'm able to sync them across devices, which is nice.
This is what I use for my own passwords and I'm able to sync them across devices, which is nice.
I use gopass (https://github.com/gopasspw/gopass/) which works well, but I don't share with anyone. Always wondered how I might jump that hurdle.
I'm also using this excellent tool, along with a nice Emacs integration for it (https://github.com/NicolasPetton/pass) and I really like it for the control and flexibility it gives, especially in the context of a developer's environment.
I'm building Jam (https://jam.link/) to tackle this problem. You can think of it as a consumer password manager built specifically for sharing.
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
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
https://0bin.net is one of the few services that you can use without logging in + has a client-side encryption key in the URL.
Example paste: https://0bin.net/paste/pfznjakZKHYGZyHS#rSk3vYexHzFn-NPPtfJT...
Example paste: https://0bin.net/paste/pfznjakZKHYGZyHS#rSk3vYexHzFn-NPPtfJT...
Someone should tell them that you don't need Flash to implement "Copy to Clipboard" anymore.
Go crazy, either email [email protected] or go straight to the source and submit a patch, relevant parts seem to be here: https://github.com/sametmax/0bin/blob/master/zerobin/static/...
Here's a PR aiming for that, for what it's worth. https://github.com/sametmax/0bin/pull/128
I use Signal which was verified on different levels as "secure" according to Kevin Mitnick, so that's good enough for me.
I've found that the simplest way to share secrets is through https://sharelock.io/new
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/
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/
I recommend first Keybase[1] if you can convince others to make an account and install on their systems. If you cannot (a common problem in business I've discovered) then PrivateBin[2] is my next preference. Their .info site explains the project and the .net site is a working example you can try[3].
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
[2]: https://privatebin.info/
[3]: https://privatebin.net/
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
[2]: https://privatebin.info/
[3]: https://privatebin.net/
Would love to give your images a try and would appreciate a bit more documentation. Certainly useful! Thank you.
Cool, want me to shoot you an email (from your profile) when done? You're also welcome to email me (in my profile) as well.
Why not :) Highly appreciated.
Hashicorps Vault has a feature called wrapping, this allows you to share a secret in a way that it can be opened once (with an expiration date as well)
Fundamentally, you should not share passwords
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.
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.
I often had to share passwords to services with students so they could work on a project. We all had shared access to a Google Docs area and a wiki, both password protected. So once a student was allowed access to either of these protected spaces I could use them to transfer a password. I'd type the password in some random document, tell the student to go look at that document, they'd email that they had the password and I'd remove it from the document. Getting the students access to the Google Docs or wiki was a simple process, they could request access to the Docs and my boss would vet and grant it, or a sys admin would add access to the wiki for them. So once you establish one relatively secure channel, you can leverage it for other secure purposes. Probably not highly secure, but we weren't protecting nuclear secrets.
You can do this in many ways. But you should use End-to-End encryption to guarantee security. For example, you might use a secret conversation that uses End-to-End encryption on some software like Signal, Telegram and Conversations. Or you can use encryption software like gpg (see https://gnupg.org/) with public key encryption methods, to encrypt the password (or any message), and then you can send it using literally anything, like email or so on.
And here is a guide on email encryption (https://emailselfdefense.fsf.org/en/).
And here is a guide on email encryption (https://emailselfdefense.fsf.org/en/).
I think Keybase does a decent job here.
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.
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.
[deleted]
Onetimesecret worked well for me. Can also be self hosted.
Hey all, we built a tool for slack that integrates with Firefox send (open source) that allows you to send passwords securely through slack!
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/
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/
Will check this out, thanks! Was looking exactly for a Slack integration of Firefox Send, but never found anything.
Is it possible to use our own hosted Firefox send? Thanks!
Is it possible to use our own hosted Firefox send? Thanks!
Hey Mathie, we just pushed something today where you can set your own Firefox send url (or set it to send.firefox.com)
Just run this command:
/secure -set-url https://securesend.quantfive.org/
Just run this command:
/secure -set-url https://securesend.quantfive.org/
Hey Mathie, we haven't built that in there yet, BUT I think we can do it quickly.
Will ping you when that's ready!
Will ping you when that's ready!
I use help spot vault. It seems easy to use for technical and non-technical co-workers, clients and friends/family.
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
https://www.helpspot.com/vault
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
https://www.helpspot.com/vault
A psafe3 file (https://www.pwsafe.org/) in a git repo.
My team has used a KeePassX database in a private git repo. Others use a company-wide install of Thycotic.
For other cases we have a company-wide install of Hashicorp's Vault, which has a secret-wrapping/sharing feature.
For other cases we have a company-wide install of Hashicorp's Vault, which has a secret-wrapping/sharing feature.
We have a keepaas file that has the passwords for a number of client resources. The clients don’t roll their passwords very often.
I send half of the password by email and the other half in a linkedin message for professional contacts outside my org.
Like others, I also use keybase.io. By design it is not connected to the phone number, I can prove by myself the identity of the recipient and yes, it has exploding messages. They had a fiasco with unwanted cryptocurrency but now it is mostly forgotten/forgiven.
I'm not so sure that their crypto-foray was so easily forgiven and forgotten.
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:
https://news.ycombinator.com/item?id=22995792
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:
https://news.ycombinator.com/item?id=22995792
magic-wormhole was our standard answer to this problem.
You can try Passion - https://github.com/heureka/passIon
passion.heu.cz/
Encrypted on client-side, the only thing server receives is the pass. You can check the request.
Encrypted on client-side, the only thing server receives is the pass. You can check the request.
If I’m sending credentials to one person, I’ll send the username via one method (text) and the password via another (email). No context for either message (i.e. NOT saying “this is for the Yahoo account) - that is sent and explained in a phone call.
An expiring message sent using an open source encrypted messenger (e.g. Signal, Wire, etc.).
If you are just wanting to share the secret once (not persistently) this works really well:
https://onetimesecret.com/
You can use the public version or host yourself.
You can use the public version or host yourself.
Privnote https://privnote.com/ is simple and does not require any sign up to create simple one-time links which are self destructive
I use this all the time!
I use a common account for sharing secrets with my family. The web app I use is Passfindr (https://passfindr.com).
The reason sharing requires a registration is so it can be end-2-end encrypted. Anything less than that is way easier for hackers to get their hands on.
You can have e2e encryption without registration and you can have registration without e2e encryption - they are orthogonal to each other.
You don’t.
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.
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.
You're talking about what should be the case, not what is the case.
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.
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.
> 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.
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?
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?
We have an old android phone for Authy MFA and SMS MFA. It lives in a safe and a few people can get access to it.
[deleted]
This was my first instinct. But what about something like a company Twitter account?
For Twitter, use TweetDeck. You can give other users the ability to post without sharing the password.
Any competent service provider should be able to set up something similar.
Any competent service provider should be able to set up something similar.
Try SecureAppy. It is a modern vault that simplifies sharing passwords, photos and more with family members or others. It is exactly what you want - free, simple, and secure. It uses end-to-end encryption. Check it out: https://www.secureappy.com/
Tell them verbally. For secret passwords put it on a sticky note.
GPG Encrypt + Slack
or
Keybase exploding message$
the answer changes depending on if you're talking about your Netflix Login or the login to the production work server
[deleted]
Gramma's maiden name followed by our street address and the current date
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)