New client install/setup proposal
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.
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.
if wrong password,
give instructions for going to web site and getting password by email.
Comparison with existing setup scheme:
- 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.
- Passwords are stored (and communicated) as MD5(password, email)
(see Security Notes below).
- 'munged' email address scheme goes away
- add email_validated flag
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).
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.
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.
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.
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.
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'.
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).
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.
We could do this by adding a flag to user table that
turns off the ability to log in using account key.
Return to BOINC main page
Last modified 8:52 PM UTC, October 17 2012.
Copyright © 2018 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.