Hey everyone, Alex here. Welcome back to another edition of Coding with Alex on sysseder.com.
If you’ve been browsing Hacker News lately, you’ve probably seen the collective groan echoing through the community regarding the state of professional networking. The headline "LinkedIn is a cesspool of scammers and identity theft" recently hit the top spot, and it struck a chord. We’ve all seen it: the fake recruiters pitching "amazing remote opportunities" that turn out to be malware delivery campaigns, the cloned profiles of prominent open-source maintainers, and the sophisticated phishing attempts targeting DevOps engineers to compromise CI/CD pipelines.
As developers, we shouldn’t just complain about these platform vulnerabilities; we should look at how to solve them. Why are centralized platforms failing so spectacularly at identity verification? More importantly, how can we, as software engineers, build robust, decentralized, and cryptographically secure identity verification systems into our own applications to prevent these kinds of social engineering attacks?
Today, we’re going to dive deep into the mechanics of cryptographic identity. We'll look at why traditional "blue checkmark" verification systems fail, explore the W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) standards, and write some practical Node.js code to issue and verify cryptographically signed user claims.
Why Centralized "Verification" is Broken
Most mainstream platforms verify identity using what I call the "bureaucratic method." You upload a photo of your driver’s license or passport, a third-party service like Persona or Jumio runs OCR on it, checks it against some database, and tells the platform, "Yep, this is Alex." The platform then database-flags your account as is_verified: true and slaps a badge on your profile.
This approach has three massive points of failure:
- The Honeypot Problem: Centralized databases of scanned government IDs are prime targets for hackers. When these services get breached, real identities are stolen, fueling the very cycle of identity theft we're trying to stop.
- Zero Portability: If I verify my identity on one platform, I can't easily prove that verification on another without repeating the entire intrusive process.
- No Ongoing Trust: A database flag is incredibly easy to spoof if an account is hijacked via session hijacking, SIM swapping, or malicious OAuth integrations. The "verified" badge remains, but the actor behind it has changed.
To fix this, we need to move toward cryptographic identity verification, where identity is proven continuously through public-key cryptography, and claims are portable, tamper-evident, and revocable.
The Architecture of Cryptographic Identity: DIDs and VCs
Instead of relying on a centralized platform to vouch for us, we can leverage the W3C standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). Here is how the architecture looks conceptually:
+--------------+ +--------------+
| | 1. Issues VC | |
| Issuer |------------------>| Holder |
| (e.g. Github,| (Signed Claim) | (User Wallet)|
| University) | | |
+--------------+ +--------------+
\ /
\ /
2. Resolves 3. Presents
DID Document Verifiable
\ Presentation
v v
+----------------------------------------+
| |
| Verifier |
| (e.g. Your Application) |
| |
+----------------------------------------+
Let's break down this flow:
- The Issuer: An entity (like a university, an employer, or GitHub) signs a claim about a user (e.g., "This user owns the GitHub handle @alex_dev") using their private key. This signed claim is the Verifiable Credential (VC).
- The Holder: The user stores this VC in a digital wallet (or local storage/mobile app key store). They control it completely.
- The Verifier: When the user wants to log into your application or prove their credentials, they present the VC. Your application (the Verifier) looks up the Issuer's public key (using their DID Document) and cryptographically verifies the signature.
Because this relies on asymmetric cryptography, the verifier doesn't need to contact the issuer in real-time, nor does the user need to expose sensitive personal data like their actual ID document.
Hands-On: Implementing Cryptographic Claims in Node.js
Let's write some code to see how we can implement a basic, lightweight cryptographic identity check. In this scenario, we will act as the Verifier. We want to verify that a user who claims to be a core contributor to an open-source project actually holds a private key corresponding to a registered public key associated with that project.
We'll use Node's native crypto module to handle the key generation, signing, and verification. No heavy, external proprietary libraries required.
Step 1: The Issuer/User Key Generation
First, let's simulate the user generating a public/private keypair. In a real-world app, the private key would live securely in the user's browser (WebCrypto API) or on their hardware security module (like a YubiKey).
const crypto = require('crypto');
// Generate a secure ECDSA key pair (using the secp256k1 curve, common in crypto/Web3)
const { publicKey, privateKey } = crypto.generateKeyPairSync('ec', {
namedCurve: 'secp256k1',
publicKeyEncoding: { type: 'spki', format: 'pem' },
privateKeyEncoding: { type: 'pkcs8', format: 'pem' }
});
console.log("--- USER KEYS GENERATED ---");
console.log(publicKey);
Step 2: Creating and Signing the Identity Claim
Now, let's say our user wants to present a claim. The claim is a JSON object stating their username and the timestamp. To prove they own this identity, they sign this JSON payload using their private key.
// The identity claim payload
const identityClaim = {
username: 'alex_dev',
platform: 'sysseder.com',
issuedAt: new Date().toISOString(),
nonce: crypto.randomBytes(16).toString('hex') // Prevents replay attacks
};
const claimString = JSON.stringify(identityClaim);
// Sign the claim with the private key
const signer = crypto.createSign('SHA256');
signer.update(claimString);
signer.end();
const signature = signer.sign(privateKey, 'base64');
console.log("--- GENERATED CLAIM & SIGNATURE ---");
console.log("Claim:", claimString);
console.log("Signature (Base64):", signature);
Step 3: Verifying the Claim on Your Backend
When the user sends this claim and the signature to your server, you need to verify it. You will take the raw claim string, the signature, and the public key they've registered on their profile (or retrieved from a trusted public directory/DID registrar).
function verifyUserIdentity(receivedClaim, receivedSignature, userPublicKey) {
try {
const verifier = crypto.createVerify('SHA256');
verifier.update(receivedClaim);
verifier.end();
const isValid = verifier.verify(userPublicKey, receivedSignature, 'base64');
// Also verify the timestamp is fresh to prevent replay of old intercepted signatures
const claimData = JSON.parse(receivedClaim);
const ageInMilliseconds = Date.now() - new Date(claimData.issuedAt).getTime();
const fiveMinutes = 5 * 60 * 1000;
if (ageInMilliseconds > fiveMinutes) {
console.error("Verification Failed: Claim has expired.");
return false;
}
return isValid;
} catch (err) {
console.error("Verification error:", err.message);
return false;
}
}
// Let's test it out
const isVerified = verifyUserIdentity(claimString, signature, publicKey);
console.log(`\n--- VERIFICATION RESULT ---`);
console.log(`Is the user's identity cryptographically valid? ${isVerified ? 'YES' : 'NO'}`);
If someone tries to impersonate "alex_dev" by changing the username in the JSON payload, the cryptographic signature check will immediately fail because only the holder of the private key could generate a valid signature for that specific string.
Mitigating Replay and Man-in-the-Middle Attacks
In our code above, you might have noticed two crucial fields in the claim: nonce and issuedAt.
If we simply signed the message "I am Alex", an attacker could intercept that signature and replay it to gain unauthorized access to your system. By forcing the client to sign a dynamic nonce (provided by your server on-demand) combined with a short-lived issuedAt timestamp, you guarantee that the signature was generated in real-time, specifically for the current authentication session.
How We Can Implement This in Production Right Now
You don't need to wait for LinkedIn or other tech giants to implement this. If you are building SaaS platforms, developer tools, or internal admin panels, you can start building trust boundaries using public-key infrastructure today:
1. SSH and GPG-based Git Verification
If you're building collaboration tools for developers, don't just rely on passwords or OAuth. You can allow users to verify their identity by proving they hold the private key to the SSH or GPG keys they use for Git commits. GitHub does this elegantly with "Verified" tags on commits.
2. WebAuthn for Passwordless Identity
Stop relying on SMS 2FA, which is easily bypassed by social engineering and SIM-swapping. Implement WebAuthn (FIDO2). It utilizes hardware-backed public-key cryptography (like TouchID, FaceID, or physical security keys) to authenticate users. It is entirely immune to phishing because the browser ensures the cryptographic challenge is bound to the specific origin URL.
3. Ephemeral Certificate Authorities
For internal infrastructure access, move away from static API keys and long-lived credentials. Implement an internal Certificate Authority (such as HashiCorp Vault or Smallstep) that issues short-lived, cryptographically signed X.509 certificates to your developers based on their identity provider login. This ensures that even if a developer's machine is compromised, the access expires automatically within hours.
Conclusion
The rampant identity theft and spam on platforms like LinkedIn are symptoms of a systemic architectural flaw: relying on centralized databases of easily forged documents and easily spoofed static database flags.
As software engineers, we have the mathematical tools to fix this. By implementing asymmetric cryptography, decentralized identifiers, and WebAuthn standards in the systems we build, we can create an internet where identity is verified by math, not by easily manipulated blue badges.
Are you implementing cryptographic verification or WebAuthn in your current projects? What are the biggest hurdles you've faced with key management and user UX? Let me know in the comments below, or hit me up on our community Discord!
Until next time, keep your private keys private.
— Alex