In your system, the derived password is a sha digest of a concatentation of other sha digests. It almost has the form sha(sha(SALT) || sha(RESOURCE) || sha(MASTER)), with sha() returning the ascii encoding of the base-16 representation. (The difference is three extra newline characters "\n", which makes things slightly messier). This string representation for sha-512 digests is 128 characters or 1028 bits, and sha-512 uses 1028-bit input chunks, so the final sha() call reads the other three digests aligned on chunk boundaries. (Again, few bits off because of newlines, but this is not fatal).
So DERIVED(RESOURCE) has a form
DERIVED = sha(sha(SALT) || sha(RESOURCE) || sha(MASTER))
= f(sha(sha(SALT) || sha(RESOURCE)), g(sha(MASTER)))
So for an attack: given the salt, along with one resource/derived password pair, every other password can be computed. If you know SALT, RESOURCE_1, and DERIVED_1, you know these:
sha(sha(SALT) || sha(RESOURCE_1))
DERIVED_1 = f(sha(sha(SALT) || sha(RESOURCE_1)), g(sha(MASTER)))
If that's the case, wouldn't it suffice to mix A and B, for example with byte-wise XOR?
password ::= sha(A XOR B)