Google has started its journey on convincing people to move away from SMS-based verification, and start receiving push messages via the Google Prompt instead of using six-digit codes. Why does Google want us away from SMS, and why using Google Prompt instead? Let’s try to find out.
There are three major mobile operating systems, and three major cloud services. Most Android users are deep into the Google’s ecosystem. iCloud is an essential part of iOS, while cloud services provided by Microsoft under the OneDrive umbrella are used not only by the few Windows Phone and Windows 10 Mobile customers but by users of other mobile and desktop platforms.
As you may know, we have recently updated Elcomsoft Cloud Explorer, bumping the version number from 1.30 to 1.31. A very minor update? A bunch of unnamed bug fixes and performance improvements? Not really. Under the hood, the new release has major changes that will greatly affect usage experience. What exactly has changed and why, and what are the forensic implications of these changes? Bear with us to find out.
Elcomsoft Cloud Explorer 1.30 can now pull SMS (text) messages straight off the cloud, and offers enhanced location processing with support for Routes and Places. In this article, we’ll have a close look at the new features and get detailed instructions on how to use them. The first article will discuss the text messages, while enhanced location data will be covered in the one that follows.
Even before we released Elcomsoft Cloud Explorer, you’ve been able to download users’ location data from Google. What you would get then was a JSON file containing timestamped geolocation coordinates. While this is an industry-standard open data format, it provides little insight on which places the user actually visits. A full JSON journal filled with location data hardly provides anything more than timestamped geographic coordinates. Even if you pin those coordinates to a map, you’ll still have to scrutinize the history to find out which place the user has actually gone to.
Every once in a while, hi-tech companies release reports on government requests that they received and served (or not). The different companies receive a different number of requests. They don’t treat them the same way, and they don’t report them the same way, which makes the comparison difficult. In this article, we’ll try to analyze and compare government request reports published by Apple, Google and Microsoft.
Before we start discussing Google’s two-factor authentication, let’s first look how Google protects user accounts if two-factor authentication is not enabled. If Google detects an unusual sign-in attempt (such as one originating from a new device located in a different country or continent), it may prompt the user to confirm their account. This can (or cannot) be done in various ways such as receiving a verification code to an existing backup email address that was previously configured in that account. Interestingly, even receiving and entering such a code and answering all the additional security questions Google may ask about one’s account does not actually confirm anything. Without two-factor authentication, Google may easily decline sign-in requests it deems suspicious. From first-hand experience, one is then forced to change their Google Account password. (Interestingly, Microsoft exhibits similar behavior, yet the company allows using two-factor authentication in such cases even if two-factor authentication is not enabled for that account. Weird, but that’s how it works.)
Fingerprint Unlock Security: Google Android and Microsoft Hello
Biometric approach to unlocking portable electronics has been on the rise since late 2013 when Apple released iPhone 5S. Ever since, manufacturers started adding fingerprint scanners to their devices. In the world of Android, this was frequently done without paying much (if any) attention to actual security. So how do these systems compare?