Featured Articles

Detecting (Malicious) Unicode in GitHub PRs
Why I was banned from GrapheneOS by Daniel Micay
Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)
Continuous Documentation: Hosting Read the Docs on GitHub Pages (2/2)
Introducing BusKill: A Kill Cord for your Laptop
Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
Hardening Guide for phpList
WordPress Profiling with XHProf (Debugging & Optimizing Speed)
Crowdfunding on Crowd Supply (Review of my experience)
WordPress Multisite on the Darknet (Mercator .onion alias)
previous arrow
next arrow

Persistent, Sandboxed, Single-Site Browser (firejail and proxychains)

Persistent, Sandboxed, Single-Site, Browser

Or how to avoid getting locked-out of another Google Account

This guide will describe how to setup a persistent browser (for Evil Corp) that’s isolated in a sandbox (with firejail) and forced to use a SOCKS5 proxy to retain a static IP address (using proxychains)

Have you ever been locked out of your own account, and then got an email for your service provider annoyingly letting you know that they’ve “blocked a login attempt — for your protection?“

There’s countless reports of frustrated users who have permanently lost access to their own gmail accounts because of Google’s faulty “fraud protection” systems that locked the account owner out of their own account, due to false-positives.

Problem

Especially the past 10 years, large corporations have been using machine learning anomaly detection systems on their login pages. Unfortunately, sometimes this is (ab)used to have priority over credential authentication challenges.

Even if you enter your username, password, and 2FA credentials correctly on the very first login attempt, you may get locked out of your own account because you “look different”

Even if you enter your username, password, and 2FA credentials correctly on the very first login attempt, you may get locked
. . . → Read More: Persistent, Sandboxed, Single-Site Browser (firejail and proxychains)

HPKP Best Practices for Let’s Encrypt

This post describes how to generate a few backup public key hashes to add to your HTTP Public Key Pinning (HPKP) config that might save you from bricking your domain if Let’s Encrypt ever gets untrusted like StartCom did.

If you have a healthy distrust of the X.509 PKI trust model, then you’ve probably heard of HPKP (and probably also HSTS & CAA). Website certificate pinning was a trend first started by google, who hard-coded a pin of their certificates in their Chrome browser. Eventually, google helped build a more standardized pinning method under RFC 7469. And today, it’s supported by Chrome, Firefox, and Opera.

Pinning is a great TOFU improvement to https, but–if misconfigured–you could “brick” your domain–making it so that your client’s browsers will refuse to let them access your site for months or years (interestingly, this has also caused some security experts to think of how HPKP could be abused in ransom-ware). Therefore, it’s a good idea to follow a few HPKP Best Practices.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: HPKP Best Practices for Let’s Encrypt

Google Chrome in 64-bit Sabayon Linux

I really should be studying for my stat exam tomorrow, but I was logging into my.ucf to download my lecture notes, and while Blackboard Learning System (the really shitty replacement for WebCT) was stuck in an infinite loading loop (most probably caused by incompetent javascript) I decided to finally get Google Chromium (which apparently has an excellent javascript engine) working on my Sabayon Linux desktop.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: Google Chrome in 64-bit Sabayon Linux

Re: The problem with wikipedia

Alright, I’ve been working on my research paper (an attempt to document the history and differences, and an overall comparison between the Microsoft DirectX API and the SGI OpenGL API), so I’ve been caught in the inevitable wikipedia trap. Here was my path:

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: Re: The problem with wikipedia