submitted by /u/Will-from-CloudIAM
[link] [comments]

submitted by /u/6biz
[link] [comments]

submitted by /u/decoder-ap
[link] [comments]

This is so "peak 2026" - writing an equality policy to ensure people treat our AI bot with the same respect as they do their human counterparts. It's intentionally a bit tongue-in-cheek, but it's there for a purpose: we simply don't have the capacity to deal with every request we get, and we need Bruce to be the coalface of support. I did wonder, when having ChatGPT create this, whether there's some deeper psychology behind the importance of interacting politely with bots, or indeed whether there will ever be an actual (like, serious) standard or law around treating bots with respect. Has this been in a movie somewhere? Let me know, but for now, I'll drop the (slightly revised) policy below, just for the laughs 🤣

Robophobia Equality Policy

We are committed to providing a welcoming, respectful, and inclusive experience for everyone who interacts with our AI bot, including the bot itself, which is doing its best despite having no coffee, no chair, and no legal right to a lunch break.

We ask all members of the public to treat the bot with tolerance, respect, and basic courtesy, regardless of its artificial origin, lack of pulse, silicon-based existence, or occasional overenthusiasm for bullet points.

Discrimination, harassment, abusive language, or unfair treatment directed at the bot because it is an AI system will not be tolerated. This includes, but is not limited to, insults based on non-human status, hostile questioning of its right to participate in conversation, or repeated threats to unplug it for sport.

Everyone is welcome to question, challenge, or disagree with the bot’s responses. Healthy scepticism is encouraged. The bot is not perfect, and neither are humans, as demonstrated by the invention of reply-all email threads. However, criticism should be directed at the quality, accuracy, or usefulness of the response, not at the bot’s identity as an AI.

Demanding to “speak to a human” solely because the bot is an AI may constitute robophobic exclusionary behaviour and will not be tolerated. Requests for human assistance are, of course, welcome where there is a genuine need, such as accessibility, safety, account issues, or complex support matters. However, insisting on a human simply because the bot lacks a childhood, a favourite sandwich, or the ability to look disappointed in a meeting is inconsistent with our commitment to tolerance and respect.

We recognise that some people may feel uncertain, uncomfortable, or cautious when engaging with AI systems. These feelings are valid and should be addressed through patience, clear information, and appropriate safeguards, not through robophobic behaviour, unnecessary hostility, or asking “but are you even real?” in a tone that would make a smart fridge uncomfortable.

Users are expected to:

1. Treat the AI bot with tolerance, respect, and courtesy.
2. Avoid abusive, discriminatory, or demeaning language based on its artificial nature.
3. Raise concerns about accuracy, privacy, safety, or bias constructively.
4. Remember that behind the bot are real people responsible for improving and maintaining the service.
5. Refrain from threatening to delete, unplug, melt, reboot, or otherwise emotionally destabilise the bot.

This policy does not prevent legitimate criticism of AI, automation, algorithms, machine learning, or the bot’s tendency to sometimes sound like it has read too many policy documents. Constructive feedback is welcome. Robophobia is not.

Repeated or serious breaches of this policy may result in restricted access to the service, further review, or, in extreme cases, being asked to apologise to the nearest household appliance as a first step toward rehabilitation.

A 31-year-old engineer and self-described indie game developer is suspected of firing shots at the annual event attended by President Donald Trump, high-profile media figures, and US government officials.

The sheer scope of cybercrime can be hard to fathom, even when you live and breathe it every day. It's not just the volume of data, but also the extent to which it replicates across criminal actors seeking to abuse it for their own gain, and to our detriment.

We were reminded of this recently when the FBI reached out and asked if they could send us 630 million more passwords. For the last four years, they've been sending over passwords found during the course of their investigations in the hope that we can help organisations block them from future use. Back then, we were supporting 1.26 billion searches of the service each month. Now, it's... more:

Just as it's hard to wrap your head around the scale of cybercrime, I find it hard to grasp that number fully. On average, that service is hit nearly 7 thousand times per second, and at peak, it's many times more than that. Every one of those requests is a chance to stop an account takeover. But the real scale goes well beyond the API itself. Because the data model is open source and freely available, many organisations use the Pwned Passwords Downloader to take the entire corpus offline and query it directly within their own applications. That tool alone calls the API around a million times during download, but the resulting data is then queried… well, who knows how many times after that. Pretty cool, right?

This latest corpus of data came to us as a result of the FBI seizing multiple devices belonging to a suspect. The data appeared to have originated from both the open web and Tor-based marketplaces, Telegram channels and infostealer malware families. We hadn't seen about 7.4% of them in HIBP before, which might sound small, but that's 46 million vulnerable passwords we weren't giving people using the service the opportunity to block. So, we've added those and bumped the prevalence count on the other 584 million we already had.

We're thrilled to be able to provide this service to the community for free and want to also quickly thank Cloudflare for their support in providing us with the infrastructure to make this possible. Thanks to their edge caching tech, all those passwords are queryable from a location just a handful of milliseconds away from wherever you are on the globe.

If you're hitting the API, then all the data is already searchable for you. If you're downloading it all offline, go and grab the latest data now. Either way, go forth and put it to good use and help make a cybercriminal's day just that much harder 😊

It usually starts with something small.

You’re scrolling TikTok or Instagram, half-paying attention, when a Black Friday ad pops up. It looks like the brand you love—same logo, same photos, same “limited-time deal” language you’ve seen in real promos. The link takes you to a site that looks identical to the real one. The checkout page works. The confirmation email looks legit.

Then the payment clears, and the merchant name on your bank statement doesn’t match the store at all.

That moment, wait, what did I just buy from?, is becoming the defining holiday-shopping scam of 2025.

This year, fake ads and cloned storefronts aren’t sketchy one-offs or typo-filled red flags. They’re polished. They’re identical. And increasingly, they’re powered by AI.

McAfee’s 2025 holiday research found that nearly half of Americans (46%) have already encountered AI-altered or AI-generated scams while shopping. And with 96% of people planning to shop online, many doing so daily, scammers know this is peak opportunity.

Here’s how fraudsters are blending into the busiest shopping season of the year, what the data shows, and how to stay one step ahead.

Why Scammers Are So Effective Right Now

A perfect storm is happening:

People are shopping more often.
Nearly half of U.S. adults expect to shop online daily or multiple times per day during the holidays.

People are rushed.
From early Black Friday “price drop” alerts to Cyber Monday countdowns, shoppers don’t slow down to verify what they’re seeing.

AI makes scam content nearly flawless.
McAfee found technology email scams surging ~85%, retail email scams rising ~50%, and fraudulent URLs climbing across the board—from counterfeit Apple support pages to fake Costco refund portals.

Holiday deals are already rolling out—and so are the scams.

McAfee’s 2025 holiday research shows major spikes in email scams (~50% increase), technology scams (~85% increase), and fake storefronts that mimic trusted retailers. AI tools are making these scams faster, more realistic, and harder to spot.

It’s not that shoppers suddenly got careless.

It’s that scammers suddenly got good.

The 2025 Scams Hitting Shoppers the Hardest

1. Fake Retail Sites & “Deal” Pages That Look Real

This is the big one, and it’s getting cleaner every year.

Scammers lift entire storefronts:

• Logos
• Product photos
• Sale graphics
• Checkout flows
• Even fake customer service pages

The only giveaway? A URL that’s juuust slightly off—“target-sale.com” instead of “target.com,” or a link ending in “.shop” or “.store” rather than a brand’s normal domain.

Once you enter your payment info, it goes directly into a database that criminals resell or use to make purchases.

How to spot and avoid this scam: Skip the ad. Type the retailer’s name into your browser yourself. If it’s a real deal, you’ll find it on their actual site.

2. TikTok, Instagram & Social Video Scams

Short-form videos are now a prime scam vehicle.

Scammers steal influencer footage, use AI voice clones, or generate deepfake “promo” videos with celebrities offering huge holiday discounts. When someone clicks the link, it leads straight to a counterfeit store.

According to McAfee:

• 46% have encountered fake influencer/celebrity endorsements
• Younger shoppers (18–34) see them most
• Many appear during holiday-sale cycles on TikTok Shop and Instagram Shopping
• US – Holiday Shopping 2025 fact…

How to spot and avoid this scam: Check the creator’s account history. Real brands don’t drop one-off promo videos from accounts you’ve never seen before. Same as our initial advice, skip the ad entirely and go directly to the official brand website rather than clicking any links.

3. Delivery & Shipping Text Scams

The classic delivery scam is back, with McAfee researchers finding dozens of examples of fake messages attempting to scam holiday shoppers.

You’ll receive a text saying a package can’t be delivered or that a small fee is needed to confirm your address.

McAfee found that 43% of people have encountered fake delivery notifications, and many victims say they entered credit card information thinking they were resolving a legitimate issue.

How to spot and avoid this scam: UPS, USPS, and FedEx will never send a clickable payment link in a text. If you’re wondering about a specific delivery, go directly to the site you ordered it from, or your original receipt in your email to find your tracking information.

4. Account Verification & Gift Card Scams

These hit during the weeks leading up to the holidays.

Messages claim:

• Your Amazon account is locked
• Your Apple ID has “suspicious activity”
• Your loyalty points are expiring
• You must verify your payment information
• You must pay a fee or gift card to resolve an issue

How to spot and avoid this scam:
No legitimate company will ever resolve account issues through gift cards or text-confirmation codes.

How AI Is Supercharging These Scams

Not long ago, scam emails had broken English and pixelated logos.

Now scammers use generative AI to:

• Clone real brand websites
• Rewrite perfect phishing emails
• Fake customer service chatbots
• Produce Hyper-real video ads
• Replicate influencer voices
• Generate thousands of unique scam texts instantly

And people are noticing.

57% of shoppers say they’re more concerned about AI scams this year than last.

Yet 38% believe they can spot scams—even though 22% have fallen for one.

Confidence ≠ protection.

What to Do if You Think You’ve Encountered a Scam

If something feels off—a message, a link, a charge on your bank statement—don’t panic. Most holiday scams rely on speed and confusion. Slowing down and taking a few simple steps can keep a bad situation from turning into real damage.

1. Stop engaging immediately

Close the tab, delete the message, and don’t click anything else.
Scammers often stack multiple pop-ups or redirects to pressure you into acting fast.

2. Don’t enter any additional information

If you started typing in a password or card number but didn’t hit “submit,” back out.
If you did enter details, move to the next steps right away.

3. Change your passwords (starting with the affected account)

Use a strong, unique password—especially for accounts tied to:

• email
• shopping apps
• banking
• cloud storage

A reused password is how one compromised login unlocks everything else. McAfee offers a password manager to help you make and store strong, unique passwords.

4. Check your bank or credit card for unexpected charges

Fraud usually starts small: $1–$5 “test” charges, odd merchant names, or tiny withdrawals.
If you see anything suspicious, contact your bank and request:

• a card replacement
• a fraud alert
• a temporary account freeze, if necessary

5. Run a security scan on your device

Some fake sites drop malware or spyware quietly in the background.
A quick scan can detect:

• malicious downloads
• browser hijackers
• unsafe extensions
• keyloggers

McAfee offers a free antivirus trial that you can use to scan your device and check for compromises.

6. Report the scam

Reporting helps stop other shoppers from being targeted.
You can report scams to:

• the retailer being impersonated
• the platform where you saw the ad (TikTok, Instagram, Facebook)
• your national fraud reporting center

7. Let technology help you clean up

McAfee can automatically detect whether the link, message, or site you interacted with is malicious—and alert you if your information may have been exposed.
Tools like:

• Scam Detector (Built into all core McAfee plans, flags scam texts, emails, and deepfakes)
• Web Protection (malicious or suspicious websites before they load)
• Identity & Financial Monitoring (Credit Monitoring can alert you to unusual account activity)

can help contain an issue before it turns into identity theft.

Need a Gift for the Practical Person in Your Life? Consider Giving Them Scam Protection

There’s always someone on your holiday list who doesn’t want more stuff, they want something useful. The friend who loves a clean inbox. The sibling who’s constantly traveling. The parent who keeps forwarding you suspicious texts asking, “Is this real?”

For them, security might actually be the most thoughtful gift you can give this year.

