Cybersecurity and privacy is a topic that is front and center because of the seemingly endless stream of news about system breaches of well-established companies. It’s not a surprise then that when designing new products and functionality, there is sometimes a tendency to exaggerate the potential risks and, therefore, over-engineer solutions. As a product manager, you must be able to lead your team to an appropriate balance.
As an example, I was once working on a new module that sent a document with obfuscated URL to users. The users would then open the URL on a Smartphone and digitally accept the contract, which would kick off an internal workflow. Much to my dismay, during a technical design session, the team not only designed but implemented a grand solution that was more “secure.”
Instead of providing a seamless experience, we required that the recipient enter a 32 character password to access the document. The long password is tedious enough to type on a computer, let alone type it or even doing a copy and paste on a smartphone.
The team implemented amped-up security to address two concerns:
Concern 1: Someone can forward the email with the link, and anyone who got the email would have access to the document.
Commentary: Ignore for a moment that the password was included in the exact same email as the URL, in our context, forwarding an email was a legitimate use case as they may have had to send to a colleague or supervisor. Furthermore, there’s a precedent set with other applications such as Twitter, where there are no additional guardrails set to prevent a link from being used if it was forwarded. In the screenshot below, you’ll see that I sent a reset password link from my one email to another email, clicked on the link from my work email, and was able to change my password.
Concern 2: Using a GUID is not real security because you’re just obscuring the link.
Commentary: Google Photos security is all around obscuring the URL and not requiring an explicit password (they use this same approach with Google Drive documents). You can read more about it here. An essential part of the article is the following:
So why is that public URL more secure than it looks? The short answer is that the URL is working as a password. Photos URLs are typically around 40 characters long, so if you wanted to scan all the possible combinations, you’d have to work through ¹⁰⁷⁰ different combinations to get the right one, a problem on an astronomical scale. “There are enough combinations that it’s considered unguessable,” says Aravind Krishnaswamy, an engineering lead on Google Photos. “It’s much harder to guess than your password.” Because web traffic for Photos is encrypted with SSL, it’s also kept secret from anyone on the network who might be listening in.
After a lengthy debate, we concluded that the risks were minimal because the URLs were 40 characters long, the maximum # of unexpired URLs was 5,000 at a time, and traffic was SSL.
Security and privacy will and should continue to be an essential consideration when building a product, but as a product manager, you need to be able to get your team to go through a thought exercise to:
Test their assumptions on risk and determine whether they are real risks or just perceived risks.
If the threat is deemed real, then design the feature or product with the user in mind and avoid transferring the problem onto the user (e.g., force the user to enter a 32 character password on a SmartPhone.)
Go through a pros and cons exercise to assess the available options as a team (dev and product) before moving to implementation.