webhosting : user-passwords versus domain-account-passwords

by Derek Sivers

Related link: http://www.hostbaby.com/

The thinking-out-loud question of the day : user-passwords versus domain-account-passwords.

Re-organizing the database for HostBaby web hosting.
Until now the client-to-domain relationship was one-to-one. (Very silly, wrong and lazy, of course. People with multiple domains on HostBaby had to just go sign up all over again.)
I've got that fixed so each person now has a single "client" account, with multiple domains inside.

The question is -- do we assign them a client-level username + password, or just let them log in with any one of their domain-level usernames + passwords?
(Because each domain name *does* need its own username + password anyway.)

(on top of each domain also having its own user+pass)
* - one single username + password to remember to access their account
* - could log in to their account, even before their domain-account is ready
* - could match the way our domain registrar company is set up : one username + password controls many domains. we could keep these synced.
* - not EVERY domain account needs a username + password : aliases and redirects don't. Only website accounts need it.
* - this is how other companies seem to do it (Network Solutions, GoDaddy, etc.)

* - more to remember!
* - I'd have to let them log in with their domain's username + password anyway, since that's the one they know the best
* - most of our clients have only one domain. requiring two different usernames + passwords just to administer that one domain is silly
* - more customer service complaints : more explaining

* - easier for them to remember : if they know any of their username + passwords, they're in
* - people with one domain only have one user+pass to remember
* - no duplication
* - this is how they'd try to log in, anyway (and the way it's been for years)

* - we generate that domain-level username+password for them when creating their account, so there's a downtime after they sign up where they have to wait to hear from us before they can log in to their account
* - security risk? people with multiple domains have more likely chance someone could guess their info?
* - doesn't match how our registrar works : we'll have to choose their *first* username+password to be the master one at the registrar, and make sure they use that to connect to their account there, even when they add new domain names with new username+password combinations

I think it's about 50/50. I'm going to try the domain-level only, and see how it goes.

Anyone else gone through this kind of decision before?


2004-10-22 00:58:06
One user, one password

Your system of domain registration is extremely broken if it involves exposing users to multiple username/password pairs to manage their domains. Find another registrar.

If you can't do that then at least hide it from your users.

For example, you could provide your own interface to domain registration and call back to the registrar's website, looking up the appropriate username/pass from the db.

Alternatively, you could generate a link/form pointing at the registrar's website pre-populated with one of the many username/password pairs.

There's no reason at all why you need to inconvenience your users while you move to a sane system of one user, one password. Check the new and old data during the login process untill you get a match -- treat the old data as user aliases.

It's bad enough having to remember the different login credentials one uses on a daily basis accross the web, it's unforgivable for a single company to force that on you.

2004-10-22 08:28:17
One user, one password
I agree.

The system knows which user has access to which domains — why'd they have to provide credentials for each? It makes no sense. A single username and one password should grant access to all domains registered to that user.

2004-10-22 10:27:45
it's a full webhosting account, with FTP/SFTP/shell
Sorry if I wasn't clear about this : the reason each domain needs its own set of usernames and passwords is because it's not just domain-registration or domain-name-management, it's a full webhosting account, with FTP/SFTP/shell access.

So the question was more about whether to let their domain-level FTP/shell username+password get them into their account-management side, or whether to have a DIFFERENT umbrella username over their whole account.

2004-10-22 21:24:58
it's a full webhosting account, with FTP/SFTP/shell

I don't mean to bust your chops here, but what you're really asking for is permission to make your user's life's suck.

The real question you should be asking is "How can I make my web based application and all my shell/ftp acounts, possibly on multiple machines, use the same password database?".

I would recomend looking at ldap for storing account details, one of the apache ldap access control modules, PAM for shell accounts and SASL for ftp/imap/smtp etc.

2004-10-22 21:43:20
One user, one password
As Hostbaby's largest customer, I'd like to point out a couple things here.

They don't even make me log in to do anything with the DNS registration. I just pay them to take care of it. They get all the junk mail you get just by registering a domain, and take care of it for me. Well worth what I pay them. So we are not really talking about a registrar.

Having separate username/passwords for multiple web-hosting (and SSH and FTP and webmail) accounts is absolutely crucial to me. I do *NOT* want to give out the password to *ALL* my accounts when I have to work with a designer for *one* account. So when I need to give a designer access to the whole site to keep a client happy (even if I *know* they're going to replace my PHP with static HTML and then wonder why the guestbook is broken :-^) then I need to be able to change that password separately.

In fact, I spoke with Derek earlier, and asked for a *finer* grain of control.

User/pass for all accounts.

Individual webmaster user/pass for each account.

Individual content editor user/pass for each account -- So I can put some parts of the site management under client control, but keep their fingers out of the gears (for the ones smart enough not to insist on putting their fingers in the gears).

2004-10-23 00:29:27
One user, one password

You're confusing two completely different things: authentication and authorization.

  • Authentication seeks to identify a user is who they claim to be, by checking a password or by some other means.

  • Authorization seeks to answer "Is user X permitted to do Y?".

A user needs one password to identify themselves. An administrator needs some means of authorizing identified users to perform certain tasks.

This applies just as much to the band manager -> web designer relationship as it does to the HostBaby -> band manager one.

2004-10-23 00:33:12
it's a full webhosting account, with FTP/SFTP/shell
INTERESTING! That's definitely a new way of looking at it. Thanks.