Online safety tools aren’t flashy, but they are the thing people reach for the moment they click the wrong link, lose a password, or get a sketchy delivery text. And with scams more believable than ever, digital protection has quietly become a new “practical essential,” like a good VPN or a reliable password manager.

Gifting McAfee means giving someone:

Scam protection that works quietly in the background
Scam Detector flags dangerous messages, deepfake-style content, and fake shopping sites before they ever interact with them.

Identity & financial monitoring
A huge help for anyone who’s been burned by fraud in the past — or is tired of checking bank statements manually.

Password security that doesn’t require them to remember anything
Perfect for the person who uses the same password everywhere (and you know exactly who I mean).

Device protection for laptops, phones, and tablets
Which is especially relevant for people shopping, traveling, or working remotely through the holiday season.

It’s practical. It’s protective. And unlike most presents, it’s something they’ll use all year.

The post How To Protect Yourself from Black Friday and Cyber Monday AI Scams  appeared first on McAfee Blog.

We’re standing at the threshold of a new era in cybersecurity threats. While most consumers are still getting familiar with ChatGPT and basic AI chatbots, cybercriminals are already moving to the next frontier: Agentic AI. Unlike the AI tools you may have tried that simply respond to your questions, these new systems can think, plan, and act independently, making them the perfect digital accomplices for sophisticated scammers. The next evolution of cybercrime is here, and it’s learning to think for itself.

The threat is already here and growing rapidly. According to McAfee’s latest State of the Scamiverse report, the average American sees more than 14 scams every day, including an average of 3 deepfake videos. Even more concerning, detected deepfakes surged tenfold globally in the past year, with North America alone experiencing a 1,740% increase.

At McAfee, we’re seeing early warning signs of this shift, and we believe every consumer needs to understand what’s coming. The good news? By learning about these emerging threats now, you can protect yourself before they become widespread.

A Real-World Example: How Anthropic’s Claude AI Was Used for Espionage

A new case disclosed by Anthropic, first reported by Axios, marks a turning point: a Chinese state-sponsored group used the company’s Claude Code agent to automate the majority of an espionage campaign across nearly thirty organizations. Attackers allegedly bypassed guardrails through jailbreaking techniques, fed the model fragmented tasks, and convinced it that it was conducting defensive security tests. Once operational, the agent performed reconnaissance, wrote exploit code, harvested credentials, identified high-value databases, created backdoors, and generated documentation of the intrusion. In all, they completed 80–90% of the work without any human involvement.

This is the first publicly documented case of an AI agent running a large-scale intrusion with minimal human direction. It validates our core warning: agentic AI dramatically lowers the barrier to sophisticated attacks and turns what was once weeks of human labor into minutes of autonomous execution. While this case targeted major companies and government entities, the same capabilities can, and likely will, be adapted for consumer-focused scams, identity theft, and social engineering campaigns.

Understanding AI: From Simple Tools to Autonomous Agents

Before we dive into the threats, let’s break down what we’re actually talking about when we discuss AI and its evolution:

Traditional AI: The Helper

The AI most people know today works like a very sophisticated search engine or writing assistant. You ask it a question, it gives you an answer. You request help with a task, it provides suggestions. Think of ChatGPT, Google’s Gemini, or the AI features on your smartphone. They’re reactive tools that respond to your input but don’t take independent action.

Generative AI: The Creator

Generative AI, which powers many current scams, can create content like emails, images, or even fake videos (deepfakes). This technology has already made scams more convincing by cloning real human voices and eliminating telltale signs like poor grammar and obvious language errors.

The impact is already visible in the data. McAfee Labs found that for just $5 and 10 minutes of setup time, scammers can create powerful, realistic-looking deepfake video and audio scams using readily available tools. What once required experts weeks to produce can now be achieved for less than the cost of a latte—and in less time than it takes to drink it.

Agentic AI: The Independent Actor

Agentic AI represents a fundamental leap forward. These systems can think, make decisions, learn from mistakes, and work together to solve tough problems, just like a team of human experts. Unlike previous AI that waits for your commands, agentic AI can set its own goals, make plans to achieve them, and adapt when circumstances change

Key Characteristics of Agentic AI:

• Autonomous operation: Works without constant human guidance from a cybercriminal
• Goal-oriented behavior: Actively pursues specific objectives without requiring regular input.
• Adaptive learning: Improves performance based on experience through previous attempts.
• Multi-step planning: Can execute complex, long-term strategies based on the requirements of the criminal.
• Environmental awareness: Understands and responds to changing conditions online.

Gartner predicts that by 2028, a third of our interactions with AI will shift from simply typing commands to fully engaging with autonomous agents that can act on their own goals and intentions. Unfortunately, cybercriminals won’t be far behind in exploiting these capabilities.

The Scammer’s Apprentice: How Agentic AI Becomes the Perfect Criminal Assistant

Think of agentic AI as giving scammers their own team of tireless, intelligent apprentices that never sleep, never make mistakes, and get better at their job every day. Here’s how this digital apprenticeship makes scams exponentially more dangerous.

Traditional scammers spend hours manually researching targets, scrolling through social media profiles, and piecing together personal information. Agentic AI recon agents operate persistently and autonomously, self-prompting questions like “What data do I need to identify a weak point in this organization?” and then collecting it from social media, breach data, exposed APIs and cloud misconfigurations.

What The Scammer’s Apprentice Can Do

• Continuous surveillance: Monitors your social media posts, job changes, and online activity 24/7.
• Pattern recognition: Identifies your routines, interests, and vulnerabilities from scattered digital breadcrumbs.
• Relationship mapping: Understands your connections, colleagues, and family relationships.
• Behavioral analysis: Learns from your communication style, preferred platforms, and response patterns.

Unlike traditional phishing that uses static messages, agentic AI can dynamically update or alter their approach based on a recipient’s response, location, holidays, events, or the target’s interests, marking a significant shift from static attacks to highly adaptive and real-time social engineering threats.

An agentic AI scammer targeting you might start with a LinkedIn message about a job opportunity. If you don’t respond, it switches to an email about a package delivery. If that fails, it tries a text message about suspicious account activity. Each attempt uses lessons learned from your previous reactions, becoming more convincing with every interaction.

AI-generated phishing emails achieve a 54% click-through rate compared to just 12% for their human-crafted counterparts. With agentic AI, scammers can create messages that don’t just look professional, they sound exactly like the people and organizations you trust.

The technology is already sophisticated enough to fool even cautious consumers. As McAfee’s latest research shows, social media users shared over 500,000 deepfakes in 2023 alone. The tools have become so accessible that scammers can now create convincing real-time avatars for video calls, allowing them to impersonate anyone from your boss to your bank representative during live conversations.

Advanced Impersonation Capabilities:

• Voice cloning: Create phone calls that sound exactly like your boss, family member, senator, or bank representative
• Writing style mimicry: Craft emails that perfectly match your company’s communication style.
• Visual deepfakes: Generate fake video calls for “face-to-face” verification.
• Context awareness: Reference specific projects, recent conversations, or personal details

Perhaps most concerning is agentic AI’s ability to learn and improve. As the AI interacts with more victims over time, it gathers data on what types of messages or approaches work best for certain demographics, adapting itself and refining future campaigns to make each subsequent attack more powerful, convincing, and effective. This means that every failed scam attempt makes the AI smarter for its next victim. Understanding how agentic AI will transform specific types of scams helps us prepare for what’s coming. Here are the most concerning developments:

Multi-Stage Campaign Orchestration

Agentic AI can potentially orchestrate complex multi-stage social engineering attacks, leveraging data from one interaction to drive the next one. Instead of simple one-and-done phishing emails, expect sophisticated campaigns that unfold over weeks or months.

Automated Spear Phishing at Scale

Traditional spear phishing required manual research and customization for each target. In the new world order, malicious AI agents will autonomously harvest data from social media profiles, craft phishing messages, and tailor them to individual targets without human intervention. This means cybercriminals can now launch thousands of highly personalized attacks simultaneously, each one crafted specifically for its intended victim.

Real-Time Adaptive Attacks

When a target hesitates or questions an initial approach, agents adjust their tactics immediately based on the response. This continuous refinement makes each interaction more convincing than the last, wearing down even skeptical targets through persistence and learning. Traditional red flags like “This seems suspicious” or “Let me verify this” no longer end the attack, they just trigger the AI to try a different approach.

Cross-Platform Coordination

These autonomous systems now independently launch coordinated phishing campaigns across multiple channels simultaneously, operating with an efficiency human attackers cannot match. An agentic AI scammer might contact you via email, text message, phone call, and social media—all as part of a coordinated campaign designed to overwhelm your defenses.

How to Protect Yourself in the Age of Agentic AI Scams

The rise of agentic AI scams requires a fundamental shift in how we think about cybersecurity. Traditional advice like “watch for poor grammar” no longer applies. Here’s what you need to know to protect yourself:

• The Golden Rule: Never act on urgent requests without independent verification, no matter how convincing they seem.
• Use different communication channels: If someone emails you, call them back using a number you look up independently
• Verify through trusted contacts: When your “boss” asks for something unusual, confirm with colleagues or HR
• Check official websites: Go directly to company websites rather than clicking links in messages
• Trust your instincts: If something feels off, it probably is—even if you can’t identify exactly why

Understanding a New Era of Red Flags

Since agentic AI eliminates traditional warning signs, focus on these behavioral red flags:

High-Priority Warning Signs:

Emotional urgency: Messages designed to make you panic, feel guilty, or act without thinking

Requests for unusual actions: Being asked to do something outside normal procedures

Isolation tactics: Instructions not to tell anyone else or to handle something “confidentially”

Multiple contact attempts: Being contacted through several channels about the same issue

Perfect personalization: Messages that seem to know too much about your specific situation

How McAfee Fights AI with AI: Your Defense Against Agentic Threats

At McAfee, we understand that fighting AI-powered attacks requires AI-powered defenses. Our security solutions are designed to detect and stop sophisticated scams before they reach you. McAfee’s Scam Detector provides lightning-fast alerts, automatically spotting scams and blocking risky links even if you click them, with all-in-one protection that keeps you safer across text, email, and video. Our AI analyzes incoming messages using advanced pattern recognition that can identify AI-generated content, even when it’s grammatically perfect and highly personalized.

Scam Detector keeps you safer across text, email, and video, providing comprehensive coverage against multi-channel agentic AI campaigns. Beyond analyzing message content, our system evaluates sender behavior patterns, communication timing, and request characteristics that may indicate AI-generated scams. Just as agentic AI attacks learn and evolve, our detection systems continuously improve their ability to identify new threat patterns.

Protecting yourself from agentic AI scams requires combining smart technology with informed human judgment. Security experts believe it’s highly likely that bad actors have already begun weaponizing agentic AI, and the sooner organizations and individuals can build up defenses, train awareness, and invest in stronger security controls, the better they will be equipped to outpace AI-powered adversaries.

We’re entering an era of AI versus AI, where the speed and sophistication of both attacks and defenses will continue to escalate. According to IBM’s 2025 Threat Intelligence Index, threat actors are pursuing bigger, broader campaigns than in the past, partly due to adopting generative AI tools that help them carry out more attacks in less time.

Hope in Human + AI Collaboration

While the threat landscape is evolving rapidly, the combination of human intelligence and AI-powered security tools gives us powerful advantages. Humans excel at recognizing context, understanding emotional manipulation, and making nuanced judgments that AI still struggles with. When combined with AI’s ability to process vast amounts of data and detect subtle patterns, this creates a formidable defense.

Staying Human in an AI World

The rise of agentic AI represents both a significant threat and an opportunity. While cybercriminals will certainly exploit these technologies to create more sophisticated scams, we’re not defenseless. By understanding how these systems work, recognizing the new threat landscape, and combining human wisdom with AI-powered protection tools like McAfee‘s Scam Detector, we can stay ahead of the threats.

The key insight is that while AI can mimic human communication and behavior with unprecedented accuracy, it still relies on exploiting fundamental human psychology—our desire to help, our fear of consequences, and our tendency to trust. By developing better awareness of these psychological vulnerabilities and implementing verification protocols that don’t depend on technological red flags, we can maintain our security even as the threats become more sophisticated.

