Hey there. 👋

Novice homebrewing is great. Losing temperature during the mash isn't. This post is all about keeping temps with small batch sizes and stainless steel mash tuns.

I did what my partner calls a "tiny science" and collected data on my stock pot, and how well my DIY insulation job fared.

Why 🤔

Why? Because buying equipment is expensive. And isn't homebrew all about doing it yourself?

Small Equipment 🔎

When I got my Brooklyn Brew Shop's Beer Making Kit for Christmas (great gift by the way). It only had a 1gal carboy, no mash tun or boil kettle in sight! I did what any reasonable person would do, I bought a ~3gal stock pot from Chinatown for $40 CAD. Two, in fact. They are my boil kettles, my mash tuns, and my liquor tanks.

Problem is, keeping temperatures stable during the mash using a steel pot at this scale is a miserable experience. Every 5 minutes I'm fussing and stressing, either overshooting (> 152°F) or undershooting (< 144°F) the temps. I can't figure out how severe the temperature gradient is: how cool is the top and how hot is the bottom. I've aggressively stirred to increase consistency throughout the mash, which lost heat overall. So I upped the burners, scorching the grain. Vicious cycle not worth the trouble. Screw that.

Saving Money (Sunk Cost?) 💸

I'm a cheap guy. I don't like my hobbies costing too much. I want to believe that DIY is half the fun, and it should also be half the cost.

Incremental Upgrades (Insulation!) 📈

I don't want to throw out my current stuff. I don't want to re-invest in new equipment. Apartment space in Toronto is a luxury, my two stock pots take up enough space. What can I do to make them better?

Instead of buying a cooler, I opted to insulate my one of my pots.

Fermware did an outstanding series on mash tun insulations (go check it out!). They're the ones who inspired me to do this upgrade. However their experiments were at a larger scale, using an electronic kettle/mash tun that most novices don't have or care to invest in. I can't trust that data will apply at my scale.

So I'm giving back to the homebrew community. My data is all about the little guy (well, little batches at least). This one is for you, The Novices, who are stingy like me and are saddled with a stock pot for a mash tun and crank out less than 3 gallon batches.

Insulation Methods 📋

