🔗 Random links are everywhere – but how secure are they actually?

Whether you use 1Password to share credentials, track a DHL parcel, get a return link from an online shop, or reset your bank password – all of these rely on randomly generated links. But what makes them secure?

🎲 The short answer: cryptographically generated randomness. These links are not just random-looking – they are produced by a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), which draws entropy from hardware noise, system events and other unpredictable sources. The result is a link with 128–256 bit of randomness. That means more possible combinations than atoms in the observable universe. Guessing one is not a realistic attack.

⏱️ The expiry time is your second line of defense. 1Password lets you set a link to expire after one hour or even after a single view. DHL links typically expire after package delivery. The shorter the window, the smaller the attack surface – even if someone intercepts the link, it is worthless shortly after.

📦 Who uses them?

⚡ Password managers (1Password, Bitwarden) – secure credential sharing
⚡ Parcel services (DHL, UPS, DPD, Evri) – tracking and pickup notifications
⚡ Online shops – order confirmations, return portals
⚡ Cloud storage (Dropbox, WeTransfer) – file sharing
⚡ Banks and services – password resets, identity verification

⚠️ Where it gets tricky: the link itself is nearly unbreakable. The weak point is always the channel you use to send it. Email, SMS, chat – whoever intercepts the message gets the link. Sending via an end-to-end encrypted channel like Signal or Teams significantly reduces that risk.

So: short expiry + encrypted channel = good enough for everyday use. For highly sensitive data, adding email verification on top closes the last gap.

How do you handle sharing sensitive links? Do you think about the channel, or just hit send? 🤔

#Security #CyberSecurity #Privacy #Infosec #Passwords

🔐 Been looking into hardening Unix Domain Sockets on Linux lately – here are some takeaways.

🛡️ Filesystem permissions: don’t rely on chmod on the socket file alone – some systems silently ignore it (hello SELinux). Protect the directory it lives in with 0750 and watch out for umask when calling bind() – it silently masks your intended permissions. Set umask before bind(), not chmod after.

🔍 Peer authentication: SO_PEERCRED after accept() gives you the PID, UID and GID of the connecting process, verified by the kernel. But it only captures credentials at connect() time – if the peer changes identity later, you won’t see it.

📨 Per-message auth: SCM_CREDENTIALS via sendmsg/recvmsg solves that. The kernel verifies the credentials on every message, even if the sender tries to lie. Essential when processes switch identity during their lifetime.

⚡ SOCK_SEQPACKET instead of SOCK_STREAM is worth considering. You get atomic message boundaries from the kernel – no custom framing, no partial reads, no glued-together messages.

🚦 Rate limiting unfortunately has to happen in userspace – the kernel offers nothing useful for per-peer UDS rate limiting. A simple token bucket per connection does the job.

Anyone else spent time hardening UDS? Curious what else people do beyond the basics.

#Linux #UnixDomainSockets #Security #SystemsProgramming #IPC #Infosec

🖥️ After years of VS Code I switched to Neovim – on an old MacBook Pro running Linux Mint.

The trigger was pretty simple: VS Code was just too heavy for the hardware. CPU at 100% on startup, Firefox open at the same time? Forget it.

Honestly the switch wasn't as big as expected – I had always used the Vim plugin in VS Code for shortcuts anyway. Moving to native Neovim was more of a "finally going all in" moment.

💡 What surprised me most: the performance. Neovim starts in milliseconds, the fan stays quiet, and the whole system just feels more relaxed.

I'm still experimenting and gradually porting the features I loved in VS Code. Debugging, CMake integration, AI support – there's still a lot to explore.

Anyone made a similar switch or have plugin recommendations for C++ development?

#Neovim #VSCode #Linux #CppDevelopment #LinuxMint #DeveloperTools

The Prefork server model gets dismissed as “old school”. I think that’s wrong – especially on Linux.
With SO_REUSEPORT, the kernel distributes incoming connections across multiple pre-forked worker processes natively. No thread contention. No shared memory complexity. Each worker is an isolated process – a crash stays contained.

What you get:
– True process isolation per connection
– Kernel-level load balancing, no userspace overhead
– Predictable memory footprint
– Simpler security boundaries between workers

In a world obsessed with async event loops, we forget that prefork scales surprisingly well for workloads with high per-connection compute and where isolation actually matters – think security-sensitive services.
SO_REUSEPORT didn’t just fix the thundering herd problem. It quietly gave prefork a second life.
More on this soon.
#linux #infosec #networking #serversecurity #prefork