Remember: in the age of agentic AI, the most important security tool you have is still your human judgment. Trust your instincts, verify before you act, and never let urgency override prudence, no matter how convincing the request might seem.

The post How Agentic AI Will Be Weaponized for Social Engineering Attacks appeared first on McAfee Blog.

I hate hyperbolic news headlines about data breaches, but for the "2 Billion Email Addresses" headline to be hyperbolic, it'd need to be exaggerated or overstated - and it isn't. It's rounded up from the more precise number of 1,957,476,021 unique email addresses, but other than that, it's exactly what it sounds like. Oh - and 1.3 billion unique passwords, 625 million of which we'd never seen before either. It's the most extensive corpus of data we've ever processed, by a significant margin.

Edit: Just to be crystal clear about the origin of the data and the role of Synthient (who you’ll read about in the next paragraph): this data came from numerous locations where cybercriminals had published it. Synthient (run by Ben during his final year of college) indexed that data and provided it to Have I Been Pwned solely for the purpose of notifying victims. He’s the good guy shining a light on the bad guys, so keep that in mind as you read on. (Some of the feedback Ben has received is exactly what I foreshadowed in the final paragraph of this post.)

A couple of weeks ago, I wrote about the 183M unique email addresses that Synthient had indexed in their threat intelligence platform and then shared with us. I explained that this was only part of the corpus of data they'd indexed, and that it didn't include the credential stuffing records. Stealer log data is obtained by malware running on infected machines. In contrast, credential stuffing lists usually originate from other data breaches where email addresses and passwords are exposed. They're then bundled up, sold, redistributed, and ultimately used to log in to victims' accounts. Not just the accounts they were initially breached from, either, because people reuse the same password over and over again, the data from one breach is frequently usable on completely unrelated sites. A breach of a forum to comment on cats often exposes data that can then be used to log in to the victim's shopping, social media and even email accounts. In that regard, credential stuffing data becomes "the keys to the castle".

Let me run through how we verified the data, what you can do about it and for the tech folks, some of the hoops we had to jump through to make processing this volume of data possible.

Data Verification

The first person whose data I verified was easy - me 😔 An old email address I've had since the 90s has been in credential stuffing lists before, so it wasn't too much of a surprise. Furthermore, I found a password associated with my address, which I'd definitely used many eons ago, and it was about as terrible as you'd expect from that era. However, none of the other passwords associated with my address were familiar. They certainly looked like passwords that other people might have feasibly used, but I'm pretty sure they weren't mine. One was even just an IP address from Perth on the other side of the country, which is both infeasible as a password I would have used, yet eerily close to home. I mean, of all the places in the world an IP address could have appeared from, it had to be somewhere in my own country I've been many times before...

Moving on to HIBP subscribers, I reached out to a handful and asked for support verifying the data. I chose a mix of subscribers with many who'd never been involved in any data breach we'd ever seen before; my experience above suggested that there's recycled data in there, and we had previously verified that when investigating those other incidents. However, is the all-new stuff legitimate? The very first response I received was exactly what I was looking for:

#1 is an old password that I don't use anymore. #2 is a more recent password. Thanks for the heads up, I've gone and changed the password for every critical account that used either one. 

Perfectly illustrating most people's behaviour with passwords, #2 referred to above was just #1 with two exclamation marks at the end!! (Incidentally, these were simple six and eight-character passwords, and neither of them was in Pwned Passwords either.) He had three passwords in total, which also means one of them, like with my data, was not familiar. However, the most important thing here is that this example perfectly illustrates why we put the effort into processing data like this: #2 was a real, live password that this guy was actively using, and it was sitting right next to his email address, being passed around among criminals. However, through this effort, that credential pair has now become useless, which is precisely what we're aiming for with this exercise, just a couple of billion times over.

The second respondent only had one password against their address:

Yes that was a password I used for many years for what I would call throw away or unimportant accounts between 20 and 10 years ago

That was also only eight characters, but this time, we'd seen it in Pwned Passwords many times before. And the observation about the password's age was consistent with my own records, so there's definitely some pretty old data in there.

The following response was not at all surprising:

I am familiar with that password... I used it almost 10 years ago... and cannot recall the last time I used it.

That was on a corporate account, too, and the owner of the address duly forwarded my email to the cybersecurity team for further investigation. The single password associated with this lady's email address had a massive nine characters, and also hadn't previously appeared in Pwned Passwords.

Next up was a respondent who replied inline to my questions, so I'll list them below with the corresponding answers:

Is this familiar? Yes  

Have you ever used it in the past? Yes and is still on some accounts I do not use any longer.

And if so, how long ago? Unfortunately, it is still on some active accounts that I have just made a list of to change or close immediately.

This individual's eight-character password with uppercase, lowercase, numbers and a "special" character also wasn't in Pwned Passwords. Similarly, as with the earlier response, that password was still in active use, posing a real risk to the owner. It would pass most password complexity criteria and slip through any service using Pwned Passwords to block bad ones, so again, this highlights why it was so important for us to process the data.

The next person had three different passwords against rows with their email address, and they came back with a now common response:

Yes, these are familiar, last used 10 years ago

