Point 1 can be addressed by changing the script.
For point 2, while the script always outputs passwords of the same length
(unless changed) that wouldn't stop someone from remembering "Oh, on this box
they require the password to only be 8 characters" and so only using the
first 8 characters of the script's output.
For point number 3 the hash doesn't actually contain the salt or string so
there is nothing to crack that would conclusively reveal what they are/were.
Attacks on cryptographic hash functions focus on finding more than one input
that returns the same hash. MD5 has this problem today for example. SHA2 is
safe but yes, who knows about the future? But: Even if SHA2 were as
compromised in the future as MD5 is today, that is not in itself sufficient
to let someone know what salt was used and begin generating their own
passwords willy-nilly, even if multiple passwords were known. So they're back
to guessing. But even in that event a fix is as simple as changing from a
SHA2 to a SHA3 implementation once that's available (yes, that means changing
passwords but see the last thing below about your last point.) And so, since
they're back to guessing, passwords generated with this are subject to the
same brute force problem that any (even a randomly generated) password would
be. (At this time, brute forcing all possible possible combinations is easier
than breaking the cryptographic hash itself.)
For your last point I should point out that people should change their
passwords regularly anyway.
:)
