DEV Community: Muhammad Imran

Math.random() Is Not Enough: Generating Truly Secure Passwords in JavaScript

Muhammad Imran — Thu, 15 Oct 2026 07:31:44 +0000

Most password generators you find in tutorials share the same flaw. They call Math.random(), pick characters from a string, and call it a day. The passwords look random. They are not random enough.

This matters because a predictable generator is barely better than no generator at all. If someone can guess the internal state of your random source, they can reproduce every "random" password it ever produced.

Why Math.random() is not safe

Math.random() is a pseudorandom number generator. It starts from a seed and produces a long but fully deterministic sequence. In V8 (the engine behind Chrome and Node.js) the algorithm is xorshift128+. It is fast and fine for games, shuffling a playlist, or picking a random quote.

It is not fine for security, for three reasons:

It is predictable. Given enough consecutive outputs, the internal state can be reconstructed, and every future value becomes known. Researchers have demonstrated this repeatedly against real-world token generators.
It is not seeded by you. You cannot give it a strong seed, and you cannot verify the quality of the seed the engine chose.
MDN says so directly. The documentation warns that Math.random() does not provide cryptographically secure random numbers and must not be used for anything security related.

Passwords, reset tokens, session IDs, and API keys are all security related.

What to use instead

Browsers and Node.js ship a cryptographic random source: the Web Crypto API.

const array = new Uint32Array(4);
crypto.getRandomValues(array);
console.log(array); // four unpredictable 32-bit numbers

crypto.getRandomValues() pulls from the operating system's entropy pool, the same source used for TLS keys. It is available in every modern browser and in Node.js 19+ as a global (earlier via require('crypto').webcrypto).

For single IDs, crypto.randomUUID() gives you a v4 UUID in one call:

const id = crypto.randomUUID();
// "3f6d4a2e-9b1c-4d5f-8a2e-7c9d1b3f5a6e"

The math that actually matters: entropy

A password's strength is measured in bits of entropy. The formula is simple:

entropy = length x log2(charset size)

Some concrete numbers:

8 lowercase letters: 8 x 4.7 = ~38 bits. Crackable in hours on a single GPU.
12 characters from letters, digits, and symbols (94 chars): 12 x 6.55 = ~79 bits. Out of reach for brute force.
16 characters from the same set: ~105 bits. Comfortable margin for years.

Length beats cleverness. A 16-character password from a plain generator is stronger than an 8-character one full of symbols that you struggle to remember. This is also why passphrases work: four random words from a 7,776-word list give about 51 bits, and they are easy to type.

Building a secure generator

Here is a compact generator that does it right:

function securePassword(length = 16) {
  const charset =
    "abcdefghijklmnopqrstuvwxyz" +
    "ABCDEFGHIJKLMNOPQRSTUVWXYZ" +
    "0123456789" +
    "!@#$%^&*()-_=+[]{};:,.<>?";

  const randomValues = new Uint32Array(length);
  crypto.getRandomValues(randomValues);

  let password = "";
  for (let i = 0; i < length; i++) {
    // modulo bias is negligible here for typical lengths,
    // but rejection sampling removes it entirely
    password += charset[randomValues[i] % charset.length];
  }
  return password;
}

console.log(securePassword()); // e.g. "kQ7$mZ2@pL9#vX4!"
console.log(securePassword(20));

A few notes on this code:

crypto.getRandomValues() fills the whole array in one call, which is faster than calling it per character.
The % charset.length introduces a tiny modulo bias because 2^32 is not a multiple of 91. For password generation this bias is negligible, but if you want it gone, discard values above the largest multiple of the charset size and draw again.
The function runs entirely client-side. The password never leaves the browser, which is exactly how a generator should behave.

If you want to go further, add options users actually ask for: exclude ambiguous characters (0, O, l, 1), guarantee at least one character from each group, or generate a memorable passphrase from a word list instead.

Mistakes to avoid

Seeding with Date.now(). Timestamps are guessable to the millisecond. An attacker who knows roughly when a password was created can brute force the seed.
Using Math.random() for reset tokens or API keys. Same predictability problem, worse consequences, because tokens are often transmitted and logged.
Short lengths with big charsets. Eight characters is short no matter how exotic the symbols are. Default to 16 or more.
Rolling your own crypto. You do not need a custom shuffling algorithm. The platform already gives you a vetted one.

The one-line version

If you just need a strong password right now and do not want to write code, there is a free client-side password generator at https://handynest.live/tools/password-generator.html that uses this same approach. Nothing is sent to a server.