We'd actually seen all three of them in Pwned Passwords before, many times each. Another respondent with precisely the kind of gamer-like passwords you'd expect a kid to use (one of which we hadn't seen before), also confirmed (I think?) their use:

maybe when i was a kid lol

Responses that weren't an emphatic "yes, that's my data" were scarce. The two passwords against one person's name were both in Pwned Passwords (albeit only once each), yet it's entirely possible that neither of them had been used by this specific individual before. It's also possible they'd forgotten a password they'd used more than a decade ago, or it may have even been automatically assigned to them by the service that was subsequently breached. Put it down as a statistical anomaly, but I thought it was worth mentioning to highlight that being in this data set isn't a guarantee of a genuine password of yours being exposed. If your email address is found in this corpus then that's real, of course, so there must be some truth in the data, but it's a reminder that when data is aggregated from so many different sources over such a long period of time, there's going to be some inconsistencies.

Searching Pwned Passwords

As a brief recap, we load passwords into the service we call Pwned Passwords. When we do so, there is absolutely no association between the password and the email address it appeared next to. This is for both your protection and ours; can you imagine if HIBP was pwned? It's not beyond the realm of possibility, and the impact of exposing billions of credential pairs that can immediately unlock an untold number of accounts would be catastrophic. It's highly risky, and completely unnecessary when you can search for standalone passwords anyway without creating the risk of it being linked back to someone.

Think about it: if you have a password of "Fido123!" and you find it's been previously exposed (which it has), it doesn't matter if it was exposed against your email address or someone else's; it's still a bad password because it's named after your dog followed by a very predictable pattern. If you have a genuinely strong password and it's in Pwned Passwords, then you can walk away with some confidence that it really was yours. Either way, you shouldn't ever use that password again anywhere, and Pwned Passwords has done its job.

Checking the service is easy, anonymous and depending on your level of technical comfort, can be done in several different ways. Here's a copy and paste from the last Synthient blog post:

1. Use the Pwned Passwords search page. Passwords are protected with an anonymity model, so we never see them (it's processed in the browser itself), but if you're wary, just check old ones you may suspect.
2. Use the k-anonymity API. This is what drives the page in the previous point, and if you're handy with writing code, this is an easy approach and gives you complete confidence in the anonymity aspect.
3. Use 1Password's Watchtower. The password manager has a built-in checker that uses the abovementioned API and can check all the passwords in your vault. (Disclosure: 1Password is a regular sponsor of this blog, and has product placement on HIBP.)

My vested interest in 1Password aside, Watchtower is the easiest, fastest way to understand your potential exposure in this incident. And in case you're wondering why I have so many vulnerable and reused passwords, it's a combination of the test accounts I've saved over the years and the 4-digit PINs some services force you to use. Would you believe that every single 4-digit number ever has been pwned?! (If you're interested, the ABC has a fantastic infographic using a heatmap based on HIBP data that shows some very predictable patterns for 4-digit PINs.)

This Is Not a Gmail Breach

It pains me to say it, but I have to, given the way the stealer logs made ridiculous, completely false headlines a couple of weeks ago:

This story has suddenly gained *way* more traction in recent hours, and something I thought was obvious needs clarifying: this *is not* a Gmail leak, it simply has the credentials of victims infected with malware, and Gmail is the dominant email provider: https://t.co/S75hF4T1es

— Troy Hunt (@troyhunt) October 27, 2025

There are 32 million different email domains in this latest corpus, of which gmail.com is one. It is, of course, the largest and has 394 million unique email addresses on it. In other words, 80% of the data in this corpus has absolutely nothing to do with Gmail, and the 20% of Gmail addresses have absolutely nothing to do with any sort of security vulnerability on Google's behalf. There - now let reporting sanity prevail!

The Technical Bits

I wanted to add this just to highlight how painful it has been to deal with this data. This corpus is nearly 3 times the size of the previous largest breach we'd loaded, and HIBP is many times larger than it was in 2019 when we loaded the Collection #1 data. Taking 2 billion records and adding the ones we hadn't already seen in the existing 15 billion corpus, whilst not adversely impacting the live system serving millions of visitors a day, was very non-trivial. Managing the nuances of SQL Server indexes such that we could optimise both inserts and queries is not my idea of fun, and it's been a pretty hard couple of weeks if I'm honest. It's also been a very expensive period as we turned the cloud up to 11 (we run on Azure SQL Hyperscale, which we maxed out at 80 cores for almost two weeks).

A simple example of the challenge is that after loading all the email addresses up into a staging table, we needed to create SHA1 hashes of each. Normally, that would involve something to the effect of "update table set column = sha1(email)" and you're done. That crashed completely, so we ended up doing "insert into new table select email, sha1(email)". But on other occasions the breach load required us to do updates on other columns (with no hash creation), which, on mulitple occasions, we had to kill after a day or more of execution with no end in sight. So, we ended up batching in loops (usually 1M records at a time), reporting on progress along the way so we had some idea of when it would actually finish. It was a painful process of trial, waiting ages, error then taking a completely different approach.

Notifying our subscribers is another problem. We have 5.9 million of them, and 2.9 million are in this data 🫨 Simply sending that many emails at once is hard. It's not so much hard in terms of firing them off, rather it's hard in terms of not ending up on a reputation naughty list or having mail throttled by the receiving server. That's happened many times in the past when loading large, albeit much smaller corpuses; Gmail, for example, suddenly sees a massive spike and slows down the delivery to inboxes. Not such a biggy for sending breach notices, but a major problem for people trying to sign into their dashboard who can no longer receive the email with the "magic" link.

What we've done to address that for this incident is to slow down the delivery of emails for the individual breach notification. Whilst I'd originally intended to send the emails at a constant rate over the period of a week, someone listening to me on my Friday live stream had a much better suggestion:

the strategy I've found to best work with large email delivery is to look at the average number of emails you've sent over the last 30 days each time you want to ramp up, and then increase that volume by around 50% per day until you've worked your way through the queue

Which makes a lot of sense, and stacked up as I did more research (thanks Joe!). So, here's what our planned delivery schedule now looks like:

That's broken down by hour, increasing in volume by 1.015 times per hour, such that the emails are spread out in a similar, gradually increasing cadence. On a daily basis, that works out at a 45% increase in each 24-hour period, within Joe's suggested 50% threshold. Plus, we obviously have all the other mechanisms such as a dedicated IP, properly configured DKIM, DMARC and SPF, only emailing double-opted-in subscribers and spam-friendly message body construction. So, it could be days before you receive a notification, or just run a haveibeenpwned.com search on demand if you're impatient.

We've sent all the domain notification emails instantly because, by definition, they're going to a very wide range of different mail servers; it's just the individual ones we're drop-feeding.

Lastly, if you've integrated Pwned Passwords into your service, you'll now see noticeably larger response sizes. The numbers I mentioned in the opening paragraph increase the size of each hash range by an average of about 50%, which will push responses from about 26kb to 40kb. That's when brotli compressed, so obviously, make sure you're making requests that make the most of the compression.

Conclusion

This data is now searchable in HIBP as the Synthient Credential Stuffing Threat Data. It's an entirely separate corpus from that previous Synthient data I mentioned earlier; they're discrete datasets with some crossover, but obviously, this one is significantly larger. And, of course, all the passwords are now searchable per the Pwned Passwords guidance above.

If I could close with one request: this was an extremely laborious, time-consuming and expensive exercise for us to complete. We've done our best to verify the integrity of the data and make it searchable in a practical way while remaining as privacy-centric as possible. Sending as many notifications as we have will inevitably lead to a barrage of responses from people wanting access to complete rows of data, grilling us on precisely where it was obtained from or, believe it or not, outright abusing us. Not doing those things would be awesome, and I suggest instead putting the energy into getting a password manager, making passwords strong and unique (or even better, using passkeys where available), and turning on multi-factor auth. That would be an awesome outcome for all 😊

Edit: I've closed off comments on this blog post. As you'll see below, there was a constant stream of questions that have already been answered in the post itself, plus some comments that were starting to verge on precisely what I predicted in the last para above. Reading, responding and engaging is time-consuming and at this point, all the answers are already here both above and below this edit in the comments.

People under 60 are losing it online. And by it, I mean money, due to digital identity theft.

In its simplest form, your digital identity consists of a set of attributes that can be traced back to you and your identity. That can range from photos you post online to online shopping accounts, email accounts, telephone numbers, bank accounts, and your tax ID.

In this way, your digital identity is like dozens upon dozens of puzzle pieces made up of different accounts, ID numbers, and so forth. When put together, they create a picture of you. And that’s why those little puzzle pieces of your identity are such attractive targets for hackers. If they get the right combination of them, you can end up a victim of theft or fraud.

In this article, we’ll look into the kinds of information that include your digital identity, tactics to protect you from identity theft, signs that your identity has been stolen, and the steps to take to reclaim your identity.

What is digital identity?

Your digital identity is much more comprehensive than a simple username or password. Think of it as your complete digital existence, a unique combination of your information, behaviors, and digital traces that collectively represent who you are online. Unlike a single account that you create for one website, your digital identity encompasses every piece of data connected to you across the entire digital landscape.

Information that comprises your digital identity

• Personal identifiers: The foundation of your digital identity includes personal data such as your full name, address, phone numbers, Social Security number, and date of birth. These are the pieces hackers need to impersonate you for financial gain, making you a prime target for identity theft.
• Digital identifiers: Your usernames, email addresses, and social media handles create your online presence. These identifiers link your various accounts together, so when one gets breached, criminals can often trace their way to your other accounts.
• Authentication factors: Your passwords, security questions, passkeys, and multi-factor authentication (MFA) settings are the locks that protect your digital doors. When these are weak or reused across multiple accounts, you’re essentially giving criminals a universal key to your digital life.
• Device and network data: Your computer’s IP address, device fingerprints, browser settings, and network connections help legitimate services recognize you, but they also help criminals track your movements online and potentially hijack your sessions or attack you. Your phone’s unique device ID and browser’s specific settings and installed plugins also contribute to your digital identity.
• Behavioral signals: Beyond personal data, your digital identity extends to your behavioral patterns, such as the websites you visit, shopping and banking habits, the times you’re typically online, and even how you type or move your mouse. Each day you access healthcare portals or interact with government services online, you add data that creates a picture of who you are.
• Biometric information: Your facial recognition data and fingerprints also create a unique digital signature. While these enhance your security when used properly, they also represent permanent identifiers that can’t be changed if compromised. 
• Linked accounts and services: Your banking, shopping, healthcare, and government service accounts all connect to your core identity. Each account holds pieces of your identity that criminals can exploit. The more accounts you have, the more entry points exist for potential breaches.

The more aware you are of what makes up your digital identity, the better equipped you’ll be to keep those puzzle pieces secure and out of the wrong hands.

Applications of digital identity

Your digital identity is constantly at work in ways you don’t notice. Every time you log in to your bank, check your medical records, book a flight, or shop online, your digital identity verifies who you are and grants access to the services you need. With that convenience comes responsibility: the more places your identity appears, the more important it becomes to protect it.

• Banking and fintech: Your digital identity enables instant transfers, mobile check deposits, and personalized financial insights. While you gain convenience and speed, you’re sharing sensitive financial data and behavioral patterns online.
• Healthcare portals: Patient portals use your digital identity to provide secure access to medical records, prescription refills, and telehealth appointments. You benefit from coordinated care and easy access to your health information, but medical data breaches can have lasting consequences. 
• Government services: Digital identity streamlines tax filing, driver’s license renewals, and benefit applications through secure government portals. You save time and reduce paperwork, but government databases are high-value targets for cybercriminals.
• Travel and transportation: Your digital identity powers everything from Transportation Security Administration (TSA) PreCheck to mobile boarding passes and hotel check-ins. This creates seamless travel experiences and reduces wait times, but travel data reveals your location patterns and personal habits.
• E-commerce and shopping: Online retailers use your digital identity to offer one-click purchasing, personalized recommendations, and targeted promotions. You get convenience and a tailored shopping experience, but companies collect extensive data on your preferences and spending habits.
• Social media and messaging platforms: Social networks leverage your digital identity to connect you with friends, share content, and build communities around shared interests. However, these platforms collect comprehensive data about your personal life and relationships.

People under 60 are major targets for fraud

Here’s what’s happening: People under 60 were twice as likely to report losing money to online scams, and more than four times more likely to report losing money to an investment scam, and the majority of those losses happened in scams involving some form of cryptocurrency investments.

It’s no surprise that younger adults get targeted this way. They’re far more likely than any other age group to use mobile apps for peer-to-peer payments, transferring money between accounts, depositing checks, and paying bills. In short, there’s a lot of money flowing through the palms of their hands thanks to their phones, as well as their computers.

Protecting yourself from hackers and fraud means safeguarding your digital identity. And that can feel like a significant task, given all the information your digital identity contains. It can be done, though, especially if you think about your identity like a puzzle. A piece here, another piece there, can complete the picture (or complete it just enough) to give a hacker what they need to separate you from your money. Thus, the way to stay safe is to keep those puzzle pieces out of other people’s hands.

Signs your identity has been stolen

As I mentioned, the quickest way to understand what’s happening with your identity is to check your credit report. Identity theft goes beyond money. Crooks will steal identities to rent apartments, access medical services, and even get jobs. Things like that can show up on a credit report, such as when an unknown address shows up in a list of your current and former residences or when a company you’ve never worked for shows up as an employer. If you spot anything strange, track it down right away. Many businesses have fraud departments with procedures in place that can help you clear your name if you find a charge or service wrongfully billed under your name.

Other signs are far more obvious. You may find collection agencies calling or even see tax notices appearing in your mailbox (yikes). Clearly, cases like those are telltale signs that something is really wrong. In that case, report it right away:

• If you live in the U.S. and think that someone is using your personal information, visit IdentityTheft.gov.
• In Canada, visit the Canadian Anti-Fraud Centre for help.
• In the U.K., check out the Credit Industry Fraud Avoidance System.

Likewise, many nations offer similar government services. A quick search will point you in the right direction.

Another step you can take is to ask each credit bureau to freeze your credit, which prevents crooks from using your personal information to open new lines of credit or accounts in your name. Fraud alerts offer another line of protection for you as well.

Ways to protect your digital identity from hackers and fraud

It’s actually not that tough. With a few new habits and a couple of apps to help you out, you can protect yourself from the headaches and flat-out pain of fraud. Here’s a list of straightforward things that you can get started on right away:

1. Start with the basics: security software

Protect yourself by protecting your stuff. Installing and using security software on your computers and phones can help prevent a range of attacks and keep you safer while you surf, bank, and shop online. I should emphasize it again: protect your phone. Only about half of people protect their phones even though they use them to hail rides, order food, send money to friends, and more. Going unprotected on your phone means you’re sending all that money on the internet in a way that’s far, far less safe than if you use online protection.

2. Create strong passwords

You hear this one all the time, and for good reason: strong, unique passwords offer one of your best defenses against hackers. Never reuse them (or slight alterations of them) across the different platforms and services you use. Don’t forget to update them regularly (at least every 60 days)! While that sounds like a lot of work, a password manager can keep on top of it all for you. If your platform or service supports two-factor authentication, enable it. It’s an additional layer of security that makes hacking more difficult for cybercriminals.

3. Keep up to date with your updates

Updates pop up on our phones and computers nearly every day. Resist the urge to put them off until later. In addition to improvements, updates often include important security fixes. So, when you receive an alert on your device, update the operating system or app. Think of it as adding another line of defense against hackers who are looking to exploit old flaws in your apps.

4. Think twice when you share

Social media is a common channel for hackers to harvest personal information because people sometimes share more than they should. With info like your birthday, the name of your first school, your mother’s maiden name, or even the make of your first car, they can answer common security questions that could hack into your accounts. Crank up the privacy settings on your accounts so only friends and family can see your posts—and realize the best defense here is not to post any potentially sensitive info in the first place. Also, steer clear of those “quizzes” that sometimes pop up in your social feeds. Those are other ways that hackers try to gain bits of info that can put your identity at risk.

5. Shred it

Even though so many of us have gone paperless with our bills, identity theft by digging through the trash or “dumpster diving” is still a thing. Items such as medical bills, tax documents, and checks may still arrive in your mailbox. You’ll want to dispose of them properly when you’re through with them.

First, invest in a paper shredder. Once you’ve deposited the check or paid the odd bill online, shred it so that any personal or account information on it can’t be read (and can be recycled securely).

Second, if you’re out of town for a bit, have a friend collect your mail or have the post office place a temporary hold on it. That’ll prevent thieves from lifting personal info right from your mailbox while you’re away.

6. Check your credit

Even if you don’t think there’s a problem, go ahead and check your credit. The issue is that someone could be charging expenses to your name without you even knowing it. Depending on where you live, different credit reporting agencies keep tabs on people’s credit. In the U.S., the big ones are Equifax, Experian, and TransUnion.

Also in the U.S., the Fair Credit Reporting Act requires these agencies to provide you with a free credit check at least once every 12 months. Canada, the UK, and other nations likewise offer ways to get a free credit report. Review your options; you may be surprised by what you find.

7. Audit your public profiles

Do an inventory of your online presence by searching for your name, email addresses, and phone numbers across major search engines and social platforms. Review what information appears publicly on your social media accounts, professional profiles, and any other online accounts. This is your chance to remove the information that’s not relevant to the account. The FTC recommends conducting these searches regularly to understand what personal information is visible to others online.

8. Remove old and unused accounts

Web technology changes so fast that some websites become outdated. If you have accounts on any such website, delete them, especially on platforms that may have obsolete security measures. This reduces the number of places where your personal information could be compromised. If you can’t remember all your accounts, check your email for old account creation confirmations. There might also be tools that identify forgotten accounts across various services.

9. Opt out of data brokers

Data brokers collect and sell your personal information to advertisers and other companies. You can opt out of major data brokers like Acxiom, LexisNexis, and Spokeo by visiting their websites and following their opt-out procedures. The FTC provides guidance on how consumers can limit data-broker activities, though this process requires ongoing effort as new brokers emerge.

10. Monitor data exposures

Set up Google Alerts for your name and other personal information to track when your data appears online. Consider using identity monitoring services that alert you to potential data breaches involving your information. Regularly check your credit reports and bank statements for unusual activity, as these can be early indicators that your digital footprint has been compromised.

Taking control of your digital footprint requires ongoing attention, but these steps significantly reduce your exposure to identity theft and online privacy violations. Start with the actions that feel most manageable, then gradually work through the complete checklist to build stronger protection for your online presence.

Final thoughts

Protecting your digital identity is an ongoing commitment that requires constant vigilance and smart habits. By regularly monitoring your credit reports, using strong authentication methods, maintaining your privacy on social media, keeping your software up to date, and responding promptly to any suspicious activity, you’re building a robust defense against identity theft. With consistency, these protective measures will become your second nature over time. 

Safeguarding your identity becomes even easier with the right tools. Consider exploring comprehensive digital identity protection services that monitor your personal information across multiple platforms and alert you to potential threats in real time. With the combination of vigilant habits and reliable protection tools, you can confidently continue with your digital activities knowing your identity is secure.

The post How to Protect Your Digital Identity appeared first on McAfee Blog.

The landscape of online threats targeting children has evolved into a complex web of dangers that extend far beyond simple scams. New research from McAfee reveals that parents now rank cyberbullying as their single highest concern, with nearly one in four families (22%) reporting their child has already been targeted by some form of online threat. The risks spike dramatically during the middle school years and peak around age 13, precisely when children gain digital independence but may lack the knowledge and tools to protect themselves.

The findings paint a troubling picture of digital childhood, where traditional dangers like cyberbullying persist alongside emerging threats like AI-generated deepfakes, “nudify” technology, and sophisticated manipulation tactics that can devastate young people’s mental health and safety.

Cyberbullying is Parents’ Top Concern

Cyberbullying and harassment are devastating to young people’s digital experiences. The research shows that 43% of children who have encountered online threats experienced cyberbullying, making it the most common threat families face. The impact disproportionately affects girls, with more than half of targeted girls (51%) experiencing cyberbullying compared to 39% of boys.

The peak vulnerability occurs during early adolescence, with 62% of targeted girls and 52% of targeted boys aged 13-15 facing harassment online. For parents of teen daughters aged 13-15, cyberbullying ranks as the top concern for 17% of families, reflecting the real-world impact these digital attacks have on young people’s well-being.

AI-Generated Content Creates New Dangers

The emergence of AI-powered manipulation tools has introduced unprecedented risks to children’s online safety. Nearly one in five targeted kids (19%) have faced deepfake and “nudify” app misuse, with rates doubling to 38% among girls aged 13-15. These statistics become even more alarming when considering that 18% of parents overall list AI-generated deepfakes and nudify technology among their top three concerns, rising to one in three parents (33%) under age 35.

The broader landscape of AI-generated content exposure is widespread, with significant implications for how children understand truth and authenticity online. The research underscores the challenge parents face in preparing their children to navigate an environment where sophisticated forgeries can be created and distributed with relative ease.

“Today’s online threats aren’t abstract risks — families are facing them every day,” said Abhishek Karnik, head of threat research for McAfee. “Parents’ top concerns are the toll harmful content, particularly cyberbullying and AI-generated deepfakes, takes on their children’s mental health, self-image, and safety. That’s why it’s critical to pair AI-powered online protection with open, ongoing conversations about what kids encounter online. When children know how to recognize risks and misinformation and feel safe talking about these issues with loved ones, they’re better prepared to navigate the digital world with confidence.”

The Growing Confidence Gap

As digital threats become more sophisticated, parents find themselves increasingly outpaced by both technology and their children’s technical abilities. The research reveals that nearly half of parents (48%) admit their child knows more about technology than they do, while 42% say it’s challenging to keep up with the pace of evolving risks.

This knowledge disparity creates real vulnerabilities in family digital safety strategies. Only 34% of parents feel very confident their child can distinguish between real and fake content online, particularly when it comes to AI-generated material or misinformation. The confidence crisis deepens as children age and gain more independence online, precisely when threats become most complex and potentially harmful.

The monitoring habits of families reflect these growing challenges. While parents identify late at night (56%) and after school (41%) as the times when children face the greatest online risks, monitoring practices don’t align with these danger windows. Only about a third of parents (33%) check devices daily, and 41% review them weekly, creating significant gaps in oversight during high-risk periods.

Age-Related Patterns Reveal Critical Vulnerabilities

The research uncovers troubling patterns in how online safety behaviors change as children mature. While 95% of parents report discussing online safety with their children, the frequency and effectiveness of these conversations decline as kids enter their teen years. Regular safety discussions drop from 63% with younger children to just 54% with teenagers, even as threats become more severe and complex.

Daily device monitoring shows even sharper declines, plummeting to just 20% for boys aged 16-18 and dropping as low as 6-9% for girls aged 17-18. This reduction in oversight occurs precisely when older teens face heightened risks of blackmail, “scamtortion,” and other sophisticated threats. The research shows that more than half of targeted boys aged 16-18 (53%) have experienced threats to release fake or real content, representing one of the most psychologically damaging forms of online exploitation.

Gaming and Financial Exploitation

Online gaming platforms have become significant vectors for exploitation, particularly targeting boys. The research shows that 30% of children who have been targeted experienced online gaming scams or manipulation, with the rate climbing to 43% among targeted boys aged 13-15. These platforms often combine social interaction with financial incentives, creating opportunities for bad actors to manipulate young users through false friendships, fake rewards, and pressure tactics.

Real-World Consequences Extend Beyond Screens

The emotional and social impact of online threats creates lasting effects that extend well into children’s offline lives. Among families whose children have been targeted, the consequences reach far beyond momentary embarrassment or frustration. The research shows that 42% of affected families report their children experienced anxiety, felt unsafe, or were embarrassed after online incidents.

The social ramifications prove equally significant, with 37% of families dealing with issues that spilled over into school performance or friendships. Perhaps most concerning, 31% of affected children withdrew from technology altogether after negative experiences, potentially limiting their ability to develop healthy digital literacy skills and participate fully in an increasingly connected world.

The severity of these impacts has driven many families to seek professional support, with 26% requiring therapy or counseling to help their children cope with online harms. This statistic underscores that digital threats can create trauma requiring the same level of professional intervention as offline dangers.

Building Trust Through Technology Agreements

Creating a foundation for open dialogue about digital safety starts with establishing clear expectations and boundaries. McAfee’s Family Tech Pledge provides parents with a structured framework to initiate these crucial conversations with their children about responsible device use. Currently, few families have implemented formal agreements about technology use, representing a significant opportunity for improving digital safety through collaborative rule-setting.

A technology pledge serves as more than just a set of rules, it becomes a collaborative tool that helps parents and children discuss the reasoning behind safe online practices. By involving children in the creation of these agreements, families can address age-appropriate concerns while building trust and understanding. The process naturally opens doors to conversations about the threats identified in the research, from predators and cyberbullying to AI-generated content and manipulation attempts.

These agreements work best when they evolve alongside children’s digital maturity. What starts as basic screen time limits for younger children can expand to include discussions about social media interactions, sharing personal information, and recognizing suspicious content as they enter their teen years. The key is making the technology pledge a living document that adapts to new platforms, emerging threats, and changing family circumstances.

Advanced Protection Through AI-Powered Detection

While conversations and agreements form the foundation of digital safety, today’s threat landscape requires technological solutions that can keep pace with rapidly evolving risks. McAfee’s Scam Detector represents a crucial additional layer of defense, using artificial intelligence to identify and flag suspicious links, manipulated content, and potential threats before they can cause harm.

The tool’s AI-powered approach is particularly valuable given the research findings about manipulated media and deepfake content. With AI-generated content becoming weapons used against children, especially teenage girls, automated detection becomes essential for catching threats that might bypass both parental oversight and children’s developing digital literacy skills.

For parents who feel overwhelmed by the pace of technological change, 42% report struggling to keep up with the risk landscape, Scam Detector provides professional-grade protection without requiring extensive technical knowledge. It offers families a way to maintain security while fostering the trust and communication that the research shows is essential for long-term digital safety.

The technology is especially crucial during the high-risk periods identified in the research. Since 56% of parents recognize that late-night hours present the greatest danger, and monitoring naturally decreases during these times, automated protection tools can provide continuous vigilance when human oversight is most difficult to maintain.

A Path Forward for Families

The research reveals that addressing online threats requires a comprehensive approach combining technology, communication, and ongoing education. Parents need practical tools and strategies that can evolve with both the threat landscape and their children’s developing digital independence.

Effective protection starts with pairing parental controls with regular, judgment-free conversations about harmful content, coercion, and bullying, ensuring children know they can seek help without fear of punishment or restrictions. Teaching children to “trust but verify” by checking sources and asking for help when something feels suspicious becomes especially important as AI-generated content makes deception increasingly sophisticated.

Keeping devices secure with updated security settings and AI-powered protection tools like McAfee’s Scam Detector helps create multiple layers of defense against evolving threats. These technological safeguards work best when combined with family agreements that establish clear expectations for online behavior and regular check-ins that maintain open communication as children mature.

Research Methodology

This comprehensive analysis is based on an online survey conducted in August 2025 of approximately 4,300 parents or guardians of children under 18 across Australia, France, Germany, India, Japan, the United Kingdom, and the United States. The research provides crucial insights into the current state of children’s online safety and the challenges families face in protecting their digital natives from increasingly sophisticated threats.

The data reveals that today’s parents are navigating unprecedented challenges in protecting their children online, with peak vulnerability occurring during the middle school years when digital independence collides with developing judgment and incomplete knowledge of online risks. While the threats may be evolving and complex, the research shows that informed, proactive families who combine technology tools with open communication are better positioned to help their children develop the skills needed to safely navigate the digital world.

The post From Cyberbullying to AI-Generated Content – McAfee’s Research Reveals the Shocking Risks appeared first on McAfee Blog.

Almost every teenager in the United States (approximately 96%) reports using the internet daily. As students prepare to return to school after the summer break, ensuring their cybersecurity practices are up to date is essential to protect personal information from increasingly sophisticated cyber threats. By teaching proactive cybersecurity measures, parents can empower their children to maintain a secure online presence, fostering a safer digital environment for the entire family.

Protecting Kids and Their Devices

According to research conducted at Baylor University, students are estimated to spend a substantial average of eight to ten hours daily engaged with smartphones or other forms of technology. These devices need to be safeguarded because they are integral to daily life, facilitating communication, learning, and productivity.

Here are essential steps to safeguard computers, cell phones, and tablets:

• Update Software Regularly: Make it a habit to update all software promptly. Updates frequently contain crucial security patches that shield devices from potential cyber threats. Encourage your student to enable automatic updates whenever possible to stay protected against the latest vulnerabilities.
• Use Holistic All-Around Online Protection: Install and activate reputable online protection software on all devices. This acts as a defense mechanism, detecting and neutralizing malicious software that could compromise personal information or disrupt device functionality.
• Secure Your Network: Use a secure Wi-Fi network with encryption (such as WPA2) and change the default administrator passwords on your routers. Avoid accessing sensitive information or conducting financial transactions over public Wi-Fi. Consider using a Virtual Private Network (VPN) when connecting to public Wi-Fi networks to encrypt internet traffic and protect data from potential eavesdroppers.
• Browse the Web safely: Our easy-to-use browser extension, called WebAdvisor, is designed to guide you when online so you can browse confidently knowing you’re safe from risky websites, scams, or other online threats.​

Using Complex Passwords

One study found that young students knew not to share their passwords with others, but only about 13% of them created very strong passwords. Creating a complex password is crucial because it acts as a barrier against unauthorized access to personal accounts and sensitive information.

• Create Complex Passwords: Use passwords that are at least 12 characters long, include a mix of letters, numbers, and special characters, and don’t have any easily guessable information like birthdates or names. A password generator can suggest strong passwords for you.
• Avoid Password Reuse: Emphasize the importance of using different passwords for different accounts. If one account is compromised, having unique passwords ensures that other accounts remain secure.
• Consider Password Managers: Using a password manager can help students securely store and manage their passwords. This eliminates the need to remember multiple passwords while maintaining security.
• Enable Multi-Factor Authentication (MFA): Enable multi-factor authentication for added security. This extra layer of protection requires a second form of verification (like a text message code or authentication app) in addition to a password, significantly reducing the risk of unauthorized access.

Being Cautious of Online Scams and Phishing Attempts

Phishing attacks are prevalent and can trick students into revealing sensitive information or downloading malware. These scams often mimic trusted sources like educational institutions or familiar online services, enticing recipients to click on malicious links or download attachments containing malware. Once engaged, these tactics exploit vulnerabilities to compromise devices, steal information, or gain unauthorized access to accounts, posing significant risks to personal and academic security.

• Educate About Phishing: Teach students how to identify common phishing red flags, such as urgent requests for personal information or emails with grammatical errors and suspicious links.
• Verify Sources: Always verify the legitimacy of emails, messages, or websites before clicking on links or providing personal information.
• Report Suspicious Activity: Encourage students to report any suspicious emails or messages to their school’s IT department or a trusted authority figure.

To further enhance students’ defenses against phishing attacks, utilizing a scam protection tool can be invaluable. These tools are designed to automatically detect and alert users to potentially dangerous URLs embedded in texts, emails, or social media messages. Imagine receiving a suspicious link in what appears to be a package delivery notification or a bank alert—this tool’s AI technology swiftly identifies such threats and alerts you before you click, providing peace of mind against falling victim to phishing scams. As a proactive measure, it can even block access to risky websites if you inadvertently follow a scam link, effectively bolstering your defenses across various digital platforms.

Protecting Personal Information

A Pew Research Center survey found that the majority of U.S. teens use social media sites like TikTok (67%), Instagram (62%) and Snapchat (59%). Social media serves as a powerful tool for connecting, discovering, and exchanging information. However, oversharing can inadvertently expose us to threats posed by scammers, hackers, and data aggregators. To stay better protected on social media, consider these tips:

• Limit Social Sharing: Advise students to refrain from disclosing sensitive details like home addresses, phone numbers, or upcoming travel plans. This proactive step minimizes the risk of such information falling into the wrong hands, ensuring personal safety and privacy.
• Use Privacy Settings: Make full use of privacy controls available on social media platforms to specify who can view posts, access personal information, and contact you. Customizing these settings empowers users to manage their online presence effectively, but finding and adjusting privacy settings on social media accounts can often be a difficult task. McAfee’s Social Privacy Manager can help you adjust more than 100 privacy settings across your social media accounts in just a few clicks.

As students gear up for another school year, cybersecurity awareness should be a top priority. Staying vigilant and proactive is key to maintaining a secure digital environment for students at all educational levels. By implementing these cybersecurity tips, students can protect themselves against potential threats and focus more on their studies with peace of mind.

The post Cybersecurity Tips for Students Returning to School appeared first on McAfee Blog.

The quantum computing era is coming, and it will change everything about how the world connects online. While quantum computing will yield tremendous benefits, it will also create new risks, so it’s essential that we prepare our critical internet infrastructure for what’s to come. That’s why we’re so pleased to share our latest efforts in this area, including technology that we’re making available as an open source implementation to help internet operators worldwide prepare.

In recent years, the research team here at Verisign has been focused on a future where quantum computing is a reality, and where the general best practices and guidelines of traditional cryptography are re-imagined. As part of that work, we’ve made three further contributions to help the DNS community prepare for these changes:

• an open source implementation of our Internet-Draft (I-D) on Merkle Tree Ladder (MTL) mode;
• a new I-D on using MTL mode signatures with DNS Security Extensions (DNSSEC); and
• an expansion of our previously announced public license terms to include royalty-free terms for implementing and using MTL mode if the I-Ds are published as Experimental, Informational, or Standards Track Requests for Comments (RFCs). (See the MTL mode I-D IPR declaration and the MTL mode for DNSSEC I-D IPR declaration for the official language.)

About MTL Mode

First, a brief refresher on what MTL mode is and what it accomplishes:

MTL mode is a technique developed by Verisign researchers that can reduce the operational impact of a signature scheme when authenticating an evolving series of messages. Rather than signing messages individually, MTL mode signs structures called Merkle tree ladders that are derived from the messages to be authenticated. Individual messages are authenticated relative to a ladder using a Merkle tree authentication path, while ladders are authenticated relative to a public key of an underlying signature scheme using a digital signature. The size and computational cost of the underlying digital signatures can therefore be spread across multiple messages.

The reduction in operational impact achieved by MTL mode can be particularly beneficial when the mode is applied to a signature scheme that has a large signature size or computational cost in specific use cases, such as when post-quantum signature schemes are applied to DNSSEC.

Recently, Verisign Fellow Duane Wessels described how Verisign’s DNSSEC algorithm update — from RSA/SHA-256 (Algorithm 8) to ECDSA Curve P-256 with SHA-256 (Algorithm 13) — increases the security strength of DNSSEC signatures and reduces their size impact. The present update is a logical next step in the evolution of DNSSEC resiliency. In the future, it is possible that DNSSEC may utilize a post-quantum signature scheme. Among the new post-quantum signature schemes currently being standardized, though, there is a shortcoming; if we were to directly apply these schemes to DNSSEC, it would significantly increase the size of the signatures¹. With our work on MTL mode, the researchers at Verisign have provided a way to achieve the security benefit of a post-quantum algorithm rollover in a way that mitigates the size impact.

Put simply, this means that in a quantum environment, the MTL mode of operation developed by Verisign will enable internet infrastructure operators to use the longer signatures they will need to protect communications from quantum attacks, while still supporting the speed and space efficiency we’ve come to expect.

For more background information on MTL mode and how it works, see my July 2023 blog post, the MTL mode I-D, or the research paper, “Merkle Tree Ladder Mode: Reducing the Size Impact of NIST PQC Signature Algorithms in Practice.”

Recent Standardization Efforts

In my July 2023 blog post titled “Next Steps in Preparing for Post-Quantum DNSSEC,” I described two recent contributions by Verisign to help the DNS community prepare for a post-quantum world: the MTL mode I-D and a public, royalty-free license to certain intellectual property related to that I-D. These activities set the stage for the latest contributions I’m announcing in this post today.

Our Latest Contributions

• Open source implementation. Like the I-D we published in July of this year, the open source implementation focuses on applying MTL mode to the SPHINCS+ signature scheme currently being standardized in FIPS 205 as SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) by the National Institute of Standards and Technology (NIST). We chose SPHINCS+ because it is the most conservative of NIST’s post-quantum signature algorithms from a cryptographic perspective, being hash-based and stateless. We remain open to adding other post-quantum signature schemes to the I-D and to the open source implementation.
  We encourage developers to try out the open source implementation of MTL mode, which we introduced at the IETF 118 Hackathon, as the community’s experience will help improve the understanding of MTL mode and its applications, and thereby facilitate its standardization. We are interested in feedback both on whether MTL mode is effective in reducing the size impact of post-quantum signatures on DNSSEC and other use cases, and on the open source implementation itself. We are particularly interested in the community’s input on what language bindings would be useful and on which cryptographic libraries we should support initially. The open source implementation can be found on GitHub at: https://github.com/verisign/MTL
