Secure Language Translations - Part 3 of Many - Lack of 2FA

"Ensure that subcontractors have vigorous data protection systems in place" says FINRA. In the meantime Troy Hunt has found 773 million records leaked in the dark web. We are all hurrying to find out if our emails are perfectly owned (pwned) by hackers or find out if our current preferred password is already known by criminals.

This is the third post in my Secure Language Translations. In my previous post we analyzed insecure DNS Resolution related issues. Today we will look into what you should ask your language service provider and the service providers they use in terms of their defense in place for identification (the act of being identified as a valid user by means of an ID) and authentication (the act of providing a secret to be granted access to a system). We will not discuss authorization (the act of giving you permissions in the system) today but you bet we will in the very near future. Below is the analysis of the risk related to the lack of 2FA using a simple quantitative risk management framework.

• Threat: Criminals can interact with services posing as authorized users just because they manage to get a hold of the credentials of another genuine user. Your hope to receive secure translations goes away as hackers get access to the otherwise sensitive, confidential or restricted files.
• Asset: Any service that relies on a password to grant access to the functionality it provides.
• Vulnerability: Services that validate just something that you know like a password because what you know is probably known by others as well.
• Risk: Tools exist that can be used to figure out emails and passwords in use by those email addresses. The impact is high and the likelihood for it to happen in beyond medium. As a result this is without question a hight risk.
• Safeguard: In addition to the usage of a password, enforce the use of multiple factor authentication (MFA) in your services. Just by adding an additional second factor authentication (2FA) is enough. This second factor authentication must not be also something that you know (like your password) but something that you have (like a phone), or you are (like fingerprint or retina scans). Sending a token to your email is not 2FA.

Why secure translations are mission impossible if this threat is not mitigated? Let's look at the STRIDE model:

1. Spoofing can occur. Authenticity is compromised. The criminal can do whatever it is that you can do.
2. Tampering can occur. Therefore Integrity is compromised. The bad guy can modify data.
3. Repudiation can occur. Non-repudiability is compromised. The service sees you, a valid user that has provided valid credentials.
4. Information disclosure can occur. Confidentiality is compromised. The criminal is not only accessing the service, they are most likely collecting and storing information.
5. Denial of Service (DoS) can occur. Availability is compromised. A DoS attack can occur against the service provider because the criminals know more about their system. They have after all valid credentials now. They might even create new users depending on the original user privileges. As a result they could come up with other exploits to more internal vulnerabilities through penetration testing tools and manual skills they do not lack of.
6. Elevation of Privilege might occur. Authorization might be compromised. The criminal knows now more from the system so other exploits might be on the way.

In my next post I analyze Privacy and in particular data retention combined with user rights.

You can follow the "Secure Language Translations" series in this blog, on linkedIn, Twitter or Google+. My objective is to educate executives and managers but also to help engineers in reducing the organization risk through sound security measures.