This idea seems almost too good to be true - in my experience the HN hive mind can always find the problem with something that's too good to be true.<p>Last company was a medium to large UK corporate which built medical software. Developers and product would sign up for all kind of random websites and services, when that person left, moved jobs, forgot the password or was on holiday then that website or service would become inaccessible - this happened more than once.<p>With a server this problem is solved with service accounts - where multiple users can login as themselves but then act as the service account. Access is logged, audited and can be controlled and assigned easily.<p>I'm wondering if it's worth me building a tool that can replicate that functionality for random or low tech websites and services. Call this software - Servicio.<p>When an employee signs up to a website or product, they generate a new email in Servicio and get assigned a password which they put in. The password is copied to their clipboard* and the user/employee doesn't get to see it.<p>When someone else wants to log into this service, they have to log in to Servicio with their user credentials, find the service, get the password copied to their clipboard* and then paste it in.<p>Someone will have to rotate passwords, and manage this software but in companies with software developers this administrator's time will be less expensive than that of the product/developer time.<p>*This is one snag I've worked out so far. An enterprising member of staff could inspect their clipboard or just paste the password into a word document. I don't have a method for avoiding this without building something native.
Any service that requires credentials should be designed and implemented in a manor that allows credential rotation at any time with low or no risk. I would encourage people to test this process on a regular basis. You could even automate this process in your dev or staging environments to minimize risk in the event that a code change breaks credential rotation. You can take this a step further and implement something like Vault [1] so that nobody on the team knows the credentials until they for whatever reason need to use them. They make a request to vault and there is a log entry that they pulled the credentials. This sets a good pattern and a good story for future audits.<p>[1] - <a href="https://www.vaultproject.io/" rel="nofollow">https://www.vaultproject.io/</a>
At my work we have an engineering@ email address that all shared accounts use, and store the credentials in a shared vault in 1Password.<p>Someone could copy the creds out, but that just means we should change shared passwords after someone leaves.
So how did the last company share the user account? If the password is kept secret by the original user I don't understand how the account could be shared. Did they ask the person to physically type the password in their keyboard?