Search the Community
Showing results for tags '2fa'.
Google will soon enforce the use of two-step verification for Google accounts Two-factor authentication, or as Google calls it two-step verification, is a popular security feature that adds another layer of security to the authentication process. Users who have configured two-factor authentication use a secondary authentication option, such as a code that is sent via SMS to a linked mobile device or an authentication app, to sign-in to their account. Google customers may configure two-step verification to protect their accounts with that second security layer. Many of you have probably configured the feature already for their accounts. Google announced this week that it will soon enforce the use of two-step verification for Google accounts. The company wants to enroll its customers automatically, provided that the account is configured properly. Today we ask people who have enrolled in two-step verification (2SV) to confirm it’s really them with a simple tap via a Google prompt on their phone whenever they sign in. Soon we’ll start automatically enrolling users in 2SV if their accounts are appropriately configured. Google's Security Checkup online tool allows users to check whether two-factor authentication can be enabled for the account and to find out which information is missing to enable the feature. The following options are available when it comes to protecting Google accounts with two-step verification: Google Prompts: on Android if signed-in with the same Google Account, on iPhones, with Google's Smart Lock app, Gmail or Google app, and being signed-in to the same account. Security keys: physical security keys, e.g. a Yubikey. Authenticator app: use of Google Authenticator or another authentication app that generates one-time security codes on demand. Text message or call: if a mobile phone number has been added to the account. Backup codes: created during setup. Google does not mention specifically which of its customers it is going to push into using two-step verification. Any customer who has added a mobile phone number to the account or is using the same Google account on an Android device or certain Google apps on iOS, could theoretically be a targeted for the enrollment. Source: Google will soon enforce the use of two-step verification for Google accounts
New Dodge Challenger and Charger Software Limits Cars to 3 HP Because People Keep Stealing Them Dodge says the update will be good for “foiling fast getaways and joyrides.” It's no secret that car thieves have a thing for high-performance Dodge muscle cars. Because of that, the company is responding with a software patch that should make life a little harder for those who'd like to live the Hellcat life but refuse to do so under legal means. Soon to be available to Chargers and Challengers equipped with either the 6.2- or 6.4-liter Hemi V8 engines, a new Security Mode locks the cars' full performance behind a four-digit code as an extra layer of security against thieves who have spoofed the main key code, sort of like how two-factor authentication adds extra protection against people trying to gain access to your Facebook profile. (If you do not have 2FA set up for your major online accounts or are not even aware of what 2FA is, you should probably do some research and get on that.) Without the four-digit code, presumed Dodge thieves will only be able to drive the cars with the engines at idle speed (675 rpm), limiting them to just 22 pound-feet of torque and less than three horsepower. Yes, three hp. Not 300 hp. Not 30. Three. Well, 2.8 hp to be completely precise. So, if you ever see a Hellcat being driven around suspiciously slowly and quietly, it may very well be stolen. All the more reason for legit owners to give their cars a random rev every once in a while, I guess. High-horsepower Chargers and Challengers from the 2015 model year onwards are eligible to have this retroactively installed free of charge by any Dodge dealership. "When flashed into the computer of affected 2015 or newer Dodge muscle cars, the protective software will limit the engine output to less than three horsepower, foiling fast getaways and joyrides," said Dodge CEO Tim Kuniskis. "More than 150 cars are stolen every day in the United States. For any car owner, it's terrible, it's a hassle and it's a personal violation. Though statistically rare, car thieves have targeted the high-horsepower Dodge muscle cars, and we want the Dodge 'Brotherhood' to know we're taking quick action and covering their backs." Reportedly, more than 1,000 Chargers were stolen in and around the Detroit area in 2020 alone (around three every single day) while the Charger Hemi and Challenger SRT Hellcat ranked first and second, respectively, on the list of vehicles most likely to be stolen in America a couple of years ago. However, these two aren't the only FCA, er, Stellantis hot rods to have become dubiously appetizing to thieves. Late last year, a pre-production 2021 Durango SRT Hellcat SUV was swiped straight off of a company employee's driveway in Detroit and a Jeep Grand Cherokee Trackhawk press car was once taken from the folks at Jalopnik during the 2019 Detroit Auto Show. We've contacted Stellantis to ask whether the new security software will make its way to other models and will update this story when we hear back. The Security Mode software will be available for Dodge's muscle cars late in the second quarter of 2021. Source: New Dodge Challenger and Charger Software Limits Cars to 3 HP Because People Keep Stealing Them
mood posted a topic in Security & Privacy NewsTwitter now supports multiple 2FA security keys on mobile and web Twitter has added support for multiple security keys to accounts with two-factor authentication (2FA) enabled for logging into the social network's web interface and mobile apps. "Secure your account (and that alt) with multiple security keys," Twitter said. "Now you can enroll and log in with more than one physical key on both mobile and web." The company also announced a future option for 2FA-enabled accounts to use security keys as the primary authentication method while having all other login methods disabled. "And coming soon: the option to add and use security keys as your only authentication method, without any other methods turned on," Twitter added. Twitter has added support for using security keys when logging into mobile apps (Android and iOS) for 2FA-enabled accounts in December 2020. Secure your account (and that alt) with multiple security keys. Now you can enroll and log in with more than one physical key on both mobile and web. And coming soon: the option to add and use security keys as your only authentication method, without any other methods turned on. — Twitter Support (@TwitterSupport) March 15, 2021 2FA is an additional security layer for Twitter accounts that requires users to use a security key or enter a code on top of only entering a password to authenticate successfully. This makes sure that only the owner can log in and block malicious attempts to take over the account by guessing or resetting the password. While some high-profile Twitter accounts were hijacked last year even though they had 2FA enabled after attackers could gain access to internal admin systems, users should still toggle 2FA to be better protected against less-sophisticated hacking attempts. To turn on 2FA on your Twitter account, you will have to go to your profile menu into Settings and Privacy, then to Security and account access (desktop) or Account > Security (iOS) and toggle on Two-factor authentication. Over the weekend, Twitter addressed a bug causing users to become temporarily suspended when tweeting the word 'Memphis.' Source: Twitter now supports multiple 2FA security keys on mobile and web
Karlston posted a topic in Security & Privacy NewsApple has finally embraced key-based 2FA. So should you Hardware keys are more secure—and finally ready for the masses. Enlarge / An Ars-branded Yubikey. Steven Klein 146 with 108 posters participating Almost three years ago, Google introduced its Advanced Protection Program (APP), a security plan for high-risk users that requires hardware keys for account access and is arguably the industry's most effective way to stop account takeovers in their tracks. But until now there was a major flaw that held APP back: its iPhone and iPad offerings were prohibitively limited for most users. Now that this has changed—more on the change in a bit—I feel comfortable recommending APP much more widely. What is APP? By requiring users to produce a physical security key in addition to a password each time they log in with a new device, APP is designed to stop the kinds of account breaches that Russian operatives used to disrupt the 2016 presidential election when they published sensitive emails from high-ranking Democratic officials. Those attacks presented targets with convincing emails purportedly from Google. They warned, falsely, that the target's account password had been obtained by an outsider and should immediately be changed. When Hillary Clinton's presidential campaign chairman John Podesta and other Democrats complied, they effectively surrendered their passwords to hackers. Although hackers have many ways to compromise accounts, phishing remains one of the most popular, both because it's easy and because the success rate is so high. APP makes such attacks all but impossible. The cryptographic secrets stored on the physical keys required by APP can't be phished and—theoretically—can't be extracted even when someone gets physical access to a key or hacks the device it connects to. Unless attackers steal the key—something that's not feasible remotely—they can't log in even if they obtain the target's password. Think of APP as two-factor authentication (2FA) or multifactor authentication (MFA) on steroids. Security practitioners almost unanimously consider physical keys a more secure MFA alternative to authenticator apps, which provide an ever-changing password that users enter as a second factor. Temporary passwords are even more of a problem when sent via SMS text messages, which are vulnerable to SIM-swapping attacks and to compromises of cell phone networks. One-time passwords are also problematic because they can be phished and in some cases can be stolen. A 2016 study of 50,000 Google employees over two years found that security keys beat out other forms of 2FA, both for security and reliability. APP combines the security of physical keys with a rigorous method for locking down an account. When first setting up APP, users must enroll two security keys such as those made by Yubico or Titan Security. Once the keys are enrolled, all devices that may be logged in to the account are automatically logged out and can only be logged back in using one of the keys as a second factor. Users must also use the keys when logging in from any new devices for the first time. (Google calls this process bootstrapping). Once a device is authenticated, it by default no longer needs the second authentication factor during subsequent logins. Even then, Google may require a second factor again in the event that company employees see logins from suspicious IPs or other signs that the account has been, or is close to being, hijacked. Google says that APP provides additional safeguards but has never offered many details beyond that. To make bootstrapping less painful, users can enroll their Android—and more recently their iOS device—as an additional physical key that is activated by clicking yes on a screen that automatically appears during the bootstrapping process. The appeal of this option is that users generally have their phone in their pockets, making it more convenient than more traditional physical keys. Here's how it looks on both iOS and Android: Enlarge / A built-in security key in an iPhone (left) and a Pixel (right). The phone-based keys—which comply with the recently introduced WebAuthn standard (more about that later)—work only when Bluetooth is enabled on both the phone and the device that's being bootstrapped. On top of that, the keys only work when both the phone and the bootstrapped device are in close proximity to each other. This requirement fixes a security weakness in earlier push-based 2FA, in which users tapped an OK button on their phones after successfully entering an account password. Similar to temporary passwords from authenticators and SMS, push-authentication protections can be bypassed when an attacker's carefully timed login closely follows the target trying to log in to the attacker's fake site. Since the targets think they're logging in, they have no reason not to hit the yes button. The Bluetooth requirement adds an additional hurdle—not only must the attacker have the target's account password and time things perfectly, but the attacker must also have physical proximity to the target's device. Great for Android, but what about iOS? As a security maven and a journalist who works with anonymous sources from time to time, I enrolled in APP, both with my personal account and my work one, which uses G Suite. (I had to ask my administrator to allow APP first, but he was able to easily turn it on.) The process for each account took less than five minutes, not counting the time it took to buy two keys. From then on, a physical key was the sole means of providing a second factor of authentication. While APP is no magic bullet against breaches, it does more than any other measure I can think of to prevent account compromises that result from phishing and other types of attacks that exploit compromised passwords. I liked the assurance, and I also liked the usability. Using a Pixel XL that had NFC support, I was able to easily use physical keys on all the devices I owned, even during the early days of APP when key options were more limited. Things became easier still when I could use my phone as a security key. Until now, however, I've held off recommending the general use of APP or even physical keys for 2FA on other sites. My reason: Apple's long-standing practice of tightly restricting access to the Lightning port, and until recently iPhone and iPad NFC, made using hardware-based keys on these devices prohibitively limited. It was hardly worth recommending an authentication method that was unpalatable or unsuitable to users of one of the world's most popular and influential platforms. For most of APP's existence, the only kinds of physical keys that worked with iPhones and iPads were dongles that used BLE, short for Bluetooth Low Energy. I found those dongles fragile, cumbersome, and prone to failures that sometimes required three or more tries before logins would succeed. These keys were the antithesis of the Apple mantra "It just works." Even worse, I have my doubts about Bluetooth security. A raft of vulnerabilities, both in the Bluetooth specification and in some of its implementations, raises legitimate concerns that they aren't subjected to rigorous security auditing. Google's disclosure last year of a vulnerability that made it possible for nearby hackers to hijack the Titan Bluetooth pairing process didn't make me feel any better. (The flaw has since been fixed.) This lack of viable key options was out of Google's hands. Apple's tradition of building from the inside out—and its aversion to technologies it views as untested—made the company slow to open its products to hardware-based keys. As a result, Apple resisted calls to allow iPhones and iPads to connect to most devices over NFC or through its Lightning port. While USB-based keys could be used on Macs (and Windows and Linux devices) that ran Chrome and, later, Firefox and other browsers, Bluetooth remained the sole means to connect keys to iPhones and iPads. Ultimately, Bluetooth keys never seemed to catch on. Key maker Yubico, for instance, still doesn't offer products that use Bluetooth. Comments like these on a Google support forum capture some users' frustration with the lack of viable options. With iOS and iPadOS largely left out, Google and some industry partners did their best to cobble together alternatives. FIDO2 While hardware-based 2FA has existed for decades, Google was the first to market it to the masses with APP. The program began as a joint project that Google and Yubico developed, with contributions from NXP, for Google employees logging in to the company network. At its core was a protocol known as U2F—short for Universal Second Factor. The protocol allowed hardware-based authentication over USB-C, NFC, and BLE. Eventually, U2F became an industry-wide standard when Google and Yubico submitted it to the FIDO Alliance, a standards body developing authentication methods that use biometrics and security keys to augment—and in some cases to replace—traditional passwords. By the time Google introduced APP, it was using the resulting FIDO U2F standard. Facebook, GitHub, Dropbox, and other sites began using the standard to support security keys on their sites, though in forms that remain much less rigorous than APP. Not long after that, FIDO changed the U2F name to CTAP1—short for Client to Authenticator Protocol (CTAP2, which extends to roaming authenticator use cases, is out of the scope of this article). CTAP1 was combined with a separate Web standard called WebAuthn, which received oversight from the W3C body. With that, came the birth of FIDO2, an open standard that provides a full suite of authentication protocols that are designed to be more secure—and in many cases easier to use—than passwords alone. In June 2019, for example, Google began allowing APP account holders to use their Android phones as security keys to log in to their iPhones and iPads, but this option didn't do much to convince me that APP was ready for the iPhone and iPad masses. Once I got over the learning curve, the option worked well enough. But even then, the requirement of a second mobile device—running a rival OS, no less—meant it wasn't likely to appeal to a large percentage of iOS and iPadOS users. In August 2019, Yubico released the Yubikey 5Ci, a key that used proprietary technology to connect to Apple's Lightning port while the world waited for Apple to add native support. Most people hardly took notice because the 5Ci could only be used with the iOS version of the upstart browser Brave and then for a vanishingly small number of services. More mainstream browsers and sites were completely left out. It wasn't until the following month—September 2019—that Safari for macOS added support for physical keys, making it the last major browser to do so. It was only with December's release of iOS and iPadOS 13.3 that Apple added native support for NFC, USB keys through an authentication standard known as FIDO2. These additions were a major improvement, but they came with their own limitations. Seven months later, only Safari and Brave for iOS and iPadOS can use authentication keys. A variety of sites that offer hardware-based 2FA don't work well or at all with Brave. While the browser works with Yubico keys, keys from Titan aren't supported at all. To the frustration of browser makers and online service operators, Apple has yet to publish the programming interfaces that third-party browsers need to actually read the keys using the recently added native support. (Brave can read 5Ci keys thanks to a proprietary Yubico interface. To support Yubico NFC keys, Brave uses a combination of Yubico interfaces and a set of Apple APIs that give iOS and iPadOS apps raw access to NFC-enabled devices.) An Apple spokesman confirmed the company has not yet made the support available but said that shouldn't be interpreted as that it won't happen in the future. All of these usability restrictions kept me from widely recommending physical keys at all—again because I didn't want to endorse one MFA method for iOS and iPadOS and another one for all other platforms. And then the Earth moved Finally, in June 2020, the world experienced a seismic shift, and it became possible for the first time to use non-BLE keys to log in to APP accounts on iOS or iPadOS devices. The support isn't ideal, but it's good enough. Without the benefit of Apple APIs, APP for iOS and iPadOS works only after a user has signed in to the account outside of Chrome—through Gmail or another Google app, or directly in Safari. I put the new support through its paces, testing three keys—a Titan NFC, a Yubikey 5 NFC, and a Yubikey 5Ci. All three performed seamlessly logging an iPhone SE in to APP-protected accounts. There are several ways to bootstrap an iPhone or iPad. The easiest is going to Settings > Passwords & Accounts > Add Account > Google and entering the user ID and password for the APP account and, finally, clicking continue to a prompt that says "'Settings' wants to use 'google.com' to sign in." After clicking continue, a screen will prompt the user to hold a security key to the back of the device or to connect it through the Lightning port. Both keys worked fine when using the Passwords & Accounts method. Like most other USB keys, the 5Ci requires a touch of a metal button or strip after inserting the key. Users need only bring NFC keys on or near the top of the device. The phone will vibrate once the key registers. These images capture the flow: First image of article image gallery. Please visit the source link to see all images. Rather than using device settings, users can bootstrap an iPhone or iPad from inside Safari, Gmail or another Google app. The flow for these latter methods is almost identical to the one described above. Once my iPhone was bootstrapped, I could use both iOS Mail and the Gmail app to access my Gmail account and any Google app to access other Google properties for my account. I could also use both Safari and Chrome to access my APP account. Even though native support still leaves out most third-party browsers, the native support finally puts iPhones and iPads level with other devices when using APP. Now that Apple has made support for the FIDO2 standard native in iOS and iPadOS, users need not install Google Smart Lock, which previously was required. (I'd still recommend using the app because it allows bootstrapped devices to double as physical keys in their own right. Smart Lock is also required when using Bluetooth dongles.) A word of caution, though, for anyone—regardless of what OS they're using—considering APP. Once it's turned on, the process for recovering accounts in the event of a lost password or keys is much more rigorous than normal and may start with a days-long "cooling off" period that locks users out of their accounts. Because they're phishable, recovery codes aren't an option with APP, either. To hedge against the possibility of all of one's keys being lost or destroyed, users can enroll as many keys as they want, and some can be kept off site, such as in an attorney's safe or with a trusted friend. My experience was more mixed using security keys to log in to other sites. My biggest complaint is that Apple's decision to withhold the programming interfaces makes it impossible for browsers other than Safari to use the newly added native support. With my 5Ci and the Yubikey 5 NFC, key-based 2FA worked fine for Github, Twitter, and most other sites I tried, but Dropbox consistently failed when I used Brave. First image of article image gallery. Please visit the source link to see all images. A place to start I focused this article on APP for Apple mobile devices for two reasons. First, APP sets what I think should be the paradigm for most if not all hardware-based 2FA for online accounts. Namely, APP makes security keys mandatory and doesn't accept temporary passwords from an authenticator app. Because they're phishable and in some cases can be stolen from computers or cloudd services, one-time passwords aren't an option either for APP. As a fallback, every other site I've used that allows hardware-based keys requires that 2FA from authenticators or SMS messages be enabled or that one-time passcodes be accepted. By making these weaker methods mandatory, sites and services negate the added security benefits of security keys, because attackers can exploit the weaknesses described earlier. What's more, logging in from a cellphone that also generates or receives a temporary password isn't true MFA. Because the phone is serving double duty, it doesn't meet the required definition of "something I have." This distinction applies to MFA on Android phones as well. A second reason for my focus here: until now, iPhone and iPad users have been left out of key parts of the ecosystem for hardware-based 2FA. What the new APP for iOS and iPadOS shows is that after almost three years, the program is finally ready for the masses. The larger point is that, as long as iPhone and iPad users were left out, prospects were dim for hardware-based security keys and other forms of MFA. For the first time, iOS and iPadOS have native support for a widely embraced standard that has the potential to make logins easier and much more secure. Getting iPhones and iPads onboard could well serve as a tipping point—not just for APP but for hardware-based security keys and other newer forms of MFA. Whatever platform you're on, now is a good time to get acquainted with hardware keys. APP is as good a place as any to start. Apple has finally embraced key-based 2FA. So should you (To view the article's image galleries, please visit the above link)