Posted by Christiaan Brand, Product Manager, Google Cloud
We previously announced that starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. For supported services (e.g. G Suite, Google Cloud Platform), enterprise administrators can now allow end users to use the power button on these devices to protect against certain classes of account takeover attempts. This feature is disabled by default, however, administrators can enable it by changing DeviceSecondFactorAuthentication policy in the Google Admin console.
Before we dive deeper into this capability, let’s first cover the main use cases FIDO technology solves, and then explore how this new enhancement can satisfy an advanced requirement that can help enterprise organizations.
Main use casesFIDO technology aims to solve three separate use cases for relying parties (or otherwise referred to as Internet services) by helping to:
- Prevent phishing during initial login to a service on a new device;
- Reverify a user’s identity to a service on a device on which they’ve already logged in to;
- Confirm that the device a user is connecting from is still the original device where they logged in from previously. This is typically needed in the enterprise.
Security-savvy professionals may interpret the third use case as a special instance of use case #2. However, there are some differences, which we break down a bit further below:
- In case #2, the problem that FIDO technology tries to solve is re-verifying a user’s identity by unlocking a private key stored on the device.
- In case #3, FIDO technology helps to determine whether a previously created key is still available on the original device without any proof of who the user is.
How use case #1 works: Roaming security keys
Because the whole premise of this use case is one in which the user logs in on a brand new device they’ve never authenticated before, this requires the user to have a FIDO security key (removeable, cross-platform, or a roaming authenticator). By this definition, a built-in FIDO authenticator on Chrome OS devices would not be able to satisfy this requirement, because it would not be able to help verify the user’s identity without being set up previously. Upon initial log-in, the user’s identity is verified together with the presence of a security key (such as Google’s
Titan Security Key) previously tied to their account.
Titan Security Keys
Once the user is successfully logged in, trust is conferred from the security key to the device on which the user is logging on, usually by placing a cookie or other token on the device in order for the relying party to “remember” that the user already performed a second factor authenticator on this device. Once this step is completed, it is no longer necessary to require a physical second factor on this device because the presence of the cookie signals to the relying party that this device is to be trusted.
Optionally, some services might require the user to still periodically verify that it’s the correct user in front of the already recognized device (for example, particularly sensitive and regulated services such as financial services companies). In almost all cases, it shouldn’t be necessary for the user to also-in addition to providing their knowledge factor (such as a password) – re-present their second factor when re-authenticating as they’ve already done that during initial bootstrapping.
Note that on Chrome OS devices, your data is encrypted when you’re not logged on, which further protects your data against malicious access.
How use case #2 works: Re-authentication
Frequently referred to as “re-authentication,” use case #2 allows a relying party to reverify that the same user is still interacting with the service from a previously verified device. This mainly happens when a user performs an action that’s particularly sensitive, such as changing their password or when interacting with regulated services, such as financial services companies. In this case, a built-in biometric authenticator (e.g. a fingerprint sensor or PIN on Android devices) can be registered, which offers users a more convenient way to re-verify their identity to the service in question. In fact, we have recently enabled this use case on Android devices for some Google services.
Additionally, there are security benefits to this particular solution, as the relying party doesn’t only have to trust a previously issued cookie, but can now both verify that the right user is present (by means of a biometric) and that a particular private key is available on this particular device. Sometimes this promise is made based on key material stored in hardware (e.g. Titan security in Pixel Slate), which can be a strong indicator that the relying party is interacting with the right user on the right device.
How use case #3 works: Built-in device authenticator
The challenge of verifying that a device a user has previously logged in on is still the device from which they’re interacting with the relying party, is what the built-in FIDO authenticator on most latest-generation Chromebooks is able to help solve.
Earlier we noted that upon initial log-in, relying parties regularly place cookies or tokens on a user’s device, so they can remember that a user has previously authenticated. Under some circumstances, such as when there’s malware present on a device, it might be possible for these tokens to be exfiltrated. Asking for the “touch of a built-in authenticator” at regular intervals helps the relying party know that the user is still interacting from a legitimate device which has previously been issued a token. It also helps verify that the token has not been exfiltrated to a different device since FIDO authenticators offer increased protection against the exfiltration of the private key. This is because it’s usually housed in the hardware itself. For example, in the case of most latest-generation Chromebooks (e.g. Pixel Slate), it’s protected by hardware-based Titan security.
Pixel Slate devices are built with hardware-based Titan security
In the case of our implementation on Chrome OS, the FIDO keys are also scoped to the specific logged in user, meaning that every user on the device essentially gets their own FIDO authenticator that can’t be accessed across user boundaries. We expect this use case to be particularly useful in enterprise environments, which is why the feature is not enabled by default. Administrators can enable it in the Google Admin console.
Enabling the built-in FIDO authenticator in the Google Admin console
Even though it’s technically possible to register the built-in FIDO authenticator on a Chrome OS device as a “security key” with services, it’s best to avoid this instance as users can run an increased risk of account lockout if they ever need to sign in to the service from a different machine.
Supported ChromebooksStarting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. To see if your Chromebook can be enabled with this capability, you can navigate to chrome://system and check the “tpm-version” entry. If “vendor” equals “43524f53”, then your Chromebook is backed by Titan security.
Navigating to chrome://system on your Chromebook
Summary
In summary, we believe that this new enhancement can provide value to enterprise organizations that want to confirm that the device a user is connecting from is still the original device from which a user logged in from in the past. Most users, however, should be using roaming FIDO security keys, such as
Titan Security Key, their
Android phone, or security keys from other vendors, in order to avoid account lockouts.
What does it take to attract top cybersecurity talent?
From professional backgrounds to competitive salaries – a study delves into what it takes to build strong cybersecurity teams
The post What does it take to attract top cybersecurity talent? appeared first on WeLiveSecurity
Using a built-in FIDO authenticator on latest-generation Chromebooks
Posted by Christiaan Brand, Product Manager, Google Cloud
We previously announced that starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. For supported services (e.g. G Suite, Google Cloud Platform), enterprise administrators can now allow end users to use the power button on these devices to protect against certain classes of account takeover attempts. This feature is disabled by default, however, administrators can enable it by changing DeviceSecondFactorAuthentication policy in the Google Admin console.
Before we dive deeper into this capability, let’s first cover the main use cases FIDO technology solves, and then explore how this new enhancement can satisfy an advanced requirement that can help enterprise organizations.
FIDO technology aims to solve three separate use cases for relying parties (or otherwise referred to as Internet services) by helping to:
Security-savvy professionals may interpret the third use case as a special instance of use case #2. However, there are some differences, which we break down a bit further below:
How use case #1 works: Roaming security keys
Once the user is successfully logged in, trust is conferred from the security key to the device on which the user is logging on, usually by placing a cookie or other token on the device in order for the relying party to “remember” that the user already performed a second factor authenticator on this device. Once this step is completed, it is no longer necessary to require a physical second factor on this device because the presence of the cookie signals to the relying party that this device is to be trusted.
Optionally, some services might require the user to still periodically verify that it’s the correct user in front of the already recognized device (for example, particularly sensitive and regulated services such as financial services companies). In almost all cases, it shouldn’t be necessary for the user to also-in addition to providing their knowledge factor (such as a password) – re-present their second factor when re-authenticating as they’ve already done that during initial bootstrapping.
Note that on Chrome OS devices, your data is encrypted when you’re not logged on, which further protects your data against malicious access.
Frequently referred to as “re-authentication,” use case #2 allows a relying party to reverify that the same user is still interacting with the service from a previously verified device. This mainly happens when a user performs an action that’s particularly sensitive, such as changing their password or when interacting with regulated services, such as financial services companies. In this case, a built-in biometric authenticator (e.g. a fingerprint sensor or PIN on Android devices) can be registered, which offers users a more convenient way to re-verify their identity to the service in question. In fact, we have recently enabled this use case on Android devices for some Google services.
The challenge of verifying that a device a user has previously logged in on is still the device from which they’re interacting with the relying party, is what the built-in FIDO authenticator on most latest-generation Chromebooks is able to help solve.
Earlier we noted that upon initial log-in, relying parties regularly place cookies or tokens on a user’s device, so they can remember that a user has previously authenticated. Under some circumstances, such as when there’s malware present on a device, it might be possible for these tokens to be exfiltrated. Asking for the “touch of a built-in authenticator” at regular intervals helps the relying party know that the user is still interacting from a legitimate device which has previously been issued a token. It also helps verify that the token has not been exfiltrated to a different device since FIDO authenticators offer increased protection against the exfiltration of the private key. This is because it’s usually housed in the hardware itself. For example, in the case of most latest-generation Chromebooks (e.g. Pixel Slate), it’s protected by hardware-based Titan security.
In the case of our implementation on Chrome OS, the FIDO keys are also scoped to the specific logged in user, meaning that every user on the device essentially gets their own FIDO authenticator that can’t be accessed across user boundaries. We expect this use case to be particularly useful in enterprise environments, which is why the feature is not enabled by default. Administrators can enable it in the Google Admin console.
Even though it’s technically possible to register the built-in FIDO authenticator on a Chrome OS device as a “security key” with services, it’s best to avoid this instance as users can run an increased risk of account lockout if they ever need to sign in to the service from a different machine.
Starting with Chrome 76, most latest-generation Chromebooks gained the option to enable a built-in FIDO authenticator backed by hardware-based Titan security. To see if your Chromebook can be enabled with this capability, you can navigate to chrome://system and check the “tpm-version” entry. If “vendor” equals “43524f53”, then your Chromebook is backed by Titan security.
Summary
In summary, we believe that this new enhancement can provide value to enterprise organizations that want to confirm that the device a user is connecting from is still the original device from which a user logged in from in the past. Most users, however, should be using roaming FIDO security keys, such as Titan Security Key, their Android phone, or security keys from other vendors, in order to avoid account lockouts.
Mispadu: Advertisement for a discounted Unhappy Meal
Another in our occasional series demystifying Latin American banking trojans
The post Mispadu: Advertisement for a discounted Unhappy Meal appeared first on WeLiveSecurity
FBI warns of new North Korea malware attacks
FBI warns of new North Korea malware attacks
You may remember four years ago, there was a malware attack on Sony Pictures. That attack led to leaks of unreleased films, publications of executive salaries and passcodes.
And last year, there was the massive attack of ransomware called “WannaCry.” The WannaCry campaign has claimed 200,000 victims across 150 countries worldwide, targeting private companies and public organizations and has actually endangered the lives of people.
Now, the group that was behind those attacks is allegedly responsible for another high-profile attack.
The Department of Homeland Security and the Federal Bureau of Investigation are now reporting findings (again) of malicious malware, who they believe, come from communist North Korea.
Who are they?
These hackers from North Korea are not necessarily new news to the United States. The U.S. has been tracking this particular group of hackers since 2009.
Read full article Komando // FBI warns of new North Korea malware attacks
Mozilla’s Firefox tries closing more privacy holes with new network tech
Mashing up two network technologies — DNS and HTTPS — thwarts snooping and tampering.
BY STEPHEN SHANKLAND
Browser makers are trying to thwart network snoopers by encrypting your connections to the web servers that host websites, but Mozilla on Friday began a project to go one step further.
Firefox Nightly, a rough-around-the-edges test version of Mozilla’s browser, now includes technology called DNS over HTTPS, Mozilla said. DNS is the Domain Name System used to find the numeric addresses needed to communicate with computers across the network — 64.30.228.118 for CNET.com, for example — and HTTPS is the secure version of the Hypertext Transfer Protocol used to fetch data from websites.
Read the full article // CNET – Mashing up two network technologies
Several state agencies targeted by malware threat
Several state agencies targeted by malware threat
PROVIDENCE, R.I. (WPRI) — Some technical issues experienced by a few state agencies on Friday have been attributed to malware, according to Department of Administration public information officer Brena McCabe.
She confirmed to Eyewitness News, agencies affected are the Department of Children, Youth and Families, Department of Human Services, and the Department of Behavioral Healthcare, Developmental Disabilities, and Hospitals.
Read Full Article WPRI // Several state agencies targeted by malware threat
Don’t Pay the Ransom Unless You Really Have To
Don’t Pay the Ransom Unless You Really Have To
How hospitals can protect themselves against ransomware.
This article is part of Update or Die, a series from Future Tense about how businesses and other organizations keep up with technological change—and the cost of falling behind.
Very early on the morning of Palm Sunday last year, the Erie County Medical Center in Buffalo, New York, was infected by the SamSam ransomware. Hospital staff members first noticed the ransom demand for 24 bitcoins (worth roughly $44,000 at the time) locking up their devices at 2 a.m. on April 9, 2017, and they promptly called the hospital help desk.
Read full article Slate // How hospitals can protect themselves against Ransomware