A parking-pay mobile app includes a homegrown cryptographic module that invents its own unreviewed network protocol. What is the primary architectural vulnerability?
Select an answer to reveal the explanation.
Short Explanation
Inventing a custom crypto protocol is like welding a homemade lock for the parking meters—unique, proud, and usually easy to pick. Use battle-tested protocols and save the creativity for the interface.
Full Explanation
A parking-pay mobile app that ships a homegrown cryptographic module inventing its own unreviewed network protocol introduces a primary architectural vulnerability: custom, unvetted cryptography commonly embeds weak primitives, flawed handshakes, poor nonce/IV handling, broken authentication, and interoperability failures that trained cryptanalysts and opportunistic attackers exploit far more readily than mature, vetted protocols. Preferring homegrown crypto because attackers have “never seen it” is security through obscurity; unfamiliarity does not equal strength and often signals amateur design. Invented protocols do not remove the need for key management or certificate validation; they usually reintroduce those problems incorrectly. Accepting unreviewed crypto because the UI matches city brand colors confuses presentation with cryptographic assurance. Exam caveat: CISSP consistently favors established, publicly reviewed protocols and libraries (TLS with modern cipher suites, vetted AEAD constructions) over proprietary crypto designed in-house without expert review. Operational check: retire the custom protocol path, replace client-server protection with standard TLS and vetted libraries, commission a cryptographic design review if any custom code must remain temporarily, remove unused homebrew primitives, and verify certificate validation and key storage meet mobile secure-coding baselines before the next app release.