New client install/setup proposal

Introduction

This is a proposal for a new install/setup mechanism for BOINC. The goals are to be simpler and more user-friendly, and to succeed even when proxy setup is needed. The major changes are:

• From the user's viewpoint, an account is now identified by the combination of user-supplied unique identifier (email address or user name) and a user-supplied password. The choice of identifier is up to the project. In the standard BOINC software, email address is used.
• Email addresses are not verified. Nothing prevents a user from creating an account with an email address they cannot access. An 'email_verified' field will be added to the database, and we will add a verification mechanism. For now, verification will be required only for message-board emails.
• The email address and/or password of an account can be changed via the web.
• The setup process attempts to identify cases where HTTP/SOCKS proxy configuration is needed, and prompts user for information.
• Account keys are still used, but are not generally visible to users. Account keys are used by the core client to identify and authenticate itself to the server. An account's key never changes (so core clients don't need to learn when email address or password has changed).

BOINC setup process

• User gets software (download or CD-ROM) and installs. BOINC Manager runs. The following steps are done in a 'wizard' (a sequence of dialogs with Next/Back buttons and explanatory text).
• User is prompted for project URL.
• BOINC communicates with the project to get configuration info (see below).
• If communication with server fails, and can't reach Google/Yahoo either: Wizard says 'can't communicate with server, you may need to configure proxy settings'. Gives instructions for finding proxy settings from web browser. Gives form for entering proxy settings.
• User is prompted for new or existing account, either email address or user name (depending on configuration info) and password. In 'new' case they type password twice. Checking for password validity (e.g. min length) is done in the manager.
• BOINC communicates with server to look up or create account, and attaches to project.
• If everything goes OK: in the existing-account case we're done. In the new-account case, BOINC manager opens web browser on Account Setup page where user can enter additional account infO: name (prepopulated with username on host), country, preferences, etc.
• New-account case: if unable to create account because account with same identifier already exists, but different password: give instructions for going to web site and getting password by email.
• Existing-account case: if wrong password, give instructions for going to web site and getting password by email.

• The 'create account using web site' step has been removed.
• The 'wait for email message' step has been removed.
• The 'cut and paste account key' step has been removed.

Web site operations

• Web site login is normally by email address and password. Cookie uses account key (existing login works even when email or password is changed).
• Can also login by account key.
• A logged-in user can change the account's email address and/or password. (changing email address clears the 'email validated' flag, and sends notification emails to both old and new addrs).
• There is no interface for getting a password, either sent by email or shown on web.
• A form (not requiring login) lets you type in an email address, and emails account key to that address.
• The 'email me on posts to this thread' command in the message boards will work only if the account's email is validated.
• There is a 'validate email' page. If you click, it sends an email to your address with a link containing a return URL which includes account DB ID, and a hash of account key and email address. Visiting this URL validates the email address.

Database notes

• Passwords are stored (and communicated) as MD5(password, email) (see Security Notes below).
• 'munged' email address scheme goes away
• add email_validated flag

Password restrictions

Rules for passwords:

• passwords are case-sensitive
• min password length is a project config item; max password length is 32.
• may use any ASCII characters 32..126 (this includes space and all punctuation, but no control chars).

Problem cases

• Poaching: user X can create an account with user Y's email address. If Y tries to register later, he'll get an error message. But: Y can go to the web site, have the account key mailed to him, change the email address of the account (to anything), then register again. Y will then have an account with his email address, and sole access to it. User X will have access to the old account, but not the new one.
• Email typo: If a user makes an error in typing their email address initially (or forgets what email address they used) they won't be able to log in to the web. In this case they can get their account key (using the Manager), use it to log in, then fix their email address.
• Email invalid: if an email address becomes invalid, the user can change it using the web site. If they've forgotten their password, they can get the account key from the Manager (as above) and use it to log in.

Transition

Phase 1

During this phase the new client is under test. All projects have a get_project_config.php file but some have not updated their server.

The server changes are:

• Add password, email-valid field to user table. Initial value (for existing accounts) is account key.
• Add web RPCs for account lookup/create.
• Change login page to accept email/passwd. Add page to change passwd.
• Remove email-munging stuff from PHP code.

Phase 2

During this phase the new client is released for all platforms, but lots of users still run old clients. All projects have updated their server.

• Change setup instructions on web sites.
• Change 'create account' page to say 'you only need to do this with client versions earlier than X'.

Phase 3

During this open-ended phase there are still a few old (or non-manager-based) clients that must be supported.

• Remove 'create account' links on web sites (old clients can still run, but new setups must use new client).

Security notes

• In general, passwords should be well-protected because some users may use the same password for BOINC projects as for more important things. Protection of account keys is slightly less important, because they provide access only to a single account on a project.
• Passwords are stored (and communicated) as MD5(password, email) (i.e. we use the email as salt). If hackers obtain one of these strings (either by hacking a server or by packet sniffing), they can use brute force to get the password. However, because of the salt they can't do this with a single precomputed list of hashes.
• The 'login using email/password' and the 'change password' web pages use HTTPS.
• Account keys are emailed in cleartext. This could be changed to sending a URL with a token that lets you see the account key on the web, but I don't think this would provide more security. Remember, scheduler RPC requests are cleartext and contain the account key.

Other comments, requests and ideas

• (Korpela): shouldn't be able to change email or passwd with account key. (But then our solutions for email typo/invalid problem cases won't work).
• Make it possible for a host to run, attached to an account, without the host containing any info that would provide access to the account. (John Keck). We could do this by adding a flag to user table that turns off the ability to log in using account key.

Last modified 10:08 PM UTC, April 16 2007.
Copyright © 2008 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.