I am ... surprised that there are no requests for this; only mentions in passing of the fact that, to add project accounts to one's BAM account, all account passwords must be identical -- not only to one another, but to that of the BAM account itself.

As a security professional, I find this very concerning. Present wisdom is obviously "Never Do That." I know this has been the reality since before I joined BAM, but it is 2023 now, and such a vulnerability is becoming more difficult to justify with time. Only one BOINC project account database needs to be compromised due to one poor implementation for someone to obtain access to all my (currently 35 active) BOINC project accounts and my BAM account.

All BOINC project accounts have unique account keys for full and weak authentication. There really ought to be an option to add one's existing BOINC projects to BAM using their individual account keys or simply their unique passwords, even if this might be confusing and cumbersome to the novice user and best left opt-in. If the user employs a password manager (which everyone everywhere ought to be doing as routinely as possible anyway), neither scenario would be that difficult for the user to handle.

I would offer to see what it takes to contribute the feature myself, but I don't see a source repository for BAM.

I should probably also request 2FA since this account is a controller for multiple others, and thus represents a potential single point of failure from a security point of view, but... well... small moves.

I 100% agree. Using/requires one/same password for all BOINC projects is extremely dangerous and should be changed ASAP. One user BOINC PROJECT login compromised and all active user PROJECTS are considered compromised.

* My suggestion is to use the projects "weak key" as an authenticator for BAM CONTROL of a users BOINC projects they are currently signed up for. No need to provide project password to BAM - Just another potential for compromised information, especially if someone reuses same or slightly different password used elsewhere.

* If the user want to add/sign up for new project(s) BAM should redirect user to the project sign up page to go through the registration process. Once the cross project user ID (CPID) has synced (which is usually after 2nd connection of BOINC program to project server) user has to update BAM info for the project.

A bit more complicated, but IMHO a lot safer for everyone.

Indeed, that would be even better -- principle of least privilege and all. However, I don't think BAM's project management features would work with only the weak authenticator, since those operations (e.g., setting project weight, switching on/off GPU usage, setting host profiles, centrally detaching hosts or disallowing work -- anything that involves altering project or computation settings) require write access to the project beyond the host attachment permission.

Maybe that's sufficient if a user has already chosen all of their project settings and is operating in a (very) steady state, but for most people it would impose the chore of having to go to their project sites to make any changes at all, ever... which kind of obviates the point of BAM.

Ideally, the upstream BOINC server software would have permissions extensions for users to generate multiple authentication keys within their project accounts and choose what permissions to assign each key, but though that source code is open, it is not an easy lift and would definitely involve a committee discussion to implement to the satisfaction of the BOINC software maintainers. For now, we have to work with what we've got.

Now, since you have me thinking -- regarding the use of authenticators, there is this: https://github.com/BOINC/boinc/issues/2371

But it's moving at a snail's pace... it's unclear what role the BOINC developers intend for authenticators to play in the future based on that conversation and the ones in related issues. It has been suggested (years ago) that all of BOINC switch to using OAuth for authentication, which honestly is the best of all possible futures, but who knows if or when that will happen.

Critically it includes mention of the detail that your project account full authenticator can never be changed, so using it anywhere... contrary to my initial suggestion... would be a Terrible Idea.

Apparently Science United uses weak authenticators, though? I'm not sure how that plays out for them, as I've never tried using that account manager.

are the passwords sent encrypted or in plain text?
i just set up a bunch of linux boinc clients and i just type the password in the command line with single quotes around them.
i dunno if that gets hashed before its sent ?

boinccmd --join_acct_mgr bam.boincstats.com actng 'Passw0rd!!!'

I agree that reusing the password is a very bad idea. This has always been needed to keep the CPID in line because it is partly based on the password. Recently a change has been made in BOINC to always use the oldest CPID (if I have read this correctly). It would require updating to the latest codes (projects and clients I suppose).

I can update BOINCstats to use a different password for each project, it would require some recoding of core-BAM! parts.

One thing to keep in mind is that BOINC password hashing is really bad. And I do mean really really bad. It's using a very old easy to crack hashing algorithm and a simple hash. It's not something I can change, it's used as such by the projects.

Step 1 complete. When a user logs in on BOINCstats a new better hashed password will be stored. Once it is stored it will be used to log in to BOINCstats. Next step will be to separate the BOINCstats password from the BOINC password since that has to be stored with the old hash for compatibility.

So I ran into an issue. I usually create unique email addresses for every site I sign up for. For example, willy+boincststats@mymailprovider.com, willy+einstein@myemailprovider.com.

As BAM! works now, the email address and password is the same for BAM! and all the projects. BAM! only uses the email/password combo when creating or changing an account, after that a hash of the email address plus password is used.

Options:

1. We use BAM! email address + project specific password, then when you change your BAM! email address you will have to re-enter the project specific password for every project (since BAM! does not store the password itself)
   
2. We use the BAM! email address by default + project specific password, then when you change your BAM! email address you will only have to re-enter the project specific password for each project that uses the BAM! email address (since BAM! does not store the password itself)
   
3. We use the BAM! email address by default + project specific password, then when you change your BAM! email address the projects that use the BAM! email address will not update and continue using the BAM! email address (until it's changed manually).
   

I'm implementing option 3, unless there are objections. It will also allow for unique email addresses.

Option 3 now implemented. I have not tested this with all projects.