Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Online joint accounts that are similar to bank accounts that are joint accounts?
Say you want to have two partners for a certain account, let's say a PayPal account, and you want to make it so that if one partner wants to change a password he must get confirmation from the second person.
Are there currently any online accounts that have a such a feature?
It's generally undesirable to have multiple people knowing the same password.
Instead, systems that requires multiple user to be able to access the same resources usually requires each user to create their own accounts, each with their own password that's only known to themselves, and the system would simply allow all the users to access the same resources. This means that a Joint Paypal account would have worked by allowing multiple user accounts to transact from the same wallet.
This means that it's unnecessary to get the approval of the other account holders to change password.
I don’t know of any actual web apps that employ such a system. But it is very much possible.
Specifically, what your asking about is called a threshold signature. The idea is that a group of N people each get their own secret credential. They can each use their credentials to partially sign a message. There will be some number M, often called the “quorum”, such that a complete (valid) signature is one in which at least M users contribute partial signatures.
More simply, M people out of a group of N members must sign a message for the signature to be valid. In a “2 of 3” (N = 3, M = 2) system, there are three people with credentials, and at least two of them would need to sign something to make it valid.
The only production use I know of is in cryptocurrency multi signature wallets. In most crypto currencies, money is sent by broadcasting a transfer message signed in such a way that proves ownership of the funds being transferred. In a multi signature wallet, no individual can unilaterally sign a transaction. Therefore no individual can unilaterally spend money.
In Monero and other CryptoNote coins, multi signature wallets also use ring signatures, so that the identities of the signatories within the group cannot be determined without the signatories’ secret keys. But signatories can create (safely shareable) proof of participation if they choose.
There is nothing to stop this kind of system from being used to authenticate a centralized web app such as a bank, but I have never seen it done. The common practice is to achieve a similar effect by privilege separation under trusted admins.
Lastpass has a sharing feature which allows you to share a set of login credentials, without the other person being able to see the password.
This way you allow them to login with the username and password you share, they have no access to know or view that password, which precludes then from sharing it with anyone else.
The feature can only be used on a website where their auto-fill feature is compatible and when using their browser extension.
I am not aware of any security research done on this feature - as to whether it would be possible to extract the password from the extension if the other party were malicious, but if the use-case here is a friend or relative, this should provide sufficient protection.
Anecdotally, I know many married couples that use this to share logins, and this reduces the risk of password compromise if only one spouse's machine is compromised.
Are there joint password account? (Like bank accounts)
No, this would be a very bad design.
Any provider which expects multiple individual to share the same resource shall provide :
This prevent the need of password sharing, allow the possibility of user revocation and multiple level of permission.
This is already widely implemented in the B2B world when there can be multiple contact for the same company :
If you're in a business and need to share one access with one or more individuals and your provider doesn't support multiple user accounts, I'll suggest to find another provider before trying to find a secure password sharing method because there isn't any.
Most such services stay logged-in, so that a password is only needed to make account changes. In that case, you can simply have two people memorize half the password, or each type their own password in the same box, one after the other.
To change the password, or sign-in on a new device for the first time, both parties would need to be present to enter their half on the re-login screen.
Simple and effective and needs no software or vendor support.
With a joint bank account, you have shared access, but not shared authentication. Specifically, each person will typically have their own access token (credit card/debit card), and credentials (pin number, online banking login), and shared online accounts will typically work in the same way, being able to grant other accounts access to the same resources.
For examples that I'm directly familiar with, you've got most of the Smart Home applications, where you can add users, and ever vary the level of access. Ring, for example, will allow you to allow a user access to specific cameras and resources, and similar things are available for services such as Tado or Phillips Hue.
Something that's a little closer to what you're looking at, you've got the households feature within iCloud accounts for Apple, where users can share subscriptions, have a single payment method, and even require authorisation for purchases from more senior users (parents, usually).
If you mean "single account, that can be accessed by different people using their each own passwords", I don't know about any widely available/actually in use shared PASSWORD systems. It can be easily achieved though on pretty much any POSIX system by setting same UID for separate user entries. Any service that depends on this authentication - like FTP or Telnet - will automatically inherit all those "shared" accounts.
If you use keys instead, then overwhelmingly common and known by pretty much everyone SSH allows you to associate unlimited number of separate keys with any user account. Once again, anything that runs over it - like, for example, SFTP or Git, will allow you to authenticate with any key.
I'm not an expert in security, but I'd like to put my two cents here.
Let's think on this example:
Bob and Alice have access to your system, and they can each perform certain actions without consulting each other. However, there are some actions for which both need to agree. Either Bob or Alice can request the action, but this will only be executed if both agree on it.
Example: To delete a row from a database table, both Bob and Alice must authorize the action.
Let's say that Bob wants to delete row 1 from the table. Bob access the system with his credentials and issue the transaction request. This transaction would be enqueued, awaiting for Alice to either authorize or deny this action. Later, Alice access the system with her credentials, and the first thing she sees is a notification: "Bob wants to delete row 1 from the database. Do you agree with this?". She could answer yes or no. If she answers "No", the transaction is cancelled, and if she answers "Yes", the transaction is executed.
Notice that this setup requires some things:
I've seen something close to this at my workplace: The HR administration system, which (among other things) we use to set goals for each year, has workflows that require that many users agree on certain operations. A user triggers an action, and another user (with higher privileges, or with the same privileges but in another branch of the hierarchy) must authorize this action (add a goal, remove a goal, edit a goal, etc.).
Notice that, at the end of the day, this setup is only as secure as the "weakest link in the chain", because once the last user of a group agrees on the action, it becomes irreversible. In our example, if Alice simply clicks "Yes" without reading the notification in full, the row in the table will be deleted and there may not be any rollback option.
