Generally, SHA-3 is build to offer $2^{n/2}$ collision resistance (and $2^n$ preimage resistance).
You haven’t specified which SHA-3 you are talking about (SHA3-224/256/384/512), but even when looking at the smallest of them (SHA3-224) and assuming correct implementation, the chance of a collision is more of a theoretical nature.
Talking about implementation: what I don’t really grasp is why you would inject a 50-byte hash before, and another 50-byte hash after the password. Those might just be two individual hashes of some web app related information you’re pulling together there… but in case that’s an attempt to add some kind of security, I would like to advise you to look at HMAC-SHA3 constructions. Yet, even better would be to use solutions that were specifically designed for this kind of task, like bcrypt, scrypt or pbkdf-2.
For further reading:
- The new SHA-3 secure hash algorithm has been published in FIPS 202 (PDF).
The HMAC algorithm is described in RFC 2104 (TXT).
It may be helpful to know that the block lengths $B$ to be used in the HMAC algorithm (meaning: the byte-length of the digest input block) is given in Table 3 of FIPS 202… that’s 144 bytes for SHA3-224, 136 bytes for SHA3-256, 104 bytes for SHA3-384, and 72 bytes for SHA3-512.