Takeaway

Random-looking is not random. Math.random() is a fast PRNG for non-security tasks. For passwords, tokens, and keys, reach for crypto.getRandomValues(), make the output long enough to carry real entropy, and keep the whole thing client-side. It is about ten lines of code, and it is the difference between a password that looks strong and one that actually is.

HTTP vs SOCKS5 Proxies: Which One Should You Actually Use?

Muhammad Imran — Mon, 12 Oct 2026 09:15:06 +0000

HTTP vs SOCKS5 Proxies: Which One Should You Actually Use?

You grabbed a proxy from a free list, pasted it into your scraper, and it half-works. Pages load but stall. Connections drop. Your code is fine. The proxy is alive. So what broke?

Probably the protocol. HTTP and SOCKS5 proxies look interchangeable on a proxy list, but they behave very differently under the hood. Pick the wrong one and you get weird failures that are painful to debug. Here is how they differ and how to choose.

What an HTTP proxy actually does

An HTTP proxy understands HTTP traffic. When you send a request through it, the proxy reads your request line and headers, forwards them to the target server, and passes the response back. It can cache responses, filter content, and log what passes through.

That is also its limit. It only speaks HTTP (and HTTPS via the CONNECT method, which just opens a blind tunnel). If your traffic is not web traffic, an HTTP proxy cannot carry it.

For most web scraping this is fine. Your Python requests code only ever makes HTTP calls, so an HTTP proxy slots right in:

import requests

proxies = {
    "http": "http://203.0.113.10:8080",
    "https": "http://203.0.113.10:8080",
}

r = requests.get("https://example.com", proxies=proxies, timeout=10)
print(r.status_code)

If you work with HTTP proxies on a daily basis, you will notice they are the most common type on every free proxy list. That abundance is their main selling point: easy to find, easy to replace when one dies.

What SOCKS5 does differently

SOCKS5 does not care what your traffic is. It works at a lower level, shuttling raw TCP (and UDP) packets between you and the destination without reading or interpreting them. Your application asks for a connection, SOCKS5 opens it, and then it gets out of the way.

Three practical differences follow from that:

UDP support. SOCKS5 can carry UDP traffic. HTTP proxies cannot. If your use case involves anything beyond plain web requests, DNS-over-UDP quirks, VoIP, or gaming traffic, SOCKS5 is your only option of the two.
Authentication built in. SOCKS5 has native username/password auth in the protocol. With HTTP proxies, auth is bolted on via headers and behaves inconsistently across servers.
No header meddling. A SOCKS proxy does not touch your headers. With misconfigured HTTP proxies you sometimes get rewritten headers or stripped cookies, which breaks login flows and fingerprint-sensitive scraping.

In Python, SOCKS5 needs a small helper because requests does not speak SOCKS natively:

import requests

# pip install requests[socks]
proxies = {
    "http": "socks5://203.0.113.20:1080",
    "https": "socks5://203.0.113.20:1080",
}

r = requests.get("https://example.com", proxies=proxies, timeout=10)
print(r.status_code)

The code looks identical. The transport underneath is not.

The honest comparison

HTTP proxy vs SOCKS5 proxy:

Traffic types: HTTP/HTTPS only vs any TCP or UDP traffic
Speed for web requests: slightly faster vs slightly slower
Authentication: via headers, inconsistent vs native in-protocol auth
Header handling: can modify or strip headers vs passes everything through untouched
Availability on free lists: very common vs less common, dies faster
Best for: web scraping, browsing vs bots, streaming, gaming, anything with UDP

Neither is "better" in general. The right question is always: what traffic are you sending?

When to use which

Use HTTP when: you are scraping websites or doing anything that is purely web traffic. HTTP proxies are faster for this, far easier to find for free, and your existing code already supports them. If you just need a quick proxy for a script, grab one from a free list and go.

Use SOCKS5 when: you need UDP, you need reliable authentication, or you are running into weird issues that smell like header interference. Scrapers that log in to accounts, tools that tunnel non-web protocols, and anything latency-sensitive over UDP belong on SOCKS5.

One more scenario: rotation pools. If you rotate proxies per request, mixing protocols in one pool is a classic source of silent failures. Keep HTTP and SOCKS5 proxies in separate pools and route traffic accordingly. A scraper that randomly gets a SOCKS5 proxy for an HTTP-only code path (or vice versa) will produce the exact kind of intermittent breakage that eats your afternoon.

Before you trust any proxy, test it

