Startup idea: Password sharing site?
5 comments
My gut reaction is that there should be a non-technical solution, rather than a 'password sharing site'.
The concept of 'password' and 'sharing' goes pretty much against what people 'should' be doing with passwords.
I'm not familiar with any systems which don't allow more than one 'super-user' account, so I'm wondering why you wouldn't just have more than one 'super-user'. One account for you (as the main responsible party), and one 'super-user' account to be used in emergency situations only, which can be provided to the site/app/server owner.
Would that not solve the problem you are attempting to address?
The concept of 'password' and 'sharing' goes pretty much against what people 'should' be doing with passwords.
I'm not familiar with any systems which don't allow more than one 'super-user' account, so I'm wondering why you wouldn't just have more than one 'super-user'. One account for you (as the main responsible party), and one 'super-user' account to be used in emergency situations only, which can be provided to the site/app/server owner.
Would that not solve the problem you are attempting to address?
The phrase "password sharing" was half-serious (and apparently not very effective) view bait--I wouldn't call it that on the public site. :-)
Some reasons multiple superusers aren't enough:
* Superusers can disable or delete each other. Most parties won't need access very often so might not know until it's too late. In many client/consultant relationships you trust, but you verify. (The importance of the login-testing daemon.)
* Being reliably alerted when someone has logged on ranges from difficult to impossible in most systems. For backup/emergency type people, you trust them enough to make it possible for them to have access, but you'd really want to know if they ever used it when you weren't expecting. (And superusers can forge logs.)
* Many systems (like shared hosting accounts) actually don't allow for multiple super-users.
* Independent consultants/free-lancers need an answer to the "what happens if you get hit by a bus/are on vacation/have a power outage" question. 2-4 person federations of independents providing backup service for each other is currently impractical when each has several systems to access. It's bad enough that I have N logins of my own I have to keep track of--having to keep up with a further 2-3N logins (that I have to change periodically if I'm doing right) is way too much overhead. The only current workaround I know of is having the same password for everything, which is extremely poor security.
An important use I didn't consider at first is personal password escrow--making a way for my various accounts to be accessed in case of personal emergency.
Some reasons multiple superusers aren't enough:
* Superusers can disable or delete each other. Most parties won't need access very often so might not know until it's too late. In many client/consultant relationships you trust, but you verify. (The importance of the login-testing daemon.)
* Being reliably alerted when someone has logged on ranges from difficult to impossible in most systems. For backup/emergency type people, you trust them enough to make it possible for them to have access, but you'd really want to know if they ever used it when you weren't expecting. (And superusers can forge logs.)
* Many systems (like shared hosting accounts) actually don't allow for multiple super-users.
* Independent consultants/free-lancers need an answer to the "what happens if you get hit by a bus/are on vacation/have a power outage" question. 2-4 person federations of independents providing backup service for each other is currently impractical when each has several systems to access. It's bad enough that I have N logins of my own I have to keep track of--having to keep up with a further 2-3N logins (that I have to change periodically if I'm doing right) is way too much overhead. The only current workaround I know of is having the same password for everything, which is extremely poor security.
An important use I didn't consider at first is personal password escrow--making a way for my various accounts to be accessed in case of personal emergency.
password escrow:
http://nsit.uchicago.edu/services/safecomputing/passwords/es...
http://nsit.uchicago.edu/services/safecomputing/passwords/es...
Interesting, but not comparable.
sure it is comparable. Basic use cases and users are the same. They have a brick and mortar system. Yours is electronic. Comparable like snail mail and email.
It's very hard to manage all this well. If you've experienced it, you know just what I mean.
So what about a service where you can store all your login credentials on a per-project basis and grant users access to a project generally or on a time-restricted basis?
Key features: * Users IDed with client certs. * All crypt done on the client--server never sees your passwords ever. * All access logged, and access by your "backup support" (e.g.) could trigger an alert to other project users. * Optional daemon account to whom you can grant access. Runs every day and attempts logging-in (ssh, ftp, http basic at first, later app-specific support) to everything in the account. Alerts everyone if a credential no longer works.
Worth paying for? Stupid idea? Been done already? I value your feedback.