You could name things more sensibly in 1Password, of course, and you should. But having a list of nearby logins in the app will certainly be more convenient than fixing every company’s identity issues. There is also the deeper, messier issue of apps calling out to URLs that do not share a name with the product or service, which can sometimes trip up apps like 1Password from linking credentials to the app you’re trying to log in to.
In the Washington, DC, area, the Washington Metropolitan Area Transit Authority (WMATA), or “Metro” to locals, manages the subways and buses (and one odd streetcar). Metro has an app that allows you to manage the money on your physical cards and set up digital payments on phones. The app is named “SmarTrip,” and it logs me out every time the sun sinks below the horizon, and 1Password can never quite associate the login page of the app with my account details. I rediscover this whenever I need to check my physical cards or wonder why an automatic reload hasn’t gone through.
Some of what I’m describing is almost certainly confirmation bias and the human tendency to remember stressful moments far more keenly than everyday actions. But I will be linking my frequent subway stations and bus stops to the SmarTrip login, along with stores, airports, and other places I want to spend less time looking at my phone while my heart rate rises.
1Password has a support page with details on how to add locations from all their desktop and mobile clients. As the firm suggests, you can also use locations for things like Wi-Fi passwords, PIN codes, credit and ATM/debit cards, and other items. When you open 1Password, everything that is “Nearby” will show up at the top of the “Home” page, and you can change how far a radius the app should take when pulling in nearby items.
1Password notes on its announcement post that it does not store, share, or track your location data, which is stored locally. Enterprise users do not have their location shared with employers. And the location feature is entirely optional. It should be available today for 1Password users whose apps are up to date, and I’m hoping that other password apps also consider offering this feature, securely, for their users.
Google’s Chrome browser might soon get a useful security upgrade: detecting passwords used in data breaches and then generating and storing a better replacement. Google’s preliminary copy suggests it’s an “AI innovation,” though exactly how is unclear.
Noted software digger Leopeva64 on X found a new offering in the AI settings of a very early build of Chrome. The option, “Automated password Change” (so, early stages—as to not yet get a copyedit), is described as, “When Chrome finds one of your passwords in a data breach, it can offer to change your password for you when you sign in.”
Chrome already has a feature that warns users if the passwords they enter have been identified in a breach and will prompt them to change it. As noted by Windows Report, the change is that now Google will offer to change it for you on the spot rather than simply prompting you to handle that elsewhere. The password is automatically saved in Google’s Password Manager and “is encrypted and never seen by anyone,” the settings page claims.
If you want to see how this works, you need to download a Canary version of Chrome. In the flags settings (navigate to “chrome://flags” in the address bar), you’ll need to enable two features: “Improved password change service” and “Mark all credential as leaked,” the latter to force the change notification because, presumably, it’s not hooked up to actual leaked password databases yet. Go to almost any non-Google site, enter in any user/password combination to try to log in, and after it fails or you navigate elsewhere, a prompt will ask you to consider changing your password.
Just in time for holiday tech-support sessions, here’s what to know about passkeys.
It’s that time again, when families and friends gather and implore the more technically inclined among them to troubleshoot problems they’re having behind the device screens all around them. One of the most vexing and most common problems is logging into accounts in a way that’s both secure and reliable.
Using the same password everywhere is easy, but in an age of mass data breaches and precision-orchestrated phishing attacks, it’s also highly unadvisable. Then again, creating hundreds of unique passwords, storing them securely, and keeping them out of the hands of phishers and database hackers is hard enough for experts, let alone Uncle Charlie, who got his first smartphone only a few years ago. No wonder this problem never goes away.
Passkeys—the much-talked-about password alternative to passwords that have been widely available for almost two years—was supposed to fix all that. When I wrote about passkeys two years ago, I was a big believer. I remain convinced that passkeys mount the steepest hurdle yet for phishers, SIM swappers, database plunderers, and other adversaries trying to hijack accounts. How and why is that?
Elegant, yes, but usable?
The FIDO2 specification and the overlapping WebAuthn predecessor that underpin passkeys are nothing short of pure elegance. Unfortunately, as support has become ubiquitous in browsers, operating systems, password managers, and other third-party offerings, the ease and simplicity envisioned have been undone—so much so that they can’t be considered usable security, a term I define as a security measure that’s as easy, or only incrementally harder, to use as less-secure alternatives.
“There are barriers at each turn that guide you through a developer’s idea of how you should use them,” William Brown, a software engineer specializing in authentication, wrote in an online interview. “None of them are deal-breaking, but they add up.”
Passkeys are now supported on hundreds of sites and roughly a dozen operating systems and browsers. The diverse ecosystem demonstrates the industry-wide support for passkeys, but it has also fostered a jumble of competing workflows, appearances, and capabilities that can vary greatly depending on the particular site, OS, and browser (or browser agents such as native iOS or Android apps). Rather than help users understand the dizzying number of options and choose the right one, each implementation strong-arms the user into choosing the vendor’s preferred choice.
The experience of logging into PayPal with a passkey on Windows will be different from logging into the same site on iOS or even logging into it with Edge on Android. And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn’t support that browser on any OS.
Another example is when I create a passkey for my LinkedIn account on Firefox. Because I use a wide assortment of browsers on platforms, I have chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account, something that isn’t possible otherwise. But it’s not as simple as all that.
When I look at the passkey in LinkedIn settings, it shows as being created for Firefox on Mac OS X 10, even though it works on all the browsers and OSes I’m using.
Screenshot showing passkey is created for Firefox on Mac OS X 10.
Why is LinkedIn indicating otherwise? The answer is that there’s no way for LinkedIn to interoperate flexibly with the browsers and OSes and vice versa. Per the FIDO2 and WebAuthn specs, LinkedIn knows only the browser and OS I used when creating the credential. 1Password, meanwhile, has no way to coordinate with LinkedIn to ensure I’m presented with consistent information that will help me keep track of this. Suddenly, using passkeys is more confusing than it needs to be for there to be utility to ordinary users.
Things get more complicated still when I want to log into LinkedIn on Firefox for Android, and am presented with the following dialog box.
Screenshot showing a dialog box with the text: “You’re using on-device encryption. Unlock your passwords to sign in.”
At this point, I don’t know if it’s Google or Firefox that’s presenting me with this non-intuitive response. I just want to open LinkedIn using the passkey that’s being synced by 1Password to all my devices. Somehow, the mysterious entity responsible for this message (it’s Google in this case) has hijacked the process in an attempt to convince me to use its platform.
Also, consider the experience on WebAuthn.io, a site that demonstrates how the standard works under different scenarios. When a user wants to enroll a physical security key to log in on macOS, they receive a dialog that steers them toward using a passkey instead and to sync it through iCloud.
Dialog box showing macOS passkeys message.
The user just wants to enroll a security key in the form of a USB dongle or smartphone and can be used when logging in on any device. But instead, macOS preempts this task with directions for creating a passkey that will be synced through iCloud. What’s the user to do? Maybe click on the “other options” in small text at the very bottom? Let’s try and see.
The dialog box that appears after clicking “other options.”
Wait, why is it still offering the option for the passkey to be synced in iCloud, and how does that qualify as “other options”? And why is the most prominent suggestion that the user “continue with Touch ID”? It isn’t until selectng “security key” that the user will see that option they wanted all along—to store the credential on a security key. Only after this step—now three clicks in—does the light on a USB security key begin blinking, and the key is finally ready to be enrolled.
Dialog box finally allows the creation of a passkey on a security key.
The dueling dialogs in this example are by no means unique to macOS.
Too many cooks in the kitchen
“Most try to funnel you into a vendor’s sync passkey option, and don’t make it clear how you can use other things,” Brown noted. “Chrome, Apple, Windows, all try to force you to use their synced passkeys by default, and you have to click through prompts to use alternatives.”
Bruce Davie, another software engineer with expertise in authentication, agreed, writing in an October post that the current implementation of passkeys “seems to have failed the ‘make it easy for users’ test, which in my view is the whole point of passkeys.”
In April, Son Nguyen Kim, the product lead for the free Proton Pass password manager, penned a post titled Big Tech passkey implementations are a trap. In it, he complained that passkey implementations to date lock users into the platform they created the credential on.
“If you use Google Chrome as your browser on a Mac, it uses the Apple Keychain feature to store your passkeys,” he wrote. “This means you can’t sync your passkeys to your Chrome profile on other devices.” In an email last month, Kim said users can now override this option and choose to store their passkeys in Chrome. Even then, however, “passkeys created on Chrome on Mac don’t sync to Chrome in iPhone, so the user can’t use it seamlessly on Chrome on their iPhone.”
Other posts reciting similar complaints are here and here.
In short, there are too many cooks in the kitchen, and each one thinks they know the proper way to make pie.
I have put these and other criticisms to the test over the past four months. I have used them on a true heterogeneous environment that includes a MacBook Air, a Lenovo X1 ThinkPad, an iPhone, and a Pixel running Firefox, Chrome, Edge, Safari, and on the phones, a large number of apps, including those for LinkedIn, PayPal, eBay, Kayak, Gmail, Amazon, and Uber. My objective has been to understand how well passkey-based authentication works over the long term, particularly for cross-platform users.
I fully agree that syncing across different platforms is much harder than it should be. So is the messaging provided during the passkey enrollment phase. The dialogs users see are dictated arbitrarily by whatever OS or browser has control at the moment. There’s no way for previously made configuration choices to be communicated to tailor dialog boxes and workflow.
Another shortcoming: There’s no programming interface for Apple, Google, and Microsoft platforms to directly pass credentials from one to the other. The FIDO2 standard has devised a clever method in an attempt to bridge this gap. It typically involves joining two devices over a secure BLE connection and using a QR code so the already-authenticated device can vouch for the trustworthiness of the other. This process is easy for some people in some cases, but it can quickly become quirky and prone to failure, particularly when fussy devices can’t connect over BLE.
In many cases, however, critics overstate the severity of these sorts of problems. These are definitely things that unnecessarily confuse and complicate the use of passkeys. But often, they’re one-time events that can be overcome by creating multiple passkeys and bootstrapping them for each device. From then on, these unphishable, unstealable credentials live on both devices, in much the way some users allow credentials for their Gmail or Apple ID to be stored in two or more browsers or password managers for convenience.
More helpful still is using a cross-platform password manager to store and sync passkeys. I have been using 1Password to do just that for a month with no problems to report. Most other name-brand password managers would likely perform as well. In keeping with the FIDO2 spec, these credentials are end-to-end encrypted.
Halfway house for password managers
With my 1Password account running on my devices, I had no trouble using a passkey to log into any enrolled site on a device running any browser. The flow was fast and intuitive. In most cases, both iOS and Android had no problem passing the key from 1Password to an app for Uber, Amazon, Gmail, or another site. Signing into phone apps is one of the bigger hassles for me. Passkeys made this process much easier, and it did so while also allowing me the added security of MFA.
This reliance on a password manager, however, largely undermines a key value proposition of passkeys, which has been to provide an entirely new paradigm for authenticating ourselves. Using 1Password to sync a password is almost identical to syncing a passkey, so why bother? Worse still, the majority of people still don’t use password managers. I’m a big believer in password managers for the security they offer. Making them a condition for using a passkey would be a travesty.
I’m not the first person to voice this criticism. David Heinemeier Hansson said much the same thing in September.
“The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access … their accounts,” wrote the Danish software engineer and programmer, who created Ruby on Rails and is the CTO of web-based software development firm 37signals. “Much the same way that two-factor authentication can do, but worse, since you’re not even aware of it.”
He continued:
Let’s take a simple example. You have an iPhone and a Windows computer. Chrome on Windows stores your passkeys in Windows Hello, so if you sign up for a service on Windows, and you then want to access it on iPhone, you’re going to be stuck (unless you’re so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!). The passkey lives on the wrong device, if you’re away from the computer and want to login, and it’s not at all obvious to most users how they might fix that.
Even in the best case scenario, where you’re using an iPhone and a Mac that are synced with Keychain Access via iCloud, you’re still going to be stuck, if you need to access a service on a friend’s computer in a pinch. Or if you’re not using Keychain Access at all. There are plenty of pitfalls all over the flow. And the solutions, like scanning a QR code with a separate device, are cumbersome and alien to most users.
If you’re going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager like 1Password.
Undermining security promises
The security benefits of passkeys at the moment are also undermined by an undeniable truth. Of the hundreds of sites supporting passkeys, there isn’t one I know of that allows users to ditch their password completely. The password is still mandatory. And with the exception of Google’s Advanced Protection Program, I know of no sites that won’t allow logins to fall back on passwords, often without any additional factor. Even then, all but Google APP accounts can be accessed using a recovery code.
This fallback on phishable, stealable credentials undoes some of the key selling points of passkeys. As soon as passkey adoption poses a meaningful hurdle in account takeovers, threat actors will devise hacks and social engineering attacks that exploit this shortcoming. Then we’re right back where we were before.
Christiaan Brandt, co-chair of the FIDO2 technical working group and an identity and security product manager at Google, said in an online interview that most users aren’t ready for true passwordless authentication.
“We have to meet users where they are,” he wrote. “When we tested messaging for passkeys, users balked at ‘replace your password with passkeys,’ but felt much more comfortable with more softened language like “you can now use a passkey to log in to your account too.’ Over time, we most definitely plan to wean users off phishable authentication factors, but we anticipate this journey to take multiple years. We really can only do it once users are so comfortable with passkeys that the fallback to passwords is (almost) never needed.”
A design choice further negating the security benefits of passkeys: Amazon, PayPal, Uber, and no small number of other sites supporting passkeys continue to rely on SMS texts for authentication even after passkeys are enrolled.
SMS-based MFA is among the weakest form of this protection. Not only can the texts be phished, but they’re also notoriously vulnerable to SIM swaps, in which an adversary gains control of a target’s phone number. As long as these less-secure fallbacks exist, passkeys aren’t much more than security theater.
I still think passkeys make sense in many cases. I’ll say more about that later. First, for a bit more context, readers should know:
Passkeys are defined in the WebAuthn spec as a “discoverable credential,” historically known as a “resident key.” The credential is in the form of a private-public key pair, which is created on the security key, which can be in the form of a FIDO-approved secure enclave embedded into a USB dongle, smartphone, or computer. The key pair is unique to each user account. The user creates the key pair after proving their identity to the website using an existing authentication method, typically a password. The private key never leaves the security key.
Going forward, when the user logs in, the site sends a security challenge to the user. The user then uses the locally stored private key to cryptographically sign the challenge and sends it to the website. The website then uses the public key it stores to verify the response is signed with the private key. With that, the user is logged in.
Under the FIDO2 spec, the passkey can never leave the security key, except as an encrypted blob of bits when the passkey is being synced from one device to another. The secret key can be unlocked only when the user authenticates to the physical key using a PIN, password, or most commonly a fingerprint or face scan. In the event the user authenticates with a biometric, it never leaves the security key, just as they never leave Android and iOS phones and computers running macOS or Windows.
Passkeys can be stored and synced using the same mechanisms millions of people already use for passwords—a password manager such as Bitwarden, Apple iCloud, Google Password Manager, or Microsoft’s cloud. Just like passwords, passkeys available in these managers are end-to-end encrypted using tried and true cryptographic algorithms.
The advent of this new paradigm was supposed to solve multiple problems at once—make authenticating ourselves online easier, eliminate the hassle of remembering passwords, and all but eradicate the most common forms of account takeovers.
When not encumbered by the problems mentioned earlier, this design provides multifactor authentication in a single stroke. The user logs in using something they have—the physical key, which must be near the device logging in. They must also use something they know—the PIN or password—or something they are—their face or fingerprint—to complete the credential transfer. The cryptographic secret never leaves the enclave embedded into the physical key.
What to tell Uncle Charlie?
In enterprise environments, passkeys can be a no-brainer alternative to passwords and authenticators. And even for Uncle Charlie—who has a single iPhone and Mac, and logs into only a handful of sites—passkeys may provide a simpler, less phishable path forward. Using a password manager to log into Gmail with a passkey ensures he’s protected by MFA. Using the password alone does not.
The takeaway from all of this—particularly for those recruited to provide technical support this week but also anyone trying to decide if it’s time to up their own authentication game: If a password manager isn’t already a part of the routine, see if it’s viable to add one now. Password managers make it practical to use a virtually unlimited number of long, randomly generated passwords that are unique to each site.
For some, particularly people with diminished capacity or less comfort being online, this step alone will be enough. Everyone else should also, whenever possible, opt into MFA, ideally using security keys or, if that’s not available, an authenticator app. I’m partial to 1Password as a password manager, Authy as an authenticator, and security keys from Yubico or Titan. There are plenty of other suitable alternatives.
I still think passkeys provide the greatest promise yet for filling the many security pitfalls of passwords and lowering the difficulty of remembering and storing them. For now, however, the hassles of using passkeys, coupled with their diminished security created by the presence of fallbacks, means no one should feel like a technophobe or laggard for sticking with their passwords. For now, passwords and key- or authenticator-based MFA remain essential.
With any luck, passkeys will someday be ready for the masses, but that day is not (yet) here.
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.
Federal prosecutors have charged a man for an alleged “hack-to-trade” scheme that earned him millions of dollars by breaking into the Office365 accounts of executives at publicly traded companies and obtaining quarterly financial reports before they were released publicly.
The action, taken by the office of the US Attorney for the district of New Jersey, accuses UK national Robert B. Westbrook of earning roughly $3.75 million in 2019 and 2020 from stock trades that capitalized on the illicitly obtained information. After accessing it, prosecutors said, he executed stock trades. The advance notice allowed him to act and profit on the information before the general public could. The US Securities and Exchange Commission filed a separate civil suit against Westbrook seeking an order that he pay civil penalties and return all ill-gotten gains.
Buy low, sell high
“The SEC is engaged in ongoing efforts to protect markets and investors from the consequences of cyber fraud,” Jorge G. Tenreiro, acting chief of the SEC’s Crypto Assets and Cyber Unit, said in a statement. “As this case demonstrates, even though Westbrook took multiple steps to conceal his identity—including using anonymous email accounts, VPN services, and utilizing bitcoin—the Commission’s advanced data analytics, crypto asset tracing, and technology can uncover fraud even in cases involving sophisticated international hacking.”
A federal indictment filed in US District Court for the District of New Jersey said that Westbrook broke into the email accounts of executives from five publicly traded companies in the US. He pulled off the breaches by abusing the password reset mechanism Microsoft offered for Office365 accounts. In some cases, Westbrook allegedly went on to create forwarding rules that automatically sent all incoming emails to an email address he controlled.
Prosecutors alleged in one such incident:
On or about January 26, 2019, WESTBROOK gained unauthorized access to the Office365 email account of Company-1 ‘s Director of Finance and Accounting (“Individual-!”) through an unauthorized password reset. During the intrusion, an auto-forwarding rule was implemented, which was designed to automatically forward content from lndividual-1 ‘s compromised email account to an email account controlled by WESTBROOK. At the time of the intrusion, the compromised email account of Individual-I contained non-public information about Company-1 ‘s quarterly earnings, which indicated that Company-1 ‘s sales were down.
Once a person gains unauthorized access to an email account, it’s possible to conceal the breach by disabling or deleting password reset alerts and burying password reset rules deep inside account settings.
Prosecutors didn’t say how the defendant managed to abuse the reset feature. Typically such mechanisms require control of a cell phone or registered email account belonging to the account holder. In 2019 and 2020 many online services would also allow users to reset passwords by answering security questions. The practice is still in use today but has been slowly falling out of favor as the risks have come to be more widely understood.
By obtaining material information, Westbrook was able to predict how a company’s stock would perform once it became public. When results were likely to drive down stock prices, he would place “put” options, which give the purchaser the right to sell shares at a specific price within a specified span of time. The practice allowed Westbrook to profit when shares fell after financial results became public. When positive results were likely to send stock prices higher, Westbrook allegedly bought shares while they were still low and later sold them for a higher price.
The prosecutors charged Westbrook with one count each of securities fraud and wire fraud and five counts of computer fraud. The securities fraud count carries a maximum penalty of up to 20 years’ prison time and $5 million in fines The wire fraud count carries a maximum penalty of up to 20 years in prison and a fine of either $250,000 or twice the gain or loss from the offense, whichever is greatest. Each computer fraud count carries a maximum five years in prison and a maximum fine of either $250,000 or twice the gain or loss from the offense, whichever is greatest.
The US Attorney’s office in the District of New Jersey didn’t say if Westbrook has made an initial appearance in court or if he has entered a plea.
Officials in Ireland have fined Meta $101 million for storing hundreds of millions of user passwords in plaintext and making them broadly available to company employees.
Meta disclosed the lapse in early 2019. The company said that apps for connecting to various Meta-owned social networks had logged user passwords in plaintext and stored them in a database that had been searched by roughly 2,000 company engineers, who collectively queried the stash more than 9 million times.
Meta investigated for five years
Meta officials said at the time that the error was found during a routine security review of the company’s internal network data storage practices. They went on to say that they uncovered no evidence that anyone internally improperly accessed the passcodes or that the passcodes were ever accessible to people outside the company.
Despite those assurances, the disclosure exposed a major security failure on the part of Meta. For more than three decades, best practices across just about every industry have been to cryptographically hash passwords. Hashing is a term that applies to the practice of passing passwords through a one-way cryptographic algorithm that assigns a long string of characters that’s unique for each unique input of plaintext.
Because the conversion works in only one direction—from plaintext to hash—there is no cryptographic means for converting the hashes back into plaintext. More recently, these best practices have been mandated by laws and regulations in countries worldwide.
Because hashing algorithms works in one direction, the only way to obtain the corresponding plaintext is to guess, a process that can require large amounts of time and computational resources. The idea behind hashing passwords is similar to the idea of fire insurance for a home. In the event of an emergency—the hacking of a password database in one case, or a house fire in the other—the protection insulates the stakeholder from harm that otherwise would have been more dire.
For hashing schemes to work as intended, they must follow a host of requirements. One is that hashing algorithms must be designed in a way that they require large amounts of computing resources. That makes algorithms such as SHA1 and MD5 unsuitable, because they’re designed to quickly hash messages with minimal computing required. By contrast, algorithms specifically designed for hashing passwords—such as Bcrypt, PBKDF2, or SHA512crypt—are slow and consume large amounts of memory and processing.
Another requirement is that the algorithms must include cryptographic “salting,” in which a small amount of extra characters are added to the plaintext password before it’s hashed. Salting further increases the workload required to crack the hash. Cracking is the process of passing large numbers of guesses, often measured in the hundreds of millions, through the algorithm and comparing each hash against the hash found in the breached database.
The ultimate aim of hashing is to store passwords only in hashed format and never as plaintext. That prevents hackers and malicious insiders alike from being able to use the data without first having to expend large amounts of resources.
When Meta disclosed the lapse in 2019, it was clear the company had failed to adequately protect hundreds of millions of passwords.
“It is widely accepted that user passwords should not be stored in plaintext, considering the risks of abuse that arise from persons accessing such data,” Graham Doyle, deputy commissioner at Ireland’s Data Protection Commission, said. “It must be borne in mind, that the passwords, the subject of consideration in this case, are particularly sensitive, as they would enable access to users’ social media accounts.”
The commission has been investigating the incident since Meta disclosed it more than five years ago. The government body, the lead European Union regulator for most US Internet services, imposed a fine of $101 million (91 million euros) this week. To date, the EU has fined Meta more than $2.23 billion (2 billion euros) for violations of the General Data Protection Regulation (GDPR), which went into effect in 2018. That amount includes last year’s record $1.34 billion (1.2 billion euro) fine, which Meta is appealing.
Google is redesigning Chrome malware detections to include password-protected executable files that users can upload for deep scanning, a change the browser maker says will allow it to detect more malicious threats.
Google has long allowed users to switch on the Enhanced Mode of its Safe Browsing, a Chrome feature that warns users when they’re downloading a file that’s believed to be unsafe, either because of suspicious characteristics or because it’s in a list of known malware. With Enhanced Mode turned on, Google will prompt users to upload suspicious files that aren’t allowed or blocked by its detection engine. Under the new changes, Google will prompt these users to provide any password needed to open the file.
Beware of password-protected archives
In a post published Wednesday, Jasika Bawa, Lily Chen, and Daniel Rubery of the Chrome Security team wrote:
Not all deep scans can be conducted automatically. A current trend in cookie theft malware distribution is packaging malicious software in an encrypted archive—a .zip, .7z, or .rar file, protected by a password—which hides file contents from Safe Browsing and other antivirus detection scans. In order to combat this evasion technique, we have introduced two protection mechanisms depending on the mode of Safe Browsing selected by the user in Chrome.
Attackers often make the passwords to encrypted archives available in places like the page from which the file was downloaded, or in the download file name. For Enhanced Protection users, downloads of suspicious encrypted archives will now prompt the user to enter the file’s password and send it along with the file to Safe Browsing so that the file can be opened and a deep scan may be performed. Uploaded files and file passwords are deleted a short time after they’re scanned, and all collected data is only used by Safe Browsing to provide better download protections.
Enlarge/ Enter a file password to send an encrypted file for a malware scan
Google
For those who use Standard Protection mode which is the default in Chrome, we still wanted to be able to provide some level of protection. In Standard Protection mode, downloading a suspicious encrypted archive will also trigger a prompt to enter the file’s password, but in this case, both the file and the password stay on the local device and only the metadata of the archive contents are checked with Safe Browsing. As such, in this mode, users are still protected as long as Safe Browsing had previously seen and categorized the malware.
Sending Google an executable casually downloaded from a site advertising a screensaver or media player is likely to generate little if any hesitancy. For more sensitive files such as a password-protected work archive, however, there is likely to be more pushback. Despite the assurances the file and password will be deleted promptly, things sometimes go wrong and aren’t discovered for months or years, if at all. People using Chrome with Enhanced Mode turned on should exercise caution.
A second change Google is making to Safe Browsing is a two-tiered notification system when users are downloading files. They are:
Suspicious files, meaning those Google’s file-vetting engine have given a lower-confidence verdict, with unknown risk of user harm
Dangerous files, or those with a high confidence verdict that they pose a high risk of user harm
The new tiers are highlighted by iconography, color, and text in an attempt to make it easier for users to easily distinguish between the differing levels of risk. “Overall, these improvements in clarity and consistency have resulted in significant changes in user behavior, including fewer warnings bypassed, warnings heeded more quickly, and all in all, better protection from malicious downloads,” the Google authors wrote.
Previously, Safe Browsing notifications looked like this:
Enlarge/ Differentiation between suspicious and dangerous warnings.
Google
Over the past year, Chrome hasn’t budged on its continued support of third-party cookies, a decision that allows companies large and small to track users of that browser as they navigate from website to website to website. Google’s alternative to tracking cookies, known as the Privacy Sandbox, has also received low marks from privacy advocates because it tracks user interests based on their browser usage.
That said, Chrome has long been a leader in introducing protections, such as a security sandbox that cordons off risky code so it can’t mingle with sensitive data and operating system functions. Those who stick with Chrome should at a minimum keep Standard Mode Safe Browsing on. Users with the experience required to judiciously choose which files to send to Google should consider turning on Enhanced Mode.
Cisco on Wednesday disclosed a maximum-security vulnerability that allows remote threat actors with no authentication to change the password of any user, including those of administrators with accounts, on Cisco Smart Software Manager On-Prem devices.
The Cisco Smart Software Manager On-Prem resides inside the customer premises and provides a dashboard for managing licenses for all Cisco gear in use. It’s used by customers who can’t or don’t want to manage licenses in the cloud, as is more common.
In a bulletin, Cisco warns that the product contains a vulnerability that allows hackers to change any account’s password. The severity of the vulnerability, tracked as CVE-2024-20419, is rated 10, the maximum score.
“This vulnerability is due to improper implementation of the password-change process,” the Cisco bulletin stated. “An attacker could exploit this vulnerability by sending crafted HTTP requests to an affected device. A successful exploit could allow an attacker to access the web UI or API with the privileges of the compromised user.”
There are no workarounds available to mitigate the threat.
It’s unclear precisely what an attacker can do after gaining administrative control over the device. One possibility is that the web user interface and application programming interface the attacker gains administrative control over make it possible to pivot to other Cisco devices connected to the same network and, from there, steal data, encrypt files, or perform similar actions. Cisco representatives didn’t immediately respond to an email. This post will be updated if a response comes later.
A security update linked to the bulletin fixes the vulnerability. Cisco said it isn’t aware of any evidence that the vulnerability is being actively exploited.
Google is making it easier for people to lock down their accounts with strong multifactor authentication by adding the option to store secure cryptographic keys in the form of passkeys rather than on physical token devices.
Google’s Advanced Protection Program, introduced in 2017, requires the strongest form of multifactor authentication (MFA). Whereas many forms of MFA rely on one-time passcodes sent through SMS or emails or generated by authenticator apps, accounts enrolled in advanced protection require MFA based on cryptographic keys stored on a secure physical device. Unlike one-time passcodes, security keys stored on physical devices are immune to credential phishing and can’t be copied or sniffed.
Democratizing APP
APP, short for Advanced Protection Program, requires the key to be accompanied by a password whenever a user logs into an account on a new device. The protection prevents the types of account takeovers that allowed Kremlin-backed hackers to access the Gmail accounts of Democratic officials in 2016 and go on to leak stolen emails to interfere with the presidential election that year.
Until now, Google required people to have two physical security keys to enroll in APP. Now, the company is allowing people to instead use two passkeys or one passkey and one physical token. Those seeking further security can enroll using as many keys as they want.
“We’re expanding the aperture so people have more choice in how they enroll in this program,” Shuvo Chatterjee, the project lead for APP, told Ars. He said the move comes in response to comments Google has received from some users who either couldn’t afford to buy the physical keys or lived or worked in regions where they’re not available.
As always, users must still have two keys to enroll to prevent being locked out of accounts if one of them is lost or broken. While lockouts are always a problem, they can be much worse for APP users because the recovery process is much more rigorous and takes much longer than for accounts not enrolled in the program.
Passkeys are the creation of the FIDO Alliance, a cross-industry group comprised of hundreds of companies. They’re stored locally on a device and can also be stored in the same type of hardware token storing MFA keys. Passkeys can’t be extracted from the device and require either a PIN or a scan of a fingerprint or face. They provide two factors of authentication: something the user knows—the underlying password used when the passkey was first generated—and something the user has—in the form of the device storing the passkey.
Of course, the relaxed requirements only go so far since users still must have two devices. But by expanding the types of devices needed, APP becomes more accessible since many people already have a phone and computer, Chatterjee said.
“If you’re in a place where you can’t get security keys, it’s more convenient,” he explained. “This is a step toward democratizing how much access [users] get to this highest security tier Google offers.”
Despite the increased scrutiny involved in the recovery process for APP accounts, Google is renewing its recommendation that users provide a phone number and email address as backup.
“The most resilient thing to do is have multiple things on file, so if you lose that security key or the key blows up, you have a way to get back into your account,” Chatterjee said. He’s not providing the “secret sauce” details about how the process works, but he said it involves “tons of signals we look at to figure out what’s really happening.
“Even if you do have a recovery phone, a recovery phone by itself isn’t going to get you access to your account,” he said. “So if you get SIM swapped, it doesn’t mean someone gets access to your account. It’s a combination of various factors. It’s the summation of that that will help you on your path to recovery.”
Google users can enroll in APP by visiting this link.
Two years ago when “Michael,” an owner of cryptocurrency, contacted Joe Grand to help recover access to about $2 million worth of bitcoin he stored in encrypted format on his computer, Grand turned him down.
Michael, who is based in Europe and asked to remain anonymous, stored the cryptocurrency in a password-protected digital wallet. He generated a password using the RoboForm password manager and stored that password in a file encrypted with a tool called TrueCrypt. At some point, that file got corrupted, and Michael lost access to the 20-character password he had generated to secure his 43.6 BTC (worth a total of about 4,000 euros, or $5,300, in 2013). Michael used the RoboForm password manager to generate the password but did not store it in his manager. He worried that someone would hack his computer and obtain the password.
“At [that] time, I was really paranoid with my security,” he laughs.
Grand is a famed hardware hacker who in 2022 helped another crypto wallet owner recover access to $2 million in cryptocurrency he thought he’d lost forever after forgetting the PIN to his Trezor wallet. Since then, dozens of people have contacted Grand to help them recover their treasure. But Grand, known by the hacker handle “Kingpin,” turns down most of them, for various reasons.
Grand is an electrical engineer who began hacking computing hardware at age 10 and in 2008 cohosted the Discovery Channel’s Prototype This show. He now consults with companies that build complex digital systems to help them understand how hardware hackers like him might subvert their systems. He cracked the Trezor wallet in 2022 using complex hardware techniques that forced the USB-style wallet to reveal its password.
But Michael stored his cryptocurrency in a software-based wallet, which meant none of Grand’s hardware skills were relevant this time. He considered brute-forcing Michael’s password—writing a script to automatically guess millions of possible passwords to find the correct one—but determined this wasn’t feasible. He briefly considered that the RoboForm password manager Michael used to generate his password might have a flaw in the way it generated passwords, which would allow him to guess the password more easily. Grand, however, doubted such a flaw existed.
Michael contacted multiple people who specialize in cracking cryptography; they all told him “there’s no chance” of retrieving his money. But last June he approached Grand again, hoping to convince him to help, and this time Grand agreed to give it a try, working with a friend named Bruno in Germany who also hacks digital wallets.
If you build a gadget that connects to the Internet and sell it in the United Kingdom, you can no longer make the default password “password.” In fact, you’re not supposed to have default passwords at all.
A new version of the 2022 Product Security and Telecommunications Infrastructure Act (PTSI) is now in effect, covering just about everything that a consumer can buy that connects to the web. Under the guidelines, even the tiniest Wi-Fi board must either have a randomized password or else generate a password upon initialization (through a smartphone app or other means). This password can’t be incremental (“password1,” “password54”), and it can’t be “related in an obvious way to public information,” such as MAC addresses or Wi-Fi network names. A device should be sufficiently strong against brute-force access attacks, including credential stuffing, and should have a “simple mechanism” for changing the password.
There’s more, and it’s just as head-noddingly obvious. Software components, where reasonable, “should be securely updateable,” should actually check for updates, and should update either automatically or in a way “simple for the user to apply.” Perhaps most importantly, device owners can report security issues and expect to hear back about how that report is being handled.
Violations of the new device laws can result in fines up to 10 million pounds (roughly $12.5 million) or 4 percent of related worldwide revenue, whichever is higher.
Besides giving consumers better devices, these regulations are aimed squarely at malware like Mirai, which can conscript devices like routers, cable modems, and DVRs into armies capable of performing distributed denial-of-service attacks (DDoS) on various targets.
As noted by The Record, the European Union’s Cyber Resilience Act has been shaped but not yet passed and enforced, and even if it does pass, would not take effect until 2027. In the US, there is the Cyber Trust Mark, which would at least give customers the choice of buying decently secured or genially abandoned devices. But the particulars of that label are under debate and seemingly a ways from implementation. At the federal level, a 2020 bill tasked the National Institutes of Standard and Technology with applying related standards to connected devices deployed by the feds.
Everyone with a Roku TV or streaming device will eventually be forced to enable two-factor authentication after the company disclosed two separate incidents in which roughly 600,000 customers had their accounts accessed through credential stuffing.
Credential stuffing is an attack in which usernames and passwords exposed in one leak are tried out against other accounts, typically using automated scripts. When people reuse usernames and passwords across services or make small, easily intuited changes between them, actors can gain access to accounts with even more identifying information and access.
In the case of the Roku attacks, that meant access to stored payment methods, which could then be used to buy streaming subscriptions and Roku hardware. Roku wrote on its blog, and in a mandated data breach report, that purchases occurred in “less than 400 cases” and that full credit card numbers and other “sensitive information” was not revealed.
The first incident, “earlier this year,” involved roughly 15,000 user accounts, Roku stated. By monitoring these accounts, Roku identified a second incident, one that touched 576,000 accounts. These were collectively “a small fraction of Roku’s more than 80M active accounts,” the post states, but the streaming giant will work to prevent future such stuffing attacks.
The affected accounts will have their passwords reset and will be notified, along with having charges reversed. Every Roku account, when next requiring a login, will now need to verify their account through a link sent to their email address. Alternatively, one can use the device ID of any linked Roku device, according to Roku’s support page. (Forcing this upgrade yourself is probably a good idea for past or present Roku owners.)
Security blog BleepingComputer reported around the time of the incident that breached Roku accounts were sold for as little as 50 cents each and likely obtained using commonly available stuffing tools that bypass brute-force protections through proxies and other means. BleepingComputer reported that “a source” tied Roku’s recent updates to its Dispute Resolution Terms, which all but locked Roku devices until a customer agreed, to the fraudulent activity. Roku told BleepingComputer that the two were not related.
Attackers have transformed hundreds of hacked sites running WordPress software into command-and-control servers that force visitors’ browsers to perform password-cracking attacks.
A web search for the JavaScript that performs the attack showed it was hosted on 708 sites at the time this post went live on Ars, up from 500 two days ago. Denis Sinegubko, the researcher who spotted the campaign, said at the time that he had seen thousands of visitor computers running the script, which caused them to reach out to thousands of domains in an attempt to guess the passwords of usernames with accounts on them.
Visitors unwittingly recruited
“This is how thousands of visitors across hundreds of infected websites unknowingly and simultaneously try to bruteforce thousands of other third-party WordPress sites,” Sinegubko wrote. “And since the requests come from the browsers of real visitors, you can imagine this is a challenge to filter and block such requests.”
Like the hacked websites hosting the malicious JavaScript, all the targeted domains are running the WordPress content management system. The script—just 3 kilobits in size—reaches out to an attacker-controlled getTaskURL, which in turn provides the name of a specific user on a specific WordPress site, along with 100 common passwords. When this data is fed into the browser visiting the hacked site, it attempts to log in to the targeted user account using the candidate passwords. The JavaScript operates in a loop, requesting tasks from the getTaskURL, reporting the results to the completeTaskURL, and then performing the steps again and again.
A snippet of the hosted JavaScript appears below, and below that, the resulting task:
With 418 password batches as of Tuesday, Sinegubko has concluded the attackers are trying 41,800 passwords against each targeted site.
Sinegubko wrote:
Attack stages and lifecycle
The attack consists of five key stages that allow a bad actor to leverage already compromised websites to launch distributed brute force attacks against thousands of other potential victim sites.
Stage 1: Obtain URLs of WordPress sites. The attackers either crawl the Internet themselves or use various search engines and databases to obtain lists of target WordPress sites.
Stage 2: Extract author usernames. Attackers then scan the target sites, extracting real usernames of authors that post on those domains.
Stage 3: Inject malicious scripts. Attackers then inject their dynamic-linx[.]com/chx.js script to websites that they have already compromised.
Stage 4: Brute force credentials. As normal site visitors open infected web pages, the malicious script is loaded. Behind the scenes, the visitors’ browsers conduct a distributed brute force attack on thousands of target sites without any active involvement from attackers.
Stage 5: Verify compromised credentials. Bad actors verify brute forced credentials and gain unauthorized access to sites targeted in stage 1.
So, how do attackers actually accomplish a distributed brute force attack from the browsers of completely innocent and unsuspecting website visitors? Let’s take a look at stage 4 in closer detail.
Distributed brute force attack steps:
When a site visitor opens an infected web page, the user’s browser requests a task from the hxxps://dynamic-linx[.]com/getTask.php URL.
If the task exists, it parses the data and obtains the URL of the site to attack along with a valid username and a list of 100 passwords to try.
For every password in the list, the visitor’s browser sends the wp.uploadFile XML-RPC API request to upload a file with encrypted credentials that were used to authenticate this specific request. That’s 100 API requests for each task! If authentication succeeds, a small text file with valid credentials is created in the WordPress uploads directory.
When all the passwords are checked, the script sends a notification to hxxps://dynamic-linx[.]com/completeTask.php that the task with a specific taskId (probably a unique site) and checkId (password batch) has been completed.
Finally, the script requests the next task and processes a new batch of passwords. And so on indefinitely while the infected page is open.
As of Tuesday, the researcher had observed “dozens of thousands of requests” to thousands of unique domains that checked for files uploaded by the visitor browsers. Most files reported 404 web errors, an indication that the login using the guessed password failed. Roughly 0.5 percent of cases returned a 200 response code, leaving open the possibility that password guesses may have been successful. On further inspection, only one of the sites was compromised. The others were using non-standard configurations that returned the 200 response, even for pages that weren’t available.
Over a four-day span ending Tuesday, Sinegubko recorded more than 1,200 unique IP addresses that tried to download the credentials file. Of those, five addresses accounted for over 85 percent of the requests:
IP
%
ASN
146.70.199.169
34.37%
M247, RO
138.199.60.23
28.13%
CDNEXT, GB
138.199.60.32
10.96%
CDNEXT, GB
138.199.60.19
6.54%
CDNEXT, GB
87.121.87.178
5.94%
SOUZA-AS, BR
Last month, the researcher observed one of the addresses—87.121.87.178—hosting a URL used in a cryptojacking attack. One possibility for the change is that the earlier campaign failed because the malicious URL it relied on wasn’t hosted on enough hacked sites and, in response, the same attacker is using the password-cracking script in an attempt to recruit more sites.
As Sinegubko notes, the more recent campaign is significant because it leverages the computers and Internet connections of unwitting visitors who have done nothing wrong. One way end users can stop this is to use NoScript or another tool that blocks JavaScript from running on unknown sites. NoScript breaks enough sites that it’s not suitable for less experienced users, and even those with more experience often find the hassle isn’t worth the benefit. One other possible remedy is to use certain ad blockers.
