Archives For Google

Two Factors Authentication is a way to authenticate a user with an application. The name derives from the adoption of two of the three different types of authentication, that is with something you know (like a password), something you have (like a phone) or something you are (like your fingerprint or retina map).

In the old days, it was common to use only a protection based on passwords, but they have demonstrated to have multiple drawbacks: first of all, good passwords tend to be difficult to remember; typical passwords tend to be repeated for different services, therefore multiple services are compromised after the first compromission; finally, passwords tend to be related to culture, meaning that people that share the same culture will choose similar passwords. All those pitfalls are well known to hackers, who rely on them for performing massive attacks to passwords.

Nowadays, passwords are considered insecure and therefore they should not be used as the one and only authentication method, but for the least important services. Many Security Experts are declaring that passwords have lost most of not all their usefulness, and that should be replaced with something else, soon.

A better solution than using passwords alone, is to associate them to another authentication factor. The easiest and most common ones are based on something you have, and what is more common than the cellphones? That means at least SMSs: this is the reason why one of the first ways to do two factor authentication, have been by using SMSs.

What to use, then? The various Tokens are mostly safe, even if some attacks have been registered in the past (see: http://www.itworld.com/article/2744236/security/rsa-security-hit-with-serious-data-breach–securid-customers-may-be-vulnerable.html). Another option is to use one of the various Apps that are so common nowadays, something like Google Authenticator or the Microsoft Account App: provided that they are implemented securely, that the phone is secure (that is, not rooted or jailbroken), that updates are installed regularly and that both the O.S. and the App are updated regularly by their developers or makers. On some platforms, not every device is treated the same: some receive updates fast and others would not receive them at all!

So, there are many factors that impact the security of an authentication solution, but really the most important factor you should consider is: how much risk you would accept? Even the worst authentication solution has its place for some very specific implementation, if who uses it accepts the risk knowingly.

For the moment, this is enough, but the analysis of the various authentication method could be a good topic for another article.

Zero Day Vulnerabilities are new Security Issues that are found in software and that could be exploited even before who made the Software knows about that.

Google has a project called Project Zero, which collects Zero Day Vulnerabilities and notifies the maker of the Software to allow it to fix those issues, before it is too late. Google’s policy is to publish the vulnerabilities, with all the details needed to exploit them, 90 days after disclosing it to the owner of the software.

It may be me, but I am sincerely puzzled about Google policy. In the real world, most organization have a tendency to delay the application of the fixes, even security ones; so, if Google publishes the detail about the vulnerability as soon the fix is published, even with working samples about how to exploit the vulnerability, it is only natural that an attacker would enjoy a grace period when most systems are unpatched. Who would benefit of Google disclosure, then?

What Google would have to do, then? The issue is not about disclosing or not the vulnerability. I fully agree that it is better to disclose them, but what is the reason why they have to give full details about the vulnerabilities? Would not be better to give generic information about the issue and to point to the fix, omitting the more practical details that could be leveraged even by the average Joe?

Disclaimer

The author of this Blog, Simone Curzi, has been a Senior Consultant and Delivery Architect in Microsoft Consulting Services (MCS) Italy for more than 6 years and has spent a total of 15 year as a Consultant in MCS. After having spent 2 years as a Security Premier Field Engineer for Microsoft Proactive Services (CSS), he has recently joined Microsoft Global CyberSecurity Practice (GCP) as Senior Consultant.
Simone is also the Leader of Microsoft Technical Community for Application Security.
The content published here express his own personal opinions only. By any means they do not necessarily reflect Microsoft's assessments or persuasions around Security or any other topic discussed in this Site. Microsoft has not participated directly or indirectly to the preparation of the current Site, for example by providing any resource other than paying for the salary.
The content is based on public information and sanitized experiences: it will not contain Microsoft Internal-Only material nor information traceable to actual Customers, even if someone could occasionally recognize himself or herself.