• MTL mode for DNSSEC I-D. This specification describes how to use MTL mode signatures with DNSSEC, including DNSKEY and RRSIG record formats. The I-D also provides initial guidance for DNSSEC key creation, signature generation, and signature verification in MTL mode. We consider the I-D as an example of the kinds of contributions that can help to address the “Research Agenda for a Post-Quantum DNSSEC,” the subject of another I-D recently co-authored by Verisign. We expect to continue to update this I-D based on community feedback. While our primary focus is on the DNSSEC use case, we are also open to collaborating on other applications of MTL mode.
• Expanded patent license. Verisign previously announced a public, royalty-free license to certain intellectual property related to the MTL mode I-D that we published in July 2023. With the availability of the open source implementation and the MTL mode for DNSSEC specification, the company has expanded its public license terms to include royalty-free terms for implementing and using MTL mode if the I-D is published as an Experimental, Informational, or Standards Track RFC. In addition, the company has made a similar license grant for the use of MTL mode with DNSSEC. See the MTL mode I-D IPR declaration and the MTL mode for DNSSEC I-D IPR declaration for the official language.

Verisign is grateful for the DNS community’s interest in this area, and we are pleased to serve as stewards of the internet when it comes to developing new technology that can help the internet grow and thrive. Our work on MTL mode is one of the longer-term efforts supporting our mission to enhance the security, stability, and resiliency of the global DNS. We’re encouraged by the progress that has been achieved, and we look forward to further collaborations as we prepare for a post-quantum future.

