A checksum of the original file would be included and encrypted by the password provided. This would prevent other users from editing the block and producing a new checksum.
This is a failed attempt to achieve integrity, with a secret password. A Message Authentication Code does that, with a secret key (see e.g. HMAC). One issue with the question's encrypted checksum is that for most document formats, it's easy to make two apparently identical documents with the same checksum. And even if we fix that by using a hash instead of a checksum, an encrypted hash is still not necessarily a proper MAC. That's because encryption is intended to provide confidentiality, not integrity. And for some common encryption systems (including the widely used and recognized AES-CTR), it's possible to alter the cryptogram obtained by encrypting a checksum/hash to match a different checksum/hash.
I believe that this would constitute a vulnerability because it would expose the password to a brute-force attack.
Yes, but there is a standard mitigation to this: using a purposely slow and salted Password-Based Key Derivation Function, such as Argon2 or scrypt, in order to generate the key of the MAC from the password (note: while PBKDF2 and it's ancestors are Password-Based Key Derivation Functions, they are obsolete, and do not seriously deter brute-force password search by powerful adversaries).
With the combination of a Password-Based Key Derivation Function and a MAC, there remains a devastating issue: the password or the key is needed to check the MAC, and that allows to forge a new MAC for a different text.
This issue is solved by using (public-key) digital signature instead of a MAC. Each user generates a public and a matching private key. The private key is necessary to make a signature, the public key allows to check it, and with that the integrity of the document, and which private key produced the signature. That could be extended to revisions (e.g. what's signed is the document as it stood when the user made the last revision. Multiple signatures of multiple states of the document can coexist, be stored in the document, and checked quickly enough).
A remaining problem is to distribute the public keys in a way ensuring their integrity and unique association to a user. One method is thru public key certificates.
Another remaining problem is storing the private keys in a manner ensuring confidentiality. That's usually done with encryption, and generating the encryption key with a Password-Based Key Derivation Function. That's standard with PGP/GPG private keyrings, and private keys matching public key certificates.
I would like to add a feature to lock tracked changes.
Is there any commonly accepted way to approach this problem?
Not much if you ask a cryptographer, beside
- The aforementioned use of digital signature with a trusted public repository of public keys, or public key certificates.
- Keeping the document on a trusted server keeping track of changes thru cryptographic authentication of users and user-originated changes, and defining the document as what's on this server; or a copy of that signed by the server.
And then the first option does not really prevents untracked changes, only bogus attribution of a change to a user that didn't originate it (assuming it's required that any change is signed). And in both options there remains the very real possibility that a user's computer is compromised, and changes to the document attributed to a user have been made contrary to the will of the user.
From a cryptographic standpoint, if one can read data using an untrusted computer, one can copy and alter it. The best crypto allows is detect that. This would be different if one assumed people can't modify what a program does. But that's not something crypto knows how to achieve on a standard, open computer.
Another option might be a blockchain. I don't really understand what that is or does (I recently asked), but can tell it does not qualify as widely accepted.