DEV Community: SAAZone Studio

Why Reusing the Same Username Everywhere Is a Privacy Risk

SAAZone Studio — Tue, 22 Sep 2026 10:15:21 +0000

Why Reusing the Same Username Everywhere Is a Privacy Risk

You've probably had the same username for years.

Your gaming account.
Your Reddit account.
Your Steam profile.
An old forum account you forgot existed.

Same username everywhere.

It's convenient. It's easy to remember.

But there's a privacy problem with that convenience:

A unique username can become a link between your different online identities.

Someone doesn't necessarily need to hack anything to discover that two accounts belong to the same person.

Sometimes, they just need to search for the same username.

The account-linking problem

Imagine you use silentfox everywhere.

Someone finds your old forum account.

They search silentfox.

They find a gaming profile.

Then a Reddit account.

Then a GitHub profile.

One account mentions a city.

Another contains an old photo.

Another lists a programming project.

None of those pieces of information had to be secret individually.

But once the accounts are linked together, they can reveal much more than each account revealed by itself.

Researchers have studied exactly this problem: whether the same username can be used to identify and link a person across different online communities. Studies have found that username similarity or reuse can make cross-platform profile linking possible.

That's the important distinction:

The username itself may not contain personal information, but its reuse can create a connection between pieces of personal information.

NIST makes a similar distinction in its digital identity guidance: a username can be personally identifiable information when it links back to a specific person, while an arbitrary or opaque identifier may not be.

It's not the same as getting hacked

This is worth clarifying.

If someone finds the same username on five websites, they haven't necessarily compromised any of your accounts.

They may simply have discovered that the accounts are probably connected.

That's a privacy and identity-correlation problem, not automatically an account takeover.

The distinction matters because there are actually two different risks people often mix together.

Username reuse

The same username can make it easier to correlate profiles across websites.

An attacker might use public information from multiple accounts to build a more complete picture of someone's online activity.

Credential reuse

This is more directly related to account compromise.

If you reuse the same username/email and password across websites, a breach at one service can provide credentials that attackers may try elsewhere.

This is known as credential stuffing.

OWASP specifically identifies reuse of usernames and passwords as a factor that can make credential-stuffing attacks effective.

So:

Username reuse can hurt privacy.

Password reuse can hurt account security.

Using both together can create both problems at once.

Why a username can reveal more than you think

Let's say someone discovers your username on an old forum.

The username itself might tell them almost nothing.

But they search for that same username on other services.

Now they find:

Forum
  ↓
Gaming profile
  ↓
Reddit account
  ↓
GitHub profile
  ↓
Personal website

Each profile contributes another piece of information.

Maybe one has your interests.

Another has your approximate location.

Another has your programming projects.

Another has a photo.

Another contains an old post that mentions your school or workplace.

The individual pieces may seem harmless.

The connection between them is what creates the bigger privacy issue.

This is why pseudonyms work best when they actually separate identities.

A different username alone isn't a perfect privacy solution, of course. Writing style, profile photos, email addresses, links, usernames that are only slightly modified, and other clues can still connect accounts.

But removing an obvious common identifier is one useful step.

What I built

While working on EvoTechTool, I wanted to make a simple tool for exactly this use case.

So I built a username generator that creates new, memorable usernames without requiring a server.

The core idea is simple:

const adjectives = [
  'silent',
  'swift',
  'quiet',
  'brave'
];

const nouns = [
  'fox',
  'raven',
  'wolf',
  'cedar'
];

function generate(pattern) {
  const adj = adjectives[randomInt(adjectives.length)];
  const noun = nouns[randomInt(nouns.length)];
  const num = randomInt(9999);

  switch (pattern) {
    case 'adj-noun':
      return `${adj}${noun}`;

    case 'adj-noun-num':
      return `${adj}${noun}${num}`;

    default:
      return `${adj}-${noun}`;
  }
}

The actual implementation uses larger word lists, but the basic concept is the same.

Instead of asking a server to generate a username, the browser selects words locally.

The generator supports multiple patterns

The tool currently supports patterns such as:

Adjective + noun → silentfox
Adjective + noun + number → silentfox42
Verb + noun → chasefox
Verb + adjective + noun → chasequietfox
Noun + noun → foxcedar
Adjective + adjective + noun → silentbravefox

You can also customize things like separators and capitalization.

The goal isn't to generate completely random strings like:

x7Qp9L2mK8

Those are great for passwords.

They're not particularly memorable as usernames.

Instead, the generator combines words so the result is easier to recognize and remember while still giving you many possible combinations.