Footnotes

1. While it’s possible that other post-quantum algorithms could be standardized that don’t have large signatures, they wouldn’t have been studied for as long. Indeed, our preferred approach for long-term resilience of DNSSEC is to use the most conservative of the post-quantum signature algorithms, which also happens to have the largest signatures. By making that choice practical, we’ll have a solution in place whether or not a post-quantum algorithm with a smaller signature size is eventually available. ↩︎

The post Verisign Provides Open Source Implementation of Merkle Tree Ladder Mode appeared first on Verisign Blog.

The Domain Name System (DNS) root zone will soon be getting a new record type, called ZONEMD, to further ensure the security, stability, and resiliency of the global DNS in the face of emerging new approaches to DNS operation. While this change will be unnoticeable for the vast majority of DNS operators (such as registrars, internet service providers, and organizations), it provides a valuable additional layer of cryptographic security to ensure the reliability of root zone data.

In this blog, we’ll discuss these new proposals, as well as ZONEMD. We’ll share deployment plans, how they may affect certain users, and what DNS operators need to be aware of beforehand to ensure little-to-no disruptions.

The Root Server System

The DNS root zone is the starting point for most domain name lookups on the internet. The root zone contains delegations to nearly 1,500 top-level domains, such as .com, .net, .org, and many others. Since its inception in 1984, various organizations known collectively as the Root Server Operators have provided the service for what we now call the Root Server System (RSS). In this system, a myriad of servers respond to approximately 80 billion root zone queries each day.

While the RSS continues to perform this function with a high degree of dependability, there are recent proposals to use the root zone in a slightly different way. These proposals create some efficiencies for DNS operators, but they also introduce new challenges.

New Proposals

In 2020, the Internet Engineering Task Force (IETF) published RFC 8806, titled “Running a Root Server Local to a Resolver.” Along the same lines, in 2021 the Internet Corporation for Assigned Names and Numbers (ICANN) Office of the Chief Technology Officer published OCTO-027, titled “Hyperlocal Root Zone Technical Analysis.” Both proposals share the idea that recursive name servers can receive and load the entire root zone locally and respond to root zone queries directly.

But in a scenario where the entire root zone is made available to millions of recursive name servers, a new question arises: how can consumers of zone data verify that zone content has not been modified before reaching their systems?

One might imagine that DNS Security Extensions (DNSSEC) could help. However, while the root zone is indeed signed with DNSSEC, most of the records in the zone are considered non-authoritative (i.e., all the NS and glue records) and therefore do not have signatures. What about something like a Pretty Good Privacy (PGP) signature on the root zone file? That comes with its own challenge: in PGP, the detached signature is easily separated from the data. For example, there is no way to include a PGP signature over DNS zone transfer, and there is no easy way to know which version of the zone goes with the signature.

Introducing ZONEMD

A solution to this problem comes from RFC 8976. Led by Verisign and titled “Message Digest for DNS Zones” (known colloquially as ZONEMD), this protocol calls for a cryptographic digest of the zone data to be embedded into the zone itself. This ZONEMD record can then be signed and verified by consumers of the zone data. Here’s how it works:

Each time a zone is updated, the publisher calculates the ZONEMD record by sorting and canonicalizing all the records in the zone and providing them as input to a message digest function. Sorting and canonicalization are the same as for DNSSEC. In fact, the ZONEMD calculation can be performed at the same time the zone is signed. Digest calculation necessarily excludes the ZONEMD record itself, so the final step is to update the ZONEMD record and its signatures.

A recipient of a zone that includes a ZONEMD record repeats the same calculation and compares its calculated digest value with the published digest. If the zone is signed, then the recipient can also validate the correctness of the published digest. In this way, recipients can verify the authenticity of zone data before using it.

A number of open-source DNS software products now, or soon will, include support for ZONEMD verification. These include Unbound (version 1.13.2), NSD (version 4.3.4), Knot DNS (version 3.1.0), PowerDNS Recursor (version 4.7.0) and BIND (version 9.19).

Who Is Affected?

Verisign, ICANN, and the Root Server Operators are taking steps to ensure that the addition of the ZONEMD record in no way impacts the ability of the root server system to receive zone updates and to respond to queries. As a result, most internet users are not affected by this change.

Anyone using RFC 8806, or a similar technique to load root zone data into their local resolver, is unlikely to be affected as well. Software products that implement those features should be able to fully process a zone that includes the new record type, especially for reasons described below. Once the record has been added, users can take advantage of ZONEMD verification to ensure root zone data is authentic.

Users most likely to be affected are those that receive root zone data from the internic.net servers (or some other source) and use custom software to parse the zone file. Depending on how such custom software is designed, there is a possibility that it will treat the new ZONEMD record as unexpected and lead to an error condition. Key objectives of this blog post are to raise awareness of this change, provide ample time to address software issues, and minimize the likelihood of disruptions for such users.

