In the case of the home-made "service number" authentication, why is the protection weak, and what should be done?

A secret service number passed as a parameter easily becomes common knowledge: it gets shared, people who change jobs or leave still know it, and it can be found by reverse engineering or brute force. Proper access protection (AAA) is needed, and the developer should understand the weaknesses so obscurity isn't reused next time.

The case: developer E wrote a web service that produces business forecasts. Each call triggers heavy computation, so to avoid unnecessary load he only runs it when a particular service number is passed as a parameter, and gives that number to a few selected users.

Why the secret leaks:

• it is easily passed on,
• employees who change roles take the knowledge with them, and former employees may still know it,
• reverse engineering or simple brute-force guessing can reveal it.

What to do:

• set up real access protection (AAA security),
• work through the case with the software development team: E was thinking of server load (and maybe cost), but not of security requirements such as preventing unauthorised access to the forecast data,
• show E what weaknesses his "protection" has, so the next project does not rely on security-by-obscurity again.