Why generate usernames locally?

There's a privacy benefit to keeping the generation local.

The generator doesn't need to send your generated usernames to a server.

The browser can select the words, construct the username, and display the result entirely on the client.

That means there's no username-generation database collecting the usernames you've generated.

And you can verify the behavior yourself.

Open DevTools.

Go to the Network tab.

Generate a few usernames.

The generation itself doesn't require a request to a username-generation API.

That's the same design principle I used for the password generator: if a tool doesn't need a server to perform its core function, why add one?

But don't overdo anonymity

There's an important balance here.

I don't think everyone should have a completely different identity on every website.

If you're building a professional identity, consistency can be useful.

For example, you may deliberately want the same username on:

GitHub
Your portfolio
LinkedIn
Your developer blog

In that situation, being discoverable is part of the goal.

The problem is using that same identity everywhere, including places where you don't necessarily want your professional or personal profiles connected.

That's where separating identities becomes useful.

A simple system for usernames

You don't need 50 completely random identities.

You can divide your online accounts into a few categories.

Public / professional

Use a consistent username.

Examples:

GitHub
Portfolio
Developer communities
Professional social accounts

The goal here is discoverability.

Personal

Use a separate identity.

Examples:

Personal forums
Gaming
Hobby communities

The goal is to participate without automatically connecting everything to your professional identity.

Temporary / low-trust

Use another generated username.

Examples:

Forums you don't plan to use long-term
Sites where you don't want your normal username exposed
Temporary communities

The goal is simply to avoid unnecessarily connecting the account to your other identities.

Don't just change one character

This is a surprisingly common mistake.

If your normal username is:

silentfox

changing it to:

silentfox2

doesn't accomplish much.

Neither does:

silent_fox

or:

silentfox123

If someone is specifically looking for connections between your accounts, obvious variations can be easy to associate.

A genuinely different username creates a much stronger separation than changing a number at the end.

A username isn't a security credential

There's another important distinction.

A username generally isn't a secret.

Your password is.

So changing your username does not replace basic account security.

You should still:

Use a unique password for every account
Use a password manager
Enable MFA where available
Consider passkeys when supported
Avoid using personal information in usernames when privacy matters

NIST currently recommends measures such as MFA, passkeys, and password managers as important ways to protect online accounts.

Username separation is about privacy and correlation, not about replacing authentication security.

Try it

I built the username generator as part of EvoTechTool, a collection of browser-based tools focused on being free, private, and requiring no signup.

Username Generator:

https://evotechtool.pages.dev/username-generator.html

Everything needed to generate the username runs in your browser.

No account.

No username-generation server.

No database of the usernames you generate.

The idea behind the tool is pretty simple:

Sometimes the easiest way to protect the connection between two identities is not to create the connection in the first place.

If you're interested in online privacy, try searching one of your old usernames across the websites you used years ago.

You might be surprised by how many pieces of your online history are still connected by the same name.

Do you use the same username everywhere, or do you separate your online identities?

I Built a Password Generator That Never Sends Your Password to a Server

SAAZone Studio — Tue, 22 Sep 2026 09:36:03 +0000

A password generator looks like a very simple tool.

Choose a length.
Select some character types.
Click Generate.

Done.

But while building my own password generator, I started thinking about a more important question:

Where does the password actually get generated?

If a password is generated on a server, the generated value has to reach that server and then be returned to your browser. TLS can protect the connection while the data is in transit, but the server itself still has access to the generated password.

That creates an additional trust requirement.

So when I built the password generator for EvoTechTool, I decided not to have a server generate the password at all.

The generation happens entirely inside the browser.

No password-generation API.
No backend request.
No account required.

And it can still generate passwords when you're offline.

Here's how I built it.

First problem: `Math.random()`

JavaScript gives us Math.random().

It's convenient, and it's perfectly useful for many things: animations, games, randomized UI elements, and other situations where cryptographic security isn't required.

But password generation is different.

Math.random() is not designed to provide cryptographically secure random values.

For security-sensitive randomness, browsers provide the Web Crypto API:

crypto.getRandomValues()

MDN describes crypto.getRandomValues() as providing cryptographically strong random values. The implementation uses a pseudorandom generator seeded with sufficient entropy rather than relying on a "truly random" process for every value.

That's exactly the kind of randomness I wanted for this project.

A simple example looks like this:

const values = new Uint32Array(10);
crypto.getRandomValues(values);

console.log(values);

The browser fills the array with cryptographically strong random values.

But there's another problem.

The modulo bias problem

A straightforward implementation might do this:

const index = randomValue % charset.length;

It looks perfectly reasonable.

But there's a subtle statistical problem.

If the number of possible random values isn't evenly divisible by the size of the character set, some characters can be selected slightly more often than others.

That's called modulo bias.

The difference can be tiny, but when you're deliberately building a security-focused tool, I don't see much reason to introduce a bias when it can be avoided.

So I used rejection sampling.

The basic idea is simple:

Generate a cryptographically secure random value.
Calculate the largest range that can be divided evenly by the character-set size.
Reject values outside that range.
Use modulo only on the remaining values.

For example:

function randomIndex(max) {
  const maxUint32 = 0x100000000;
  const limit = Math.floor(maxUint32 / max) * max;

  const array = new Uint32Array(1);

  let value;

  do {
    crypto.getRandomValues(array);
    value = array[0];
  } while (value >= limit);

  return value % max;
}

Now the generated index is selected without the modulo bias.

The performance difference is negligible for the small number of random values needed to generate a normal password.

The actual password generation

With that in place, generating the password becomes fairly straightforward:

function generatePassword(length, charset) {
  let password = '';

  for (let i = 0; i < length; i++) {
    const index = randomIndex(charset.length);
    password += charset[index];
  }

  return password;
}

The important part isn't the loop.

It's where the randomness comes from.

Instead of:

Math.random()

the generator uses:

crypto.getRandomValues()

And instead of asking a server to generate the password, everything happens locally.

Why client-side generation?

There are a few reasons I prefer this architecture for a password generator.

1. No password-generation request

The browser doesn't need to send the generated password to an API.

The password is created locally.

2. Less trust required

A server-side generator means you have to trust the service handling the generated password.

A local generator removes the password-generation server from the architecture entirely.

That's not a guarantee that the entire website is magically secure — browsers, extensions, devices, malware, screenshots, clipboard access, and other parts of the environment still matter.

But it does remove one unnecessary place where the generated password could be exposed.

3. You can inspect it yourself

This is something I really like about client-side tools.

Open DevTools and go to the Network tab.

Generate a password.

You can inspect what the page is doing instead of simply trusting a statement like "your password never leaves your browser."

For a genuinely local implementation, generating a password doesn't require a request to a password-generation API.

What I put into the tool

The password generator in EvoTechTool currently supports:

Passwords up to 128 characters
Uppercase letters
Lowercase letters
Numbers
Symbols
Excluding ambiguous characters such as l, I, 1, O, and 0
Password strength information
Entropy calculation
Offline generation

The interface is intentionally simple.

I didn't want the security-related part of the tool buried under unnecessary features.

What about password strength?

This part is interesting because a password can look complicated without actually being very random.

For a uniformly random password, a simplified entropy calculation is:

entropy = length × log₂(character_set_size)

For example, increasing the password length increases the possible number of combinations exponentially.

But entropy calculations have an important limitation:

They describe the randomness of the generation process, not a guarantee about how long a real attacker will take to crack the password.

The actual difficulty of cracking a password depends on things such as the attack model, hashing algorithm, rate limiting, hardware, and whether the password was actually generated uniformly.

So I treat the crack-time figure in the tool as an estimate rather than a promise.

Random passwords vs. human-created passwords

This is also why I prefer generated passwords for accounts where I don't need to memorize the password.

Humans are surprisingly predictable when creating passwords.

We tend to use:

familiar words
names
dates
patterns
substitutions like @ for a
predictable capitalization
repeated structures

A randomly generated password doesn't have those human patterns.

NIST's current Digital Identity Guidelines allow passwords to be randomly assigned and emphasize the value of password managers and randomly generated unique passwords.

NIST also notes that password managers can help users create unique, long, complex passwords for different accounts.

So you don't need to memorize a different random password for every website.

Let the password manager handle that part.

One important distinction

There's a difference between password generation and password storage.

This article is about generating passwords.

If you're building an application that stores users' passwords, that's a completely different problem.

You should never store users' passwords as plaintext. Modern password-storage guidance recommends appropriate password hashing algorithms such as Argon2id, bcrypt, or PBKDF2 rather than reversible encryption or plaintext storage.

In other words:

Generating a password securely and storing a password securely are two different engineering problems.

How to use a password generator properly

If you're using a password generator, I'd follow a few simple rules.

1. Use a unique password for every account

If one password is compromised, you don't want the same password protecting five other accounts.

2. Use a password manager

You don't need to memorize dozens of random passwords.

A password manager can generate and store unique credentials for you.

3. Check whether the generator is actually client-side

Don't blindly trust a website's privacy claim.

Open DevTools.

Watch the Network tab.

Generate a password and see what requests are made.

4. Don't paste sensitive passwords into random websites

Even if a generator claims to be secure, think about the trust model before using it.

For a client-side generator, the ideal architecture is simple:

Your Browser
     │
     ├── Generate random values
     │
     ├── Build password
     │
     └── Display password

     No password-generation server

That's the architecture I wanted for my own tool.

Try it

I built the password generator as part of EvoTechTool, a collection of small browser-based tools focused on being free, private, and requiring no signup.

Password Generator:

https://evotechtool.pages.dev/password-generator.html

The project is built around a simple idea:

Free · Private · No Signup

For the password generator specifically, the goal is straightforward:

Generate the password where it belongs — inside your browser.

If you're building a password generator yourself, I'd pay particular attention to two things:

Use a cryptographically secure random source such as crypto.getRandomValues(), and consider whether the password actually needs to leave the browser.

The UI can always be improved later.

The security model should come first.

What do you think about client-side password generation?

Do you prefer generating passwords entirely in the browser, or do you see situations where a server-side generator makes more sense?

I Built a Free WebRTC Leak Test (And Why Your VPN Might Be Lying to You)

SAAZone Studio — Mon, 21 Sep 2026 18:48:36 +0000

You pay $10 a month for a VPN. You think you're safe.

But a single line of JavaScript on any website can still see your real IP address. It's called a WebRTC leak, and most VPN users don't even know it exists.

I found out about this while building a privacy tool suite. I added a WebRTC test because I wanted to know if my own VPN was actually working.

Spoiler: it wasn't.

What is WebRTC?

WebRTC (Web Real-Time Communication) is the browser technology that powers video calls, voice chat, and peer-to-peer file sharing. It's what makes Google Meet, Discord, and WhatsApp Web work without any plugins.

To establish a direct connection between two browsers, WebRTC needs to know the network addresses on both ends. So it asks the browser for:

Your local IP (like 192.168.1.5)

Your public IP (the one your ISP assigned you)

The second one is the problem. Even if you're behind a VPN, WebRTC can still fetch your real public IP through a separate channel. This is called a WebRTC leak.

Why this matters

Your VPN is supposed to hide your real IP. That's the whole point.

If a website can detect your real IP through WebRTC, then:

Advertisers can identify you across VPN sessions
Websites can geo-locate you to your real city
Malicious actors can target your real network

Your VPN bill is basically wasted.

How the test works

The core API is RTCPeerConnection. Here's a simplified version:
javascript

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});

pc.onicecandidate = (event) => {
  if (event.candidate) {
    const ipRegex = /([0-9]{1,3}(\.[0-9]{1,3}){3})/;
    const match = event.candidate.candidate.match(ipRegex);
    if (match) {
      const ip = match[1];
      console.log('Detected IP:', ip);
    }
  }
};

pc.createDataChannel('');
pc.createOffer().then(offer => pc.setLocalDescription(offer));

What this does:

Creates a new peer connection with a STUN server
Registers a listener for ICE candidates (network paths the browser found)
Each candidate contains an IP address — often the real one, not the VPN's
We extract the IP with a regex and log it

The tool then compares that IP against the public IP your browser normally reports. If they're different, you have a leak.

The comparison logic

Simple version:

Public IP (from a normal API call): what your VPN shows the world

WebRTC IP (from ICE candidate): what the browser actually knows about your network

If they match → your VPN is working.
If they differ → your real IP is leaking.

You can also detect the local IP (192.168.x.x). That's less dangerous, but it reveals what router you're behind.

Why I built this client-side

Most IP leak tests are free — until they aren't. They log your IP, sell the data, or ask you to create an account to see the full results.

I wanted something different. So I built it into EvoTechTool, my free tool suite.

The whole test runs in your browser. No backend, no logs, no server. The check happens on your device and the results stay there. You can verify this by opening your browser's DevTools and watching the network tab — nothing leaves your machine.

You can try it here: https://evotechtool.pages.dev/whats-my-ip.html

Turn off your VPN, run the test, note your IP. Turn on your VPN, run it again. If the IP is the same, your VPN is leaking. If it's different, you're good.

What other leaks exist

WebRTC is not the only one. Browsers leak through:

DNS — requests may go through your ISP even with a VPN active

IPv6 — if your VPN only tunnels IPv4, your real IPv6 address can still leak

Browser fingerprinting — identifies you without needing an IP

Time zone and language — two pieces of data that narrow your location significantly

I check time zone and language in the tool too, because they're often what gives away your VPN.

The bigger picture

WebRTC is a good technology. Video calls without plugins are great. But the trade-off is that your browser knows more about your network than you might want it to share.

Understanding that trade-off is the first step to fixing it.

If you use a VPN for privacy, run the test. If it fails, switch to a VPN that handles WebRTC properly, or disable WebRTC in your browser settings.

And if you're a developer building privacy tools — don't make your users sign up to see their own IP.

What other browser APIs do you think developers use without understanding the privacy trade-offs?

I built this as part of EvoTechTool, a free suite of browser-based tools (QR generator, password generator, IP checker, username generator) from SAAZone Studio in Dhaka, Bangladesh. Everything runs client-side. No signup, no tracking, no server.

How I Built a Fully Client-Side QR Code Generator (And Why I Avoided a Backend)

SAAZone Studio — Sun, 20 Sep 2026 12:57:18 +0000

The Problem with Most QR Generators

I was building a simple tool for my own use and needed to generate a QR code for a WiFi network. I tried the popular free tools, and they all did the same thing:

They routed the QR code through their own server.
They set an expiry date (7 days, 30 days, etc.).
They charged you to keep the QR code alive after that.

I was frustrated. A QR code is just a pattern of black and white squares that encodes a URL. Why does it need to expire?

That's when I decided to build my own.

The Goal: A Truly Private, Client-Side Tool

My goal was simple: create a QR code generator where:

The QR code points directly to the content (no redirect server).
The tool runs entirely in the user's browser.
There is no backend, no database, and no tracking.

This meant the QR code would never expire. It would work forever, even if my site went offline.

The Tech Stack: Keeping It Simple

I chose to build the tool with plain HTML, CSS, and JavaScript.

I didn't need React, Next.js, or a server. The entire logic for generating the QR code could run in the browser. This kept the site incredibly fast, and it meant I could host it for free on Cloudflare Pages.

The core of the tool uses a small JavaScript library to generate the QR code image, but everything else—the UI, the form logic, and the history feature—is built from scratch.

The Hardest Part: No Backend

The biggest challenge was figuring out how to handle features without a server.

For example, I wanted users to be able to see a history of the QR codes they had generated. But I didn't want to store that data on a server. The solution was to use the browser's localStorage API. This means the history is saved locally on the user's device, and it's never sent anywhere. It's private by design.

What I Learned

Building this tool taught me a valuable lesson: you don't always need a complex framework or a backend.

For many simple tools, the browser is a powerful enough platform on its own. By removing the server, I also removed the need for user accounts, privacy policies about data storage, and a lot of complexity.

It made me think about how many other tools could be built this way—fast, free, and private.

Try It Out

The tool I built is called EvoTechTool. It's a free, client-side QR code generator with support for 11 types of content (URL, WiFi, vCard, etc.). Everything runs in your browser.

You can check it out here: https://evotechtool.pages.dev

I'd love to hear your thoughts on building serverless, client-side tools. Do you think this approach is the future for simple utilities?

DEV Community: SAAZone Studio

Why Reusing the Same Username Everywhere Is a Privacy Risk

Why Reusing the Same Username Everywhere Is a Privacy Risk

The account-linking problem

It's not the same as getting hacked

Username reuse

Credential reuse

Why a username can reveal more than you think

What I built

The generator supports multiple patterns

Why generate usernames locally?

But don't overdo anonymity

A simple system for usernames

Public / professional

Personal

Temporary / low-trust

Don't just change one character

A username isn't a security credential

Try it

I Built a Password Generator That Never Sends Your Password to a Server

First problem: Math.random()

The modulo bias problem

The actual password generation

Why client-side generation?

1. No password-generation request

2. Less trust required

3. You can inspect it yourself

What I put into the tool

What about password strength?

Random passwords vs. human-created passwords

One important distinction

How to use a password generator properly

1. Use a unique password for every account

2. Use a password manager

3. Check whether the generator is actually client-side

4. Don't paste sensitive passwords into random websites

Try it

I Built a Free WebRTC Leak Test (And Why Your VPN Might Be Lying to You)

What is WebRTC?

Why this matters

How the test works

What this does:

The comparison logic

Why I built this client-side

What other leaks exist

The bigger picture

How I Built a Fully Client-Side QR Code Generator (And Why I Avoided a Backend)

The Problem with Most QR Generators

The Goal: A Truly Private, Client-Side Tool

The Tech Stack: Keeping It Simple

The Hardest Part: No Backend

What I Learned

Try It Out

First problem: `Math.random()`