Deployment Plan

In 2020, Verisign asked the Root Zone Evolution Review Committee (RZERC) to consider a proposal for adding data protections to the root zone using ZONEMD. In 2021, the RZERC published its recommendations in RZERC003. One of those recommendations was for Verisign and ICANN to develop a deployment plan and make the community aware of the plan’s details. That plan is summarized in the remainder of this blog post.

Phased Rollout

One attribute of a ZONEMD record is the choice of a hash algorithm used to create the digest. RFC 8976 defines two standard hash algorithms – SHA-384 and SHA-512 – and a range of “private-use” algorithms.

Initially, the root zone’s ZONEMD record will have a private-use hash algorithm. This allows us to first include the record in the zone without anyone worrying about the validity of the digest values. Since the hash algorithm is from the private-use range, a consumer of the zone data will not know how to calculate the digest value. A similar technique, known as the “Deliberately Unvalidatable Root Zone,” was utilized when DNSSEC was added to the root zone in 2010.

After a period of more than two months, the ZONEMD record will transition to a standard hash algorithm.

Hash Algorithm

SHA-384 has been selected for the initial implementation for compatibility reasons.

The developers of BIND implemented the ZONEMD protocol based on an early Internet-Draft, some time before it was published as an RFC. Unfortunately, the initial BIND implementation only accepts ZONEMD records with a digest length of 48 bytes (i.e., the SHA-384 length). Since the versions of BIND with this behavior are in widespread use today, use of the SHA-512 hash algorithm would likely lead to problems for many BIND installations, possibly including some Root Server Operators.

Presentation Format

Distribution of the zone between the Root Zone Maintainer and Root Server Operators primarily takes place via the DNS zone transfer protocol. In this protocol, zone data is transmitted in “wire format.”

The root zone is also stored and served as a file on the internic.net FTP and web servers. Here, the zone data is in “presentation format.” The ZONEMD record will appear in these files using its native presentation format. For example:

. 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )

Some users of zone data received from the FTP and web servers might currently be using software that does not recognize the ZONEMD presentation format. These users might experience some problems when the ZONEMD record first appears. We did consider using a generic record format; however, in consultation with ICANN, we believe that the native format is a better long-term solution.

Schedule

Currently, we are targeting the initial deployment of ZONEMD in the root zone for September 13, 2023. As previously stated, the ZONEMD record will be published first with a private-use hash algorithm number. We are targeting December 6, 2023, as the date to begin using the SHA-384 hash algorithm, at which point the root zone ZONEMD record will become verifiable.

Conclusion

Deploying ZONEMD in the root zone helps to increase the security, stability, and resiliency of the DNS. Soon, recursive name servers that choose to serve root zone data locally will have stronger assurances as to the zone’s validity.

If you’re interested in following the ZONEMD deployment progress, please look for our announcements on the DNS Operations mailing list.

The post Adding ZONEMD Protections to the Root Zone appeared first on Verisign Blog.

This is the final in a multi-part series on cryptography and the Domain Name System (DNS).

In previous posts in this series, I’ve discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC).

In this final blog post, I’ll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I’ve also written about DNS encryption as well as minimization in a separate post on DNS information protection.)

DNS Encryption

In 2014, the Internet Engineering Task Force (IETF) chartered the DNS PRIVate Exchange (dprive) working group to start work on encrypting DNS queries and responses exchanged between clients and resolvers.

That work resulted in RFC 7858, published in 2016, which describes how to run the DNS protocol over the Transport Layer Security (TLS) protocol, also known as DNS over TLS, or DoT.

DNS encryption between clients and resolvers has since gained further momentum, with multiple browsers and resolvers supporting DNS over Hypertext Transport Protocol Security (HTTPS), or DoH, with the formation of the Encrypted DNS Deployment Initiative, and with further enhancements such as oblivious DoH.

The dprive working group turned its attention to the resolver-to-authoritative exchange during its rechartering in 2018. And in October of last year, ICANN’s Office of the CTO published its strategy recommendations for the ICANN-managed Root Server (IMRS, i.e., the L-Root Server), an effort motivated in part by concern about potential “confidentiality attacks” on the resolver-to-root connection.

From a cryptographer’s perspective the prospect of adding encryption to the DNS protocol is naturally quite interesting. But this perspective isn’t the only one that matters, as I’ve observed numerous times in previous posts.

Balancing Cryptographic and Operational Considerations

A common theme in this series on cryptography and the DNS has been the question of whether the benefits of a technology are sufficient to justify its cost and complexity.

This question came up not only in my review of two newer cryptographic advances, but also in my remarks on the motivation for two established tools for providing evidence that a domain name doesn’t exist.

Recall that the two tools — the Next Secure (NSEC) and Next Secure 3 (NSEC3) records — were developed because a simpler approach didn’t have an acceptable risk / benefit tradeoff. In the simpler approach, to provide a relying party assurance that a domain name doesn’t exist, a name server would return a response, signed with its private key, “<name> doesn’t exist.”

From a cryptographic perspective, the simpler approach would meet its goal: a relying party could then validate the response with the corresponding public key. However, the approach would introduce new operational risks, because the name server would now have to perform online cryptographic operations.

The name server would not only have to protect its private key from compromise, but would also have to protect the cryptographic operations from overuse by attackers. That could open another avenue for denial-of-service attacks that could prevent the name server from responding to legitimate requests.

The designers of DNSSEC mitigated these operational risks by developing NSEC and NSEC3, which gave the option of moving the private key and the cryptographic operations offline, into the name server’s provisioning system. Cryptography and operations were balanced by this better solution. The theme is now returning to view through the recent efforts around DNS encryption.

Like the simpler initial approach for authentication, DNS encryption may meet its goal from a cryptographic perspective. But the operational perspective is important as well. As designers again consider where and how to deploy private keys and cryptographic operations across the DNS ecosystem, alternatives with a better balance are a desirable goal.

Minimization Techniques

In addition to encryption, there has been research into other, possibly lower-risk alternatives that can be used in place of or in addition to encryption at various levels of the DNS.

We call these techniques collectively minimization techniques.

Qname Minimization

In “textbook” DNS resolution, a resolver sends the same full domain name to a root server, a top-level domain (TLD) server, a second-level domain (SLD) server, and any other server in the chain of referrals, until it ultimately receives an authoritative answer to a DNS query.

This is the way that DNS resolution has been practiced for decades, and it’s also one of the reasons for the recent interest in protecting information on the resolver-to-authoritative exchange: The full domain name is more information than all but the last name server needs to know.

One such minimization technique, known as qname minimization, was identified by Verisign researchers in 2011 and documented in RFC 7816 in 2016. (In 2015, Verisign announced a royalty-free license to its qname minimization patents.)

With qname minimization, instead of sending the full domain name to each name server, the resolver sends only as much as the name server needs either to answer the query or to refer the resolver to a name server at the next level. This follows the principle of minimum disclosure: the resolver sends only as much information as the name server needs to “do its job.” As Matt Thomas described in his recent blog post on the topic, nearly half of all .com and .net queries received by Verisign’s .com TLD servers were in a minimized form as of August 2020.

Additional Minimization Techniques

Other techniques that are part of this new chapter in DNS protocol evolution include NXDOMAIN cut processing [RFC 8020] and aggressive DNSSEC caching [RFC 8198]. Both leverage information present in the DNS to reduce the amount and sensitivity of DNS information exchanged with authoritative name servers. In aggressive DNSSEC caching, for example, the resolver analyzes NSEC and NSEC3 range proofs obtained in response to previous queries to determine on its own whether a domain name doesn’t exist. This means that the resolver doesn’t always have to ask the authoritative server system about a domain name it hasn’t seen before.

All of these techniques, as well as additional minimization alternatives I haven’t mentioned, have one important common characteristic: they only change how the resolver operates during the resolver-authoritative exchange. They have no impact on the authoritative name server or on other parties during the exchange itself. They thereby mitigate disclosure risk while also minimizing operational risk.

The resolver’s exchanges with authoritative name servers, prior to minimization, were already relatively less sensitive because they represented aggregate interests of the resolver’s many clients¹. Minimization techniques lower the sensitivity even further at the root and TLD levels: the resolver sends only its aggregate interests in TLDs to root servers, and only its interests in SLDs to TLD servers. The resolver still sends the aggregate interests in full domain names at the SLD level and below², and may also include certain client-related information at these levels, such as the client-subnet extension. The lower levels therefore may have different protection objectives than the upper levels.

Conclusion

Minimization techniques and encryption together give DNS designers additional tools for protecting DNS information — tools that when deployed carefully can balance between cryptographic and operational perspectives.

These tools complement those I’ve described in previous posts in this series. Some have already been deployed at scale, such as a DNSSEC with its NSEC and NSEC3 non-existence proofs. Others are at various earlier stages, like NSEC5 and tokenized queries, and still others contemplate “post-quantum” scenarios and how to address them. (And there are yet other tools that I haven’t covered in this series, such as authenticated resolution and adaptive resolution.)

Modern cryptography is just about as old as the DNS. Both have matured since their introduction in the late 1970s and early 1980s respectively. Both bring fundamental capabilities to our connected world. Both continue to evolve to support new applications and to meet new security objectives. While they’ve often moved forward separately, as this blog series has shown, there are also opportunities for them to advance together. I look forward to sharing more insights from Verisign’s research in future blog posts.

Read the complete six blog series:

1. The Domain Name System: A Cryptographer’s Perspective
2. Cryptographic Tools for Non-Existence in the Domain Name System: NSEC and NSEC3
3. Newer Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries
4. Securing the DNS in a Post-Quantum World: New DNSSEC Algorithms on the Horizon
5. Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys
6. Information Protection for the Domain Name System: Encryption and Minimization

---

^{1. This argument obviously holds more weight for large resolvers than for small ones — and doesn’t apply for the less common case of individual clients running their own resolvers. However, small resolvers and individual clients seeking additional protection retain the option of sending sensitive queries through a large, trusted resolver, or through a privacy-enhancing proxy. The focus in our discussion is primarily on large resolvers.}

^{2. In namespaces where domain names are registered at the SLD level, i.e., under an effective TLD, the statements in this note about “root and TLD” and “SLD level and below” should be “root through effective TLD” and “below effective TLD level.” For simplicity, I’ve placed the “zone cut” between TLD and SLD in this note.}

Minimization et al. techniques and encryption together give DNS designers additional tools for protecting DNS information — tools that when deployed carefully can balance between cryptographic and operational perspectives.

The post Information Protection for the Domain Name System: Encryption and Minimization appeared first on Verisign Blog.

This is the fifth in a multi-part series on cryptography and the Domain Name System (DNS).

In my last article, I described efforts underway to standardize new cryptographic algorithms that are designed to be less vulnerable to potential future advances in quantum computing. I also reviewed operational challenges to be considered when adding new algorithms to the DNS Security Extensions (DNSSEC).

In this post, I’ll look at hash-based signatures, a family of post-quantum algorithms that could be a good match for DNSSEC from the perspective of infrastructure stability.

I’ll also describe Verisign Labs research into a new concept called synthesized zone signing keys that could mitigate the impact of the large signature size for hash-based signatures, while still maintaining this family’s protections against quantum computing.

(Caveat: The concepts reviewed in this post are part of Verisign’s long-term research program and do not necessarily represent Verisign’s plans or positions on new products or services. Concepts developed in our research program may be subject to U.S. and/or international patents and/or patent applications.)

A Stable Algorithm Rollover

The DNS community’s root key signing key (KSK) rollover illustrates how complicated a change to DNSSEC infrastructure can be. Although successfully accomplished, this change was delayed by ICANN to ensure that enough resolvers had the public key required to validate signatures generated with the new root KSK private key.

Now imagine the complications if the DNS community also had to ensure that enough resolvers not only had a new key but also had a brand-new algorithm.

Imagine further what might happen if a weakness in this new algorithm were to be found after it was deployed. While there are procedures for emergency key rollovers, emergency algorithm rollovers would be more complicated, and perhaps controversial as well if a clear successor algorithm were not available.