I only used Reflectix as insulation. Fermware gave me confidence in its efficacy and its affordable! Home Depot sells Reflectix Bubble Pack 2'x10' (Model #BP24010) for $24.98 CAD which gave me more than enough for this experiment.

Control

Hey! It wouldn't be an experiment without a control, eh? Plus I get to finally see how quickly this sucker cools without me fussing with it.

Reflectix "Jacket"

A nice, clean, single layer of Reflectix wrapped around the pot. Installed into the lid as well.

Triple-layered Reflectix "Jacket"

Take the above, but do it three times! This to see if the temps could be improved with a thicker wall.

I didn't bother with the 2cm gap method as recommended by Reflectix for hot water tanks since Fermware's data showed little difference and a 3-layer jacket is cumbersome enough as it is.

Methodology 🔬🧪👨‍🔬

We're using a ~3gal stock pot. It has a steam basket on the inside as a false bottom. The temperature probe rests on top of the steam basket, raising it approx. 1 inch above the bottom of the pot.

The probe is some digital oven thermometer I had laying around: it's stainless steel and appears to be waterproof.

Because my brews thus far have been for 1 gallon batches (I need to upgrade my carboy!), we'll only be using 1 gallon of water for the test. Plus this will show just how temperamental keeping low volumes at a consistent temperature.

Heat is applied using my portable induction stove (Duxtop 9100MC). I have an induction stove because electric ranges suck, lag getting up to temp, and raise my energy bill with wasted heat. I recommend you get one for cooking!

Steps

1. Bring the 1 gallon of water up to 160°F using stove's max heat
2. Once at temperature, turn off the stove and start the timer
3. Every 10min, record the temperature as indicated on my oven thermometer thing.
4. Don't disturb it: no taking off the lid or stirring the water.
5. Graph the data! 🎉

"Shut up! Results!" 📊

Ok fine.

Discussion 🗣

I don't think anyone is surprised. This is consistent with Fermware's lab results although slightly steeper curves. I credit this exclusively to the fact I have less thermal mass to work with.

The resolution of my data isn't the best. I'm manually checking a thermometer of unknown calibration, with zero-decimal precision, every 10min using a stopwatch. You can see the lines are a bit bumpy. I would say any measurement has a ±0.5°F margin of error.

Another error in my methodology is turning off the stove exactly at 160°F. A better approach would have been bringing it to 165°F, watch it fall, and begin data collection & timing at the 160°F mark. This may explain the sudden "drop" at the beginning for both insulation tests.

Despite all that, it's clear from the data insulation is a marked improvement:

Control slope: (160-134)/(0.00-70.0) = -0.371 °F/min
Jacket slope: (160-136)/(0.00-110) = -0.218 °F/min
Triple Jacket slope: (160-141)/(0.00-120) = -0.158 °F/min

From the above slope calculations, we can see the jacket is 1.70x better than control and triple jacket is 2.35x better than control, losing only 1.58°F every 10 minutes.

Conclusion 🎉

Had I known what I know now, the instant I unwrapped that homebrew kit gift, I'd have turned around and buy a water cooler immediately. Maybe even get one of those conversion kits with the spigot and integrated brew thermometer.

But I didn't, so here we are. We're working with what we got. Not surprisingly, the 3-layered jacket performs the best, losing only ~1.6°F every 10min. Thanks to being on an induction, I can apply a small amount of heat once or twice to keep exactly where I want it during a 60 minute mash. A definite pro against a regular cooler. This is a satisfying result that competes with an insulated cooler mash tun.

The single layer method doesn't look to be worth the trouble: you're just selling yourself short. With the extra insulation available and minimal additional bulk, I don't see why you wouldn't just triple-up and enjoy improved temp stability.

I will be keeping this setup for all of my future homebrews! I can only expect it will be even easier with 2 or 3 gallon brews. 😌

Addendum

I originally started this experiment be beginning with boiled water (100°C / 212°F) but quickly discovered I didn't want to remain shackled at my dinner table for more than 9 hours to collect the full data set.

Enjoy the bonus chart where I stuck to it for the control. Note the curve trend!

TL;DR: If a public client respects the RFC 7009 spec and does not authenticate the revocation request, then Doorkeeper does not actually revoke the access token. Upgrade to versions 4.4.0, 5.0.0.rc2 or later

The Problem

Any OAuth application that uses public/non-confidential authentication when interacting with Doorkeeper is unable to revoke its tokens when calling the revocation endpoint.

A bug in the token revocation API would cause it to attempt to authenticate the public OAuth client as if it was a confidential app. Because of this, the token is never revoked.

The impact of this is the access or refresh token is not revoked, leaking access to protected resources for the remainder of that token's lifetime.

If Doorkeeper is used to facilitate public OAuth apps and leverage token revocation functionality, upgrade to the patched versions immediately.

Vulnerable Versions

4.2.0 – 4.3.2
5.0.0.rc1

Impact

All public, non-confidential clients respecting the RFC will not have their access or refresh tokens revoked when sending a valid, well-formed & unauthenticated revocation request to doorkeeper.

Any such clients relying on Doorkeeper's revocation functionality are susceptible to a session replay attack, even after the victim terminates their session via a revocation/log out.

1. Attacker gains access token via any acceptable means (MiTM, physical computer access, bug in client code, etc.)
2. Victim logs out/attempts to revoke the access token
3. Attacker is not affected, as the token is still valid for the duration of its lifespan. Furthermore, the refresh token can be used to extend the attacker's privileged access.

This scenario is captured under the OWASP Top 10 (2013)'s A2: Broken
Authentication and Session Management as a vulnerability.

Now obviously the attacker must already be able to obtain the access token, but without revocation the victim has a false sense of security & cannot limit damage to their account. Additionally, clients relying on the Doorkeeper revocation endpoint to revoke all other issued tokens on password change, password reset, etc. would also be impacted by this problem.

The Fix

Doorkeeper needed a structural update so it is able to define which OAuth client application is intended to be public or confidential.

With that now available, the tokens revocation API knows to either enforce authentication (as required for confidential clients) or accept just the client ID (as is the case for a public client).

See the following PRs for more info:

• https://github.com/doorkeeper-gem/doorkeeper/pull/1119
• https://github.com/doorkeeper-gem/doorkeeper/pull/1031

Credit

All credit to Roberto Ostinelli for discovery.

Thanks to the Distributed Weakness Filing Project for a swift assignment of a CVE identifier.

References

• https://github.com/doorkeeper-gem/doorkeeper/issues/891

Header image is by Kevin King under the Creative Commons license CC BY 2.0

Doorkeeper is a Ruby gem that makes it easy to introduce OAuth 2 provider functionality to a Rails or Grape application.

Depending on how a developer uses the gem, they may allow any registered user to create OAuth client applications in their software.

CVSSv3

Base Score: 7.6 (High)
Temporal Score: 6.8 (Medium)
Vector: AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N/E:P/RL:O/RC:C

Attack Details

Stored XSS on the OAuth Client's name will cause users being prompted for consent via the "implicit" grant type to execute the XSS payload.

The XSS attack could gain access to the user's active session, resulting in account compromise.

Any user is susceptible if they click the authorization link for the malicious OAuth client. Because of how the links work, a user cannot tell if a link is malicious or not without first visiting the page with the XSS payload.

The requirement for this attack to be dangerous in the wild is the software using Doorkeeper must allow regular users to create or edit OAuth client applications.

If 3rd parties are allowed to create OAuth clients in the app using Doorkeeper, upgrade to the patched versions immediately.

Additionally there is stored XSS in the native_redirect_uri form element.

DWF has assigned CVE-2018-1000088.

Proof of Concept

See Doorkeeper issue #970:

1. Log in as a user capable of creating OAuth client applications
2. Create an OAuth client application
3. Set the Client Name to <script>alert('XSS')</script>
4. Trick other users to click your implicit authorization link

Timeline

1. Discovered by Gauthier Monserand May 25, 2017
2. Fix prepared by Gauthier Monserand May 25, 2017
3. Maintainer released patched version May 26, 2017
4. CVE requested February 17, 2018
5. CVE assigned February 20, 2018
6. This post is published February 21, 2018

Affected Versions

v2.1.0 – v4.2.5

Fix

Not Using Custom Views

If the software using Doorkeeper did not generate custom views, simply upgrade to v4.2.6 or greater.

Using Custom Views

Any software using Doorkeeper with custom views must manually escape the fields:

In app/views/doorkeeper/authorizations/new.html.erb:

Look for the raw field for client_name and ensure no explicit HTML exists in the value. Use Rails' safe helpers if HTML is required (such as content_tag). e.g. this diff

-    <%= raw t('.prompt', client_name: "<strong class=\"text-info\">#{ @pre_auth.client.name }</strong>") %>
+    <%= raw t('.prompt', client_name: content_tag(:strong, class: 'text-info') { @pre_auth.client.name }) %>

In app/views/doorkeeper/applications/_form.html.erb:

Look for the raw field for native_redirect_uri and ensure no explicit HTML exists in the value. Use Rails' safe helpers if HTML is required (such as content_tag). e.g. this diff

-  <%= raw t('doorkeeper.applications.help.native_redirect_uri', native_redirect_uri: "{gfm-js-extract-pre-1}") %>
+  <%= raw t('doorkeeper.applications.help.native_redirect_uri', native_redirect_uri: content_tag(:code) { Doorkeeper.configuration.native_redirect_uri }) %>

Credit & References

Discovered and fixed by Gauthier Monserand:

• https://github.com/doorkeeper-gem/doorkeeper/issues/969
• https://github.com/doorkeeper-gem/doorkeeper/pull/970

There comes a time where regardless of your unit testing you have errors in production. But, alas, the exception isn't in your controller itself but the view!

There has been a quick and dirty way of getting the full stack trace in console for a while but it fails to hit the mark in Rails 4 and Rails 5.

Below is the full copy/paste snippet that will let you try and render a view in console. Very helpful with JSON APIs that use jbuilder that can have complex logic and multiple partial inheritance. Any error or exception will generate a full stack trace for you to debug with.

def rendered_view(view_path, variables = {})  
  view = ActionView::Base.new(Rails.configuration.paths['app/views'], variables)
  view.extend ApplicationHelper
  view.class_eval do
    include Rails.application.routes.url_helpers
    include ApplicationHelper
    def protect_against_forgery?
      false
    end
  end
  view.render(file: view_path)
end  

Example

Given a view like below

# views/api/users/show.json.jbuilder
json.foo  foo  
json.user @user.id  

Use the helper method you'd use in production console like so to get the exception stack trace:

rendered_view('api/users/show', { 'user' => User.find(123), 'foo' => 'bar' })  
# => ActionView::Template::Error: some exception you're debugging for
#        from ...
#        from ...
#        ...

Or once you've resolved the error:

# => "{\"foo\":\"bar\":,\"user\":123}"

Happy hunting!

This posts's header is by Matthew Potter. Used under CC BY 2.0 license.

TL;DR: Once a user successfully provides a valid OTP, that OTP can be replayed for the duration of the timestep. Upgrade to version 2.0.0 or higher.

The Problem

Devise-Two-Factor implements RFC 6238 which defines a way to provide what is commonly known as Two-Factor Authentication (2FA).

RFC 6238 states that once a valid OTP is successfully proven to the server, the server must reject all subsequent validation attempts of that OTP for a given timestep. In other words, as the name implies, the OTP can only be used once.

Devise-Two-Factor failed to "burn" a given OTP code once validated successfully.

The Impact

Despite violating a security design concern in the RFC, the impact is quite small.

1. Attacker has a window of opportunity of the timestep (30 seconds by default)
2. Attacker must shoulder-surf or MiTM the OTP code.
3. Attacker must already know the victim's password.

Satisfying these conditions will defeat two-factor authentication for the victim, in that one authentication scenario.

However, the Man-in-The-Middles (MiTM) scenario is moot since, if an attacker can MiTM the
connection, they can just obtain the granted session secret from the response instead.

Solution

Because the server (aka verifier) must now "remember" which tokens are valid and which are not, a storage mechanism must be used. Caches are a pallatable solution but permenant storage is desired.

In the case of Devise-Two-Factor, the verifier simply writes down the last successful OTP code. When a prover supplies an OTP, the verifier does two things:

1. Checks if the given code is valid for the given timestep
2. Checks if the given code is not the same as the previous successful OTP code

If both conditions pass then the user (prover) is valid and should be issued an authentication token.

The supplied code will never* match the previously stored value unless its two attempts in the same timestep (aka our replay attack).

*there is a tiny chance that a future timestep will produce the same code because of the pigeonhole principle. In which case the prover (user) will receive a false-positive error. Trying again in a T+1 timestep will resolve the issue. Because this probability is so slim (I think 1 in a million), it's considered "never to occur".

Patch/Workaround

Specifically to Devise-Two-Factor, the patch is here: https://github.com/tinfoil/devise-two-factor/commit/cb025fbd7fd257a057dd82de50aead7fbc987e8f

Applicable to Other Libraries

It is extremely likely Devise-Two-Factor is not the only library implementing TOTPs incorrectly, failing to guard replayed OTP codes. Checking other libraries in various languages would likely expose the same exploit.

Acknowledgements

Thanks to Viliam Holub for originally reporting the issue.

Header image is by Brent Moore under the Creative Commons license CC BY-NC 2.0.

TL;DR: If a public client respects the RFC 7009 spec and does not authenticate the revocation request, then Doorkeeper does not actually revoke the access token. Upgrade to version 4.1.1, 3.1.1, or 2.2.3

The Problem

Doorkeeper implements OAuth 2.0 access & refresh token revocation (RFC 7009) as of version 1.2.0.

The crux of the problem is, as per RFC 7009 spec, the revocation request MUST contain the parameter token and doesn't require authentication unless it's a confidential client (i.e. a JavaScript-powered Single Page App in the browser). However, Doorkeeper incorrectly implemented the spec and does not proceed unless it is an authenticated/authorized request. As a result Doorkeeper looks for access_token, bearer_token, or an Authorization request header via the Helpers::Controller#doorkeeper_token's delegation to OAuth::Token.

Furthermore, RFC 7009 makes no mention of supporting anything but providing the token parameter so all of the alternative methods for finding the access token via the helper fail to save the day (eg Authorization header's Basic or Bearer values).

Finally, by spec definition-- despite not finding a token to revoke–
Doorkeeper will respond with a 200 empty body. Now this on its own is fairly innocuous but likely "hid" this lack of revocation from developers-- Leaving them none the wiser. At least that was the case with me.

Why Authenticating is Pointless

As I stated before, simply knowing the access token implicitly verifies the request.

The access token is considered a secret which, if stolen via session hijacking, let's an attacker impersonate the user. In other words, the access token represents the trusted user.

Now if we're posting to the revocation endpoint, the idea of authenticating the request in the usual places or authorizing the token parameter matches the authentication is pointless.

If it doesn't match, an attacker can simply make their authentication match that of the token's value.

The very existence of token is sufficient to represent a trusted user and anything more is just fluff– It doesn't add any additional security.

Impact

All public, non-confidential clients respecting the RFC will not have their access or refresh tokens revoked when sending a valid, well-formed & unauthenticated revocation request to doorkeeper.

Any such clients relying on Doorkeeper's revocation functionality are susceptible to a session replay attack, even after the victim terminates their session via a revocation/log out.

1. Attacker gains access token via any acceptable means (MiTM, physical computer access, bug in client code, etc.)
2. Victim logs out/attempts to revoke the access token
3. Attacker is not affected, as the token is still valid for the duration of its lifespan. Furthermore, the refresh token can be used to extend the attacker's privileged access.

This scenario is captured under the OWASP Top 10 (2013)'s A2: Broken
Authentication and Session Management as a vulnerability.

Now obviously the attacker must already be able to obtain the access token, but without revocation the victim has a false sense of security & cannot limit damage to their account. Additionally, clients relying on the Doorkeeper revocation endpoint to revoke all other issued tokens on password change, password reset, etc. would also be impacted by this problem.

Solution

The true solution is to fully comply with the RFC 7009 and do not authenticate/authorize the request. This means removing reliance on #dookeeper_token and assert presence of the token directly, revoking it if it's present.

Patch/Workaround

See https://github.com/doorkeeper-gem/doorkeeper/commit/fb938051777a3c9cb071e96fc66458f8f615bd53

Header image is by Nick Harris under the Creative Commons license CC BY-ND 2.0

Update (May, 2017): AOSP has written a FORMAT.md document that is more up-to-date than this article. It will likely be the living document for detailing how animation works in Android. This article is kept for posterity.

So you're an Android wizz and want to further customize your wicked Android experience. You've perused the plethora of custom boot screen animations and nothing tickles your fancy, or you've installed a popular ROM like CyanogenMod and you're just not happy with it.

You've got your animation ready, you've exported it as a series of sequenctial PNGs, and you're ready to go!

Alas, what the #@$!&@ is the desc.txt used for? And why the many parts folders? This article seeks to answer that question.

Straight to the source

For the expertly technical, you can read the BootAnimation.cpp source code to see exactly how Android boot animations work. Because things change in major releases of Android, not all desc.txt files are created equal.

For example, did you know boot animations now support playing sound as of Android Lollipop (5.0–5.1.1)?

Basic Premise

Boot animations are a series of PNG images, loaded & displayed one after the other, to create the illusion of video. This is a smaller memory & CPU footprint than decoding an actual video file with codecs.

Some boot animations have intros, a main loop, and then an outro. This is what the part* folders & desc.txt allow. You don't have to have intros & outros, but it make for a much more polished effect. The above video example of CopperheadOS's boot animation (made by yours truly) is comprised of an intro, main loop, and outro.

You group your PNGs into folders and specify, for each part:

1. How many times the PNGs should loop before the next sequence plays
2. How long should the last frame pause before continuing
3. And if Android is allow to abort the animation early if the OS is fully loaded

Your .zip file (which cannot be compressed, it's meant to just be a blob!) should be laid out in the following fashion:

desc.txt  
part0/  
    0000.png
    0001.png
    0002.png
    ...
part1/  
    0000.png
    0001.png
    0002.png
    ...
...

You need a minimum of one part0 folder, containing your parts. It appears there's no programmed limit to how many PNGs per part, and how many parts in total. Note that because they're PNG images, you can easily have a very large boot animation. I recommend keeping it under 20MB.

Anatomy of a desc.txt file

Note what you can define here is limited by the version of Android. Not all versions support the c part type. That was introduced in Android Jelly Bean (4.1–4.3.1)

Our example desc.txt

700 420 30  
c 1 15 part0 000000  
c 0 0 part1 FF0000  
c 1 30 part2 0000FF  

Top line

[width] [height] [frames per second]

So in our above example:

• 700 is the width of the PNGs
• 420 is the height of the PNGs
• 30 is the frames per second. I've seen 60, 30, and 10 used here.

Subsequent lines

You want to define each part on its own line:

[type] [loop count] [pause] [path] [bg colour (optional)]

You can have transparent PNGs that will show a background colour but almost all animations I see have a matte, full black background in the PNGs and the optional colour section absent in the desc.txt.

Note: [type] with value c is only supported in Android Jelly Bean or later. It must be p for older Android versions.

Second Line (The Intro)

• c is the "type". If it is c and the OS has finished loading halfway through the sequence loop, then it will finish the loop & exit gracefully. If it is p then the animation will abort mid-sequence if the OS has loaded. Unless you have an older Android OS, you typically want c for a refined animation.
• 1 is the loop count. This means play once then proceed to the next sequence.
• 15 is the "pausing" in frames of the last frame in the sequence before going to the next sequence. So in this example it's pausing 0.5 seconds because 15 is half of 30
• part0 is the path to the collection of PNGs to use in this part
• 000000 is the background colour in hex. This value is full black and the default colour. You can define a desc.txt with this entry absent (and most do).

Third Line (The Main Loop)

• c is still used, because this is where the OS will eventually finish loading. We want a graceful exit to the outro.
• 0 is a special loop count. It means "loop forever". This part is where the OS will load and exit. Because we chose c it will gracefully exit to the end of the animation. If p was chosen, this is where the animation would abort & exit.
• 0 means no delay. Duh.
• part1 is the path to the collection of PNGs to use in this part
• FF0000 means a red background for this part

Fourth Line (The Outro)

• c is still used, because otherwise the outro would abort.
• 1 is used because, thanks to c, the outro sequence must play even if the OS has loaded; so we play it once. If you chose p for the outro but c for prior parts, it'd exit immediately without playing. If you chose 0 here, the boot animation would loop forever and never stop!
• 30 means pause a final second before showing the OS. Maybe your outro is fading to black so your final frame is a black screen.
• part2 is the path to the collection of PNGs to use in this part
• 0000FF means a blue background for this part

And there you have it!

I hope you found this useful. There's a lot of misinformation and incorrect forum posts out there detailing how to properly write a desc.txt file.

Feel free to leave a comment if you have any questions and I'll try to answer them to the best of my ability.

This posts's header is by Kham Tran. Used under CC BY 2.0.

TL;DR you can download the RL Grime screensaver I build here (Mac OS X only)

RL Grime's music video

For some reason my brain absolutely loves looping over this same song over and over again. It's called Core by RL Grime and the visuals are stunning. According to the YouTube description, the music video was directed by David Rudnick & Daniel Swan. Props to those two.

I extracted the above loop from the music video and, using HandBreak, converted the file to a H.264 video in a MP4 container.

Ok, so, I have this mesmerizing loop but how do I get it on my computer as a screensaver? Enter Quartz Composer.

XCode's Quartz Composer

Quartz Composer is a crazy simple way to process and render graphics on Mac and iOS. In the above screenshot, that's literally all I had to build for my screensaver.

Steps

1. Open Quartz Composer (requires XCode, a separate download for XCode 6.1)
2. File → New from Template, choose Screen Saver
3. Delete all nodes but the Clear, Billboard, and Resize Image if in Preview nodes
4. Drag and drop the video file in question into the editor's field, it should create a new node
5. Click the Image output on the Movie Importer node (the video node) and connect it to the Macro Patch's Image input
6. Done!

This is all you need to loop a video as a screensaver for Mac OS X. Simply Export the file and you're good to go!

Installing the Screen Saver

Take your exported Quartz Composer screen saver and plop it into ~/Library/Screen Savers. You can get there by pressing ⌘ + Shift + G while in Finder.

Next open up System Preferences → Desktop & Screen Saver, and you'll see your newly installed screen saver available from the list

Caveats

Note that the screen saver you created does not actually store the video, it only references it. You cannot delete or move the video file!

Personally I moved the video file into the Screen Savers folder and referenced it there.

If this post is greek to you, take a look at my Ember CLI and Content Security Policy (CSP) blog post.

Earlier this month, I had the opportunity to speak at the Toronto EmberJS Meetup, a monthly meeting at Pharmacy (pictured above), about Ember CLI and Content Security Policy. I assembled a demo application with a variety of of CSP errors, and walked through on how to fix each one in the application.

The app explained some elements of CSP, why things are the way they are, and how to configure your Ember CLI app. You can download the app here to interactively learn about CSP.

This posts's header is by Jesse Milns, from BlogTO. Used under CC BY-NC-ND 3.0.

As of Ember CLI v0.0.47 there is now built-in support for Content Security Policy in our apps!

WTF is a CSP?

It's a beautiful defence against XSS attacks. You simply send a HTTP header in server your response. A example policy would be:

Content-Security-Policy:
  default-src 'self';
  img-src     *;
  object-src  media1.example.com
              media2.example.com
              *.cdn.example.com;
  script-src  trustedscripts.example.com

Tada! You've locked down what type of resources are allowed to be loaded from where. When a user using a browser that supports CSP (and a lot of them do) visits your site, it will only load resources that have been whitelisted by your policy. If an attacker injects a persistent XSS into your app loading, say, http://evildomain.com/keylogger.js it will fail because it's not coming from trustedscripts.example.com or your domain.

Why should I care?

Well, the Ember CLI maintainers believe that security should be consciously in the mind of web developers. I agree. We should be responsible for building secure-by-default apps and not patch after the fact.

Having CSP in Ember increases your understanding of how an attacker could harm your users or compromise your app.

Won't this break my app?

Nope! For now they have it as "Report Only" which means when in a dev environment your console will fill up with all violations of the policy so you can patch your backend or Handlebars template.

Ok, how do I use it?

TL;DR: you need to modify your server config that sends your Ember app to respond with the Content Security Policy headers.

I suggest you do your homework, though. Content Security Policy is a powerful beast. You can read up on all of the directives available to you here: http://content-security-policy.com/. And how to configure your Ember app: ember-cli-content-security-policy.

Or, if you don't like reading, here's a talk on CSP (not Ember-related):

In an effort to not write information on the internet that will ultimately get rusty (this is especially true for Ember posts!), I suggest you read the Ember CLI docs on CSP for more information:

http://www.ember-cli.com/#content-security-policy

This posts's header is by Pekka Nikrus, titled Embers. Used under CC BY-NC-SA 2.0.

I had the opportunity to help my employer, FreshBooks, implement a responsible disclosure policy. As it turns out, it's very difficult to offer a PGP key while maintaining trust, security, and convenience.

In this post I hope to outline the struggles, the roadblocks, and practical strategy surrounding PGP key management for a ~100 person company.

The Tweet that Started it All

I'd love to know what % of vulns reported to big tech companies are encrypted with PGP vs. plaintext email. Please publish stats.

— Christopher Soghoian (@csoghoian) February 10, 2014

It all started with the above tweet. One of my favourite security-conscious people I follow was complaining about the piss-poor state of secure responsible disclosure pages that vendors offer. It got me to thinking, "Gee whiz, does FreshBooks even have a responsible disclosure policy?" Not surprisingly the answer was no.

I decided that with FreshBooks growing bigger and more important every quarter, we owe it to our users to explicitly provide a mechanism of disclosure that researchers will be comfortable with. The more acceptable we are, the more likely they are to disclose vulnerabilities or exploits to us.

If we were going to do this, we were going to do it right. That means no plaintext pages, no insecure email communications, and no lack of common mechanisms that security researchers expect.

Actual response from tech company's security team: "PGP email doesn't play well with Zendesk so I don't want to encourage it unless needed."

— Christopher Soghoian (@csoghoian) February 11, 2014

I don't want FreshBooks to be like that. We are going about this properly if we're going to do it at all.

The Policy

The page itself is a simple one.

Like most software companies, we explicitly state what we do & don't allow, how to go about it, where to report the vulnerability, and how they'd like their attribution (if at all).

The key components are:

• How to report an issue
• Permitted research: what's allowed and what's not (for example, banning Denial of Service testing)
• Rewards (if applicable)
• Researcher attribution

The initial idea was to offer a general security inbox security@freshbooks.com with a PGP key with fingerprint offered on the website and available on PGP key servers. If we were to do this right, it's quite a non-trivial option when the number of recipients for security@ is greater than one.

The PGP Encryption & Trust Strategy

@csoghoian for our submissions (http://t.co/lHgxfay3nS), two in the last two years, out of maybe 100 emails. They were the two worst though

— Michael Koziarski (@nzkoz) February 10, 2014

Since we deal in customer financial data, I'd hope that any critical vulnerability gets to us securely. That means creating a strategy that people use… Both internally and externally. There's no use in designing a Fort Knox of a system if your co-workers won't bother to use it!

Above: Sketching out some of the PGP key ideas for the managers briefing.

There are a lot of ways to skin this cat, and I spent some time musing over the best options. Our systems administrator wanted to enforce that when a security team member leaves the company that we have a way to revoke their access. With a shared PGP keypair for a security@ mailbox, that's pretty hard to do.

The question is: when a team member departs the company, what prevents them from being malicious with the PGP key? They carry the trust and brand of FreshBooks Security Team <security@freshbooks.com>. Even if you had a revocation certificate handy, the departed could give away the PGP keypair to your competitor in way that you don't know about for months or years!

✗ Option 1: Shared key only

This is the most naïve implementation.

There is a single PGP key for the "FreshBooks Security Team" <security@freshbooks.com> that a researcher encrypt emails to & receive signed correspondence from.

All team members have a copy of the keypair on their workstations and all members have access to the security@ mailbox.

Advantages:

1. Single point of contact for security researcher.
2. Anyone on the team can decrypt and respond; potentially faster turnaround time.
3. All correspondence can be encrypted and signed.

Disadvantages:

1. No web of trust for the security researcher to trust the key.
2. Risk of a fired, rogue employee secretly copying the private key before their departure and maliciously signing and/or decrypting messages.

✗ Option 2: Individual keys only

So it's the same physical setup as before but instead of a single PGP key available for security@freshbooks.com we publicly list a team of security officers all with their individuals keys (all of which are intersigned with one-another) and ask the researcher to multi-recipient encrypt their message. Further communication will happen on a per-individual basis.

Advantages:

1. Web of Trust is (somewhat) maintained with the use of key servers and inter-personal key signing
2. Revocation of key signatures strongly mitigates risk of a fired, rogue employee secretly copying their private key before their departure and maliciously signing and/or decrypting messages.
3. All correspondence can be encrypted and signed.

Disadvantages:

1. Many points of contact for security researcher. They have to choose who to send the report to or encrypt the same message for every recipient of security@freshbooks.com.
2. Web page must be maintained with the member list of security@freshbooks.com (cumbersome)
3. There's no concept of trust from security@freshbooks.com saying it trusts these individuals.

✓ Option 3: Shared key for receiving & individual keys for continued correspondence

Step 1:

Security researcher obtains a copy of our public key and sends an encrypted email to security@freshbooks.com

Step 2:

The encrypted email received by Team Lead, Alice, and Bob's inboxes. Since it's encrypted for security@freshbooks.com, Alice and Bob cannot read the email.

Step 3:

Team Lead, being the only owner of the 0x00DEADBEEF <security@freshbooks.com> PGP key, decrypts the message and forwards it, decrypted (or re-encrypted?), to the rest of the team. If the team lead is on vacation or away, have one of the team members respond to the email (signing their response with their personal key) saying that they'll get back to them ASAP once the employee with access to the security@freshbooks.com private key returns.

Step 4:

After the team meets, someone is assigned as the liaison or point of further contact between the team and the researcher. That team member continues to communicate with the researcher signing with their PGP key. That team member is responsible for keeping the rest of the team up-to-date.

When A Team Member Departs:

When a team member leaves the company they revoke their PGP key. In addition, the security@freshbooks.com key and other team members' keys revoke their signature against the departed's key. The keys are then exported and re-sent to the key servers, updating the trust model to exclude the departed team member.

This conveys to a researcher that the departed team member is to no longer be trusted. Any attempt by a departed team member to perform rogue actions (such as impersonation of the security team, selling their key to a competitor) will be thwarted by the trust model.

When The Team Lead Departs:

Similar to the above model but, in addition, the security@freshbooks.com key will also be revoked and re-generated to which a new Team Lead will own. Prior to revocation the old key will sign the new key and vice-versa showing that the newly generated key carries the trust of the old one. All team members will sign the new key and revoke their signatures on the old.
The public website's Responsible Disclosure policy page should be updated to point to the newly generate security@freshbooks.com key.

Advantages:

1. Web of Trust is maintained with the use of key servers and inter-personal key signing
2. Risk of a fired, rogue employee secretly copying the private key before their departure and maliciously signing and/or decrypting messages is strongly mitigated unless Team Lead becomes evil.
3. All correspondence can be encrypted and signed.

Disadvantages:

1. Potentially slower turnaround time for decrypting messages
2. Team Lead is a single point of failure
3. Main key revocation is tied with the departure of the Team Lead.
4. Each email message has to be relayed to the rest of the team.

The Practical Pushback

This is obviously a fairly complicated structure, and many companies don't bother going through with the effort of implementing proper PGP key management. It's usually the big guns who have dedicated security departments who implement this mess.

Our head of Operations, upon being presented with this strategy, asked about encrypted web forms.

It's not a completely crazy to not offer emails with PGP and just opt for a web form. GitHub does it, after all and it appears there's a move to adopt forms:

If you have a dedicated path for security researchers to report vulns in your products, please make it a HTTPS form, not an email address.

— Christopher Soghoian (@csoghoian) February 12, 2014

My question, at this point, is now twofold:

1. When we get the report, how do we continue secure communication?
2. Using a web form could have unintended side-effects such as logging and caching somewhere along the line.

For now we're offering an encrypted web form and a single PGP security@freshbooks.com key that the head of Operations has access to. The web form, under the hood, sends an email to security team which is secured under STARTTLS.

In the next year, we'll move to the full PGP management structure outlined in Option 3.

The PGP Key Generation

So far, I've only described our management strategy when people join and leave the company. The are many ways to go about key generation and storage. Below is more-or-less our plan:

• All keys should be 4096-bit RSA (sign) & RSA (encrypt) that expire every 5 years
• Generate a key revocation file for the main key and store it on hard media, such as archival CD-ROM
• Back up the main keypair's private key on archival media and securely store medium.
• Randomly generate the passphrases using Diceware or similarly entropic, but human memorable, strategy
• Encourage use of signing keys internally within the company, publishing the signed keys to a key server.
• The private keys should only live on the workstations of the owners of said keys (which are protected behind Active Directory)

The State of The Union

At the time of this writing, most levels of management have approved my proposal and Responsible Disclosure policy draft. We're in the process of finalizing the team, defining an explicit response protocol (such as promising an initial response within 24 hours!), and defining internal changes that need to happen. The internal policy strives to conform to the RFPolicy v2.

It's exciting to see that with my persistence that FreshBooks realizes the importance of such a project.

I expect to see the policy and protocol live and ready to go in the near future.

Update!

The responsible disclosure policy is live and so far we've had two disclosures!

This post's header is by Brian Klug, titled Anonymous Hacker. Used under CC BY-NC 2.0.