Protocol choice only matters if the proxy itself works, and most free proxies do not. Roughly half of freshly listed free proxies never respond at all, and of the ones that do, about half die within hours.

So test first, code second. A proxy checker that reports protocol, anonymity level, and response time tells you in seconds whether a proxy is worth your time. Check the protocol field specifically: plenty of lists label everything "HTTP" when it is not.

The short version

Scraping websites? HTTP is fine and plentiful. Need UDP, clean headers, or real auth? SOCKS5. Test every proxy before you trust it, keep your protocol pools separate, and stop debugging code that was never broken. The proxy was the problem all along.

How to Build a Proxy Rotator in Python (That Actually Works)

Muhammad Imran — Thu, 08 Oct 2026 18:38:14 +0000

If you have ever run a web scraper for more than a few hours, you know the pattern. It works great at first. Then the requests start failing. Then your IP gets blocked entirely. The site was not even angry at you, you just looked like a bot because every request came from the same address.

The fix is rotating proxies: send each request (or every few requests) through a different IP address. It sounds complicated, but the core idea fits in about 40 lines of Python. Here is how I built mine.

What you need

Python 3.8+
requests library (pip install requests)
A list of proxies (I will show you where to get free ones)

Step 1: Get a proxy list

You need a pool of proxies to rotate through. Free proxy lists work fine for learning and light jobs. I maintain ProxyNest, a free proxy list that retests its entries continuously, and it has a simple JSON API:

GET https://proxynest.live/api/proxies?limit=50

That returns a list of live proxies with their IP, port, protocol (http/socks4/socks5), and country. For this tutorial you can also paste proxies from any list into a text file, one per line in ip:port format.

Step 2: Build the rotator

The idea is simple. Keep a list of proxies, pick one at random (or round-robin) for each request, and drop the ones that fail so they do not poison your pool.

import random
import requests
import time

PROXY_API = "https://proxynest.live/api/proxies?limit=100"

def fetch_proxies():
    resp = requests.get(PROXY_API, timeout=10)
    resp.raise_for_status()
    proxies = []
    for p in resp.json():
        url = f"{p['protocol']}://{p['ip']}:{p['port']}"
        proxies.append({"http": url, "https": url})
    return proxies

class ProxyRotator:
    def __init__(self):
        self.proxies = fetch_proxies()
        self.bad = set()

    def get(self):
        good = [p for p in self.proxies
                if p["http"] not in self.bad]
        if not good:
            raise RuntimeError("Proxy pool exhausted, refetching...")
        return random.choice(good)

    def mark_bad(self, proxy):
        self.bad.add(proxy["http"])

rotator = ProxyRotator()

That is the whole rotator. Ten lines of real logic.

Step 3: Use it in your scraper

Now wrap your requests so a dead proxy does not kill the run:

def fetch(url, max_retries=5):
    for attempt in range(max_retries):
        proxy = rotator.get()
        try:
            resp = requests.get(
                url,
                proxies=proxy,
                timeout=10,
                headers={"User-Agent": "Mozilla/5.0 (compatible; my-scraper/1.0)"},
            )
            resp.raise_for_status()
            return resp.text
        except requests.RequestException:
            rotator.mark_bad(proxy)
            time.sleep(1)
    raise RuntimeError(f"Failed to fetch {url} after {max_retries} retries")

html = fetch("https://example.com/products")
print(len(html), "characters fetched")

A few things to notice:

Dead proxies get removed. mark_bad takes failing proxies out of the pool instead of retrying them forever.
Random selection beats round-robin for small pools, because it spreads load unevenly and looks less mechanical.
The User-Agent matters. Rotating proxies but sending the same default python-requests user agent is like wearing a disguise and then shouting your name. Set a realistic one.

Step 4: Do not be rude

Rotation is not a license to hammer a site. Add delays between requests (time.sleep(1) at minimum), respect robots.txt, and keep your concurrency sane. Most blocks happen because of request rate, not because of proxies. The proxy just buys you a second identity; it does not make aggressive scraping polite.

If you need serious throughput, free proxies will eventually frustrate you. They die fast and they are slow. But for learning, prototypes, and light scheduled jobs, this setup works surprisingly well.

The takeaway

Proxy rotation is one of those things that sounds like infrastructure but is really just a list and a random choice. Fetch a pool, pick one per request, drop the failures, and be polite about your request rate. That is 90 percent of it.

Muhammad Imran works on network tooling and runs ProxyNest, a free directory of public proxies with a live API and a proxy checker that re-verifies any proxy on demand.