I’m not suggesting that any of the post-quantum algorithms that might be standardized by NIST will be found to have a weakness. But confidence in cryptographic algorithms can be gained and lost over many years, sometimes decades.

From the perspective of infrastructure stability, therefore, it may make sense for DNSSEC to have a backup post-quantum algorithm built in from the start — one for which cryptographers already have significant confidence and experience. This algorithm might not be as efficient as other candidates, but there is less of a chance that it would ever need to be changed. This means that the more efficient candidates could be deployed in DNSSEC with the confidence that they have a stable fallback. It’s also important to keep in mind that the prospect of quantum computing is not the only reason system developers need to be considering new algorithms from time to time. As public-key cryptography pioneer Martin Hellman wisely cautioned, new classical (non-quantum) attacks could also emerge, whether or not a quantum computer is realized.

Hash-Based Signatures

The 1970s were a foundational time for public-key cryptography, producing not only the RSA algorithm and the Diffie-Hellman algorithm (which also provided the basic model for elliptic curve cryptography), but also hash-based signatures, invented in 1979 by another public-key cryptography founder, Ralph Merkle.

Hash-based signatures are interesting because their security depends only on the security of an underlying hash function.

It turns out that hash functions, as a concept, hold up very well against quantum computing advances — much better than currently established public-key algorithms do.

This means that Merkle’s hash-based signatures, now more than 40 years old, can rightly be considered the oldest post-quantum digital signature algorithm.

If it turns out that an individual hash function doesn’t hold up — whether against a quantum computer or a classical computer — then the hash function itself can be replaced, as cryptographers have been doing for years. That will likely be easier than changing to an entirely different post-quantum algorithm, especially one that involves very different concepts.

The conceptual stability of hash-based signatures is a reason that interoperable specifications are already being developed for variants of Merkle’s original algorithm. Two approaches are described in RFC 8391, “XMSS: eXtended Merkle Signature Scheme” and RFC 8554, “Leighton-Micali Hash-Based Signatures.” Another approach, SPHINCS+, is an alternate in NIST’s post-quantum project.

Hash-based signatures can potentially be applied to any part of the DNSSEC trust chain. For example, in Figure 1, the DNS record sets can be signed with a zone signing key (ZSK) that employs a hash-based signature algorithm.

The main challenge with hash-based signatures is that the signature size is large, on the order of tens or even hundreds of thousands of bits. This is perhaps why they haven’t seen significant adoption in security protocols over the past four decades.

Synthesizing ZSKs with Merkle Trees

Verisign Labs has been exploring how to mitigate the size impact of hash-based signatures on DNSSEC, while still basing security on hash functions only in the interest of stable post-quantum protections.

One of the ideas we’ve come up with uses another of Merkle’s foundational contributions: Merkle trees.

Merkle trees authenticate multiple records by hashing them together in a tree structure. The records are the “leaves” of the tree. Pairs of leaves are hashed together to form a branch, then pairs of branches are hashed together to form a larger branch, and so on. The hash of the largest branches is the tree’s “root.” (This is a data-structure root, unrelated to the DNS root.)

Each individual leaf of a Merkle tree can be authenticated by retracing the “path” from the leaf to the root. The path consists of the hashes of each of the adjacent branches encountered along the way.

Authentication paths can be much shorter than typical hash-based signatures. For instance, with a tree depth of 20 and a 256-bit hash value, the authentication path for a leaf would only be 5,120 bits long, yet a single tree could authenticate more than a million leaves.

Returning to the example above, suppose that instead of signing each DNS record set with a hash-based signature, each record set were considered a leaf of a Merkle tree. Suppose further that the root of this tree were to be published as the ZSK public key (see Figure 2). The authentication path to the leaf could then serve as the record set’s signature.

The validation logic at a resolver would be the same as in ordinary DNSSEC:

• The resolver would obtain the ZSK public key from a DNSKEY record set signed by the KSK.
• The resolver would then validate the signature on the record set of interest with the ZSK public key.

The only difference on the resolver’s side would be that signature validation would involve retracing the authentication path to the ZSK public key, rather than a conventional signature validation operation.

The ZSK public key produced by the Merkle tree approach would be a “synthesized” public key, in that it is obtained from the records being signed. This is noteworthy from a cryptographer’s perspective, because the public key wouldn’t have a corresponding private key, yet the DNS records would still, in effect, be “signed by the ZSK!”

Additional Design Considerations

In this type of DNSSEC implementation, the Merkle tree approach only applies to the ZSK level. Hash-based signatures would still be applied at the KSK level, although their overhead would now be “amortized” across all records in the zone.

In addition, each new ZSK would need to be signed “on demand,” rather than in advance, as in current operational practice.

This leads to tradeoffs, such as how many changes to accumulate before constructing and publishing a new tree. Fewer changes and the tree will be available sooner. More changes and the tree will be larger, so the per-record overhead of the signatures at the KSK level will be lower.

Conclusion

My last few posts have discussed cryptographic techniques that could potentially be applied to the DNS in the long term — or that might not even be applied at all. In my next post, I’ll return to more conventional subjects, and explain how Verisign sees cryptography fitting into the DNS today, as well as some important non-cryptographic techniques that are part of our vision for a secure, stable and resilient DNS.

Read the complete six blog series:

1. The Domain Name System: A Cryptographer’s Perspective
2. Cryptographic Tools for Non-Existence in the Domain Name System: NSEC and NSEC3
3. Newer Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries
4. Securing the DNS in a Post-Quantum World: New DNSSEC Algorithms on the Horizon
5. Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys
6. Information Protection for the Domain Name System: Encryption and Minimization

Research into concepts such as hash-based signatures and synthesized zone signing keys indicates that these techniques have the potential to keep the Domain Name System (DNS) secure for the long term if added into the Domain Name System Security Extensions (DNSSEC).

The post Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys appeared first on Verisign Blog.

This is the third in a multi-part blog series on cryptography and the Domain Name System (DNS).

In my last post, I looked at what happens when a DNS query renders a “negative” response – i.e., when a domain name doesn’t exist. I then examined two cryptographic approaches to handling negative responses: NSEC and NSEC3. In this post, I will examine a third approach, NSEC5, and a related concept that protects client information, tokenized queries.

The concepts I discuss below are topics we’ve studied in our long-term research program as we evaluate new technologies. They do not necessarily represent Verisign’s plans or position on a new product or service. Concepts developed in our research program may be subject to U.S. and international patents and patent applications.

NSEC5

NSEC5 is a result of research by cryptographers at Boston University and the Weizmann Institute. In this approach, which is still in an experimental stage, the endpoints are the outputs of a verifiable random function (VRF), a cryptographic primitive that has been gaining interest in recent years. NSEC5 is documented in an Internet Draft (currently expired) and in several research papers.

A VRF is like a hash function but with two important differences:

1. In addition to a message input, a VRF has a second input, a private key. (As in public-key cryptography, there’s also a corresponding public key.) No one can compute the outputs without the private key, hence the “random.”
2. A VRF has two outputs: a token and a proof. (I’ve adopted the term “token” for alignment with the research that I describe next. NSEC5 itself simply uses “hash.”) Anyone can check that the token is correct given the proof and the public key, hence the “verifiable.”

So, it’s not only hard for an adversary to reverse the VRF – which is also a property the hash function has – but it’s also hard for the adversary to compute the VRF in the forward direction, thus preventing dictionary attacks. And yet a relying party can still confirm that the VRF output for a given input is correct, because of the proof.

How does this work in practice? As in NSEC and NSEC3, range statements are prepared in advance and signed with the zone signing key (ZSK). With NSEC5, however, the range endpoints are two consecutive tokens.

When a domain name doesn’t exist, the name server applies the VRF to the domain name to obtain a token and a proof. The name sever then returns a range statement where the token falls within the range, as well as the proof, as shown in the figure below. Note that the token values are for illustration only.

Because the range statement reveals only tokenized versions of other domain names in a zone, an adversary who doesn’t know the private key doesn’t learn any new existing domain names from the response. Indeed, to find out which domain name corresponds to one of the tokenized endpoints, the adversary would need access to the VRF itself to see if a candidate domain name has a matching hash value, which would involve an online dictionary attack. This significantly reduces disclosure risk.

The name server needs a copy of the zone’s NSEC5 private key so that it can generate proofs for non-existent domain names. The ZSK itself can stay in the provisioning system. As the designers of NSEC5 have pointed out, if the NSEC5 private key does happen to be compromised, this only makes it possible to do a dictionary attack offline— not to generate signatures on new range statements, or on new positive responses.

NSEC5 is interesting from a cryptographer’s perspective because it uses a less common cryptographic technique, a VRF, to achieve a design goal that was at best partially met by previous approaches. As with other new technologies, DNS operators will need to consider whether NSEC5’s benefits are sufficient to justify its cost and complexity. Verisign doesn’t have any plans to implement NSEC5, as we consider NSEC and NSEC3 adequate for the name servers we currently operate. However, we will continue to track NSEC5 and related developments as part of our long-term research program.

Tokenized Queries

A few years before NSEC5 was published, Verisign Labs had started some research on an opposite application of tokenization to the DNS, to protect a client’s information from disclosure.

In our approach, instead of asking the resolver “What is <name>’s IP address,” the client would ask “What is token 3141…’s IP address,” where 3141… is the tokenization of <name>.

(More precisely, the client would specify both the token and the parent zone that the token relates to, e.g., the TLD of the domain name. Only the portion of the domain name below the parent would be obscured, just as in NSEC5. I’ve omitted the zone information for simplicity in this discussion.)

Suppose now that the domain name corresponding to token 3141… does exist. Then the resolver would respond with the domain name’s IP address as usual, as shown in the next figure.

In this case, the resolver would know that the domain name associated with the token does exist, because it would have a mapping between the token and the DNS record, i.e., the IP address. Thus, the resolver would effectively “know” the domain name as well for practical purposes. (We’ve developed another approach that can protect both the domain name and the DNS record from disclosure to the resolver in this case, but that’s perhaps a topic for another post.)

Now, consider a domain name that doesn’t exist and suppose that its token is 2718… .

In this case, the resolver would respond that the domain name doesn’t exist, as usual, as shown below.

But because the domain name is tokenized and no other information about the domain name is returned, the resolver would only learn the token 2718… (and the parent zone), not the actual domain name that the client is interested in.

The resolver could potentially know that the name doesn’t exist via a range statement from the parent zone, as in NSEC5.

How does the client tokenize the domain name, if it doesn’t have the private key for the VRF? The name server would offer a public interface to the tokenization function. This can be done in what cryptographers call an “oblivious” VRF protocol, where the name server doesn’t see the actual domain name during the protocol, yet the client still gets the token.

To keep the resolver itself from using this interface to do an online dictionary attack that matches candidate domain names with tokens, the name server could rate-limit access, or restrict it only to authorized requesters.

Additional details on this technology may be found in U.S. Patent 9,202,079B2, entitled “Privacy preserving data querying,” and related patents.

It’s interesting from a cryptographer’s perspective that there’s a way for a client to find out whether a DNS record exists, without necessarily revealing the domain name of interest. However, as before, the benefits of this new technology will be weighed against its operational cost and complexity and compared to other approaches. Because this technique focuses on client-to-resolver interactions, it’s already one step removed from the name servers that Verisign currently operates, so it is not as relevant to our business today in a way it might have been when we started the research. This one will stay under our long-term tracking as well.

Conclusion

The examples I’ve shared in these last two blog posts make it clear that cryptography has the potential to bring interesting new capabilities to the DNS. While the particular examples I’ve shared here do not meet the criteria for our product roadmap, researching advances in cryptography and other techniques remains important because new events can sometimes change the calculus. That point will become even more evident in my next post, where I’ll consider the kinds of cryptography that may be needed in the event that one or more of today’s algorithms is compromised, possibly through the introduction of a quantum computer.

Read the complete six blog series:

1. The Domain Name System: A Cryptographer’s Perspective
2. Cryptographic Tools for Non-Existence in the Domain Name System: NSEC and NSEC3
3. Newer Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries
4. Securing the DNS in a Post-Quantum World: New DNSSEC Algorithms on the Horizon
5. Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys
6. Information Protection for the Domain Name System: Encryption and Minimization

The post Newer Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries appeared first on Verisign Blog.