Warning your users about a vulnerability

Somebody just told you about a vulnerability in your code. Moreover, they published a paper about it. Even worse, people have been very vocal about it.
What can you do now? The usual (and natural) reaction is to downplay the vulnerability, and try to keep it confidential. After all, publishing a vuln will make your users unsafe, and it is bad publicity for your project, right?


The best course of action is to communicate a lot. Here’s why:

Communicate with the security researcher

Yes, I know, we security people tend to be harsh, quickly flagging a vulnerable project as “broken”, “dangerous for your customers” or even “EPIC FAIL“. That is, unfortunately, part of the folklore. But behind that, security researchers are often happy to help you fix the problem, so take advantage of that!

If you try to silence the researcher, you will not get any more bug reports, but your software will still be vulnerable. Worse, someone else will undoubtedly find the vulnerability, and may sell it to governments and/or criminals.

Vulnerabilities are inevitable, like bugs. Even if you’re very careful, people will still find ways to break your software. Be humble and accept them, they’re one of the costs of writing software. The only thing that should be on your mind when you receive a security report is protecting your users. The rest is just ego and fear of failure.

So, be open, talk to security researchers, and make it easy for them to contact you (tips: create a page dedicated to security on your website, and provide a specific email for that).

Damage control of a public vulnerability

What do you do when you discover the weakness on the news/twitter/whatever?

Communicate. Now.

Contact the researchers, contact the journalists writing about it, the users whining about the issue, write on your blog, on twitter, on facebook, on IRC, and tell them this: “we know about the issue, we’re looking into it, we’re doing everything we can to fix it, and we’ll update you as soon as it’s fixed“.

This will buy you a few hours or days to fix the issue. You can’t say anything else, because you probably don’t know enough about the problem to formulate the right opinion. What you should not say:

  • “we’ve seen no report of this exploited in the wild”, yet
  • “as far as we know, the bug is not exploitable”, but soon it will be
  • “the issue happens on a test server, not in production” = “we assume that the researcher didn’t also test on prod servers”
  • “no worries, there’s a warning on our website telling that it’s beta software”. Beta means people are using it.

Anything you could say in the few days you got might harm your project. Take it as an opportunity to cool your head, work on the vulnerability, test regressions, find other mitigations, and plan the new release.

Once it is done, publish the security report:

Warning your users

So, now, you fixed the vulnerability. You have to tell your users about it. As time passes, more and more people will learn about the issue, so they might as well get it from you.

You should have a specific webpage for security issues. You may fear that criminals might use it to attack your software or website. Don’t worry, they don’t need it, they have other ways to know about software weaknesses. This webpage is for your users. It has multiple purposes:

  • showing that you handle security issues
  • telling which versions someone should not use
  • explaining how to fix some vulnerabilities if people cannot update

For each vulnerability, here is what you should display:

  • the title (probably chosen by the researcher)
  • the security researcher’s name
  • the CVE identifier
  • the chain of events:
    • day of report
    • dates of back and forth emails with the researcher
    • day of fix
    • day of release (for software)
    • day of deploy (for web apps)
  • the affected versions (for software, not web apps)
  • the affected components (maybe the issue only concerns specific parts of a library)
  • how it can be exploited. You don’t need to get into the details of the exploit.
  • The target of the exploit. Be very exhaustive about the consequences. Does the attacker get access to my contacts list? Can he run code on my computer? etc.
  • The mitigations. Telling to update to the latest version is not enough. Some users will not update right away, because they have their own constraints. Maybe they have a huge user base and can’t update quickly. Maybe they rely on an old feature removed in the latest version. Maybe their users refuse to update because it could introduce regressions. What you should tell:
    • which version is safe (new versions with the fix, but also old versions if the issue was introduced recently)
    • if it’s open source, which commit introduced the fix. That way, people managing their own internal versions of software can fix it quickly
    • how to fix the issue without updating (example for a recent Skype bug). You can provide a quick fix, that will buy time for sysadmins and downstream developers to test, fix and deploy the new version.

Now that you have a good security report, contact again the security researchers, journalists and users, provide them with the report, and emphasize what users risked, and how they can fix it. You can now comment publicly about the issue, make a blog post, send emails to your users to tell them how much you worked to protect them. And don’t forget the consecrated formule: “we take security very seriously and have taken measures to prevent this issue from happening ever again”.

Do you need help fixing your vulnerabilities? Feel free to contact me!

Worst Case Messaging Protocol

We already have lots of tools to communicate safely, and in some cases, anonymously. These tools work well for their purpose, but spying and law enforcement tools have also improved.

People are forced to decrypt their hard drives in airports. Rootkits are developed by police forces. DPI systems are installed on a country level. Using the graph of who communicates with whom, it is possible to map the whole hierarchy of an organisation, even if all communications are encrypted. How can we defend against that?

I believe that the analysis of organisations is one of the biggest threats right now. The ability to recognize an organization is the ability to destroy it by seizing a few members. That may be useful against terrorists, but these tools are too powerful, and they may be used by the wrong hands. Terrorists already know how to defend against such systems, but what of common people? Any company, association or union could be broken anytime.

I think we need tools to mount resilient organizations. A compromised node shouldn’t bring down the whole system. Intercepted messages shouldn’t give too much information on the different parties. People can still find ways to send their messages safely (PGP, dead drops, giving USB keys hand to hand), but we need a framework to build decentralized human systems.

Here is the solution I propose: a messaging protocol designed to protect identities and route around interception. This protocol is designed to work in the worst case (hence its name), when any communication could be intercepted, and even when we can only use offline communication.

Every message is encrypted, signed and nearly anonymized (if you already know the emitter or receiver, you can recognize their presence, but this can be mitigated). To introduce redundant routes in the network, a simple broadcast is used (the protocol is not designed for IP networks, but for human networks, with limited P2P communication). Any node can be used to transmit all the messages. The fundamental idea is that if you’re compromised, the whole organization can still work safely without you.



  • Every communication can be intercepted
  • if a node is compromised, every message it can read or write is compromised
  • People can still create a P2P (IRL) network to communicate (aka giving an USB key to someone else)


  • Confidentiality
  • Anonymity
  • Authentication
  • Deniability? (I am just a messenger)
  • Untraceability
  • Can work offline (worst case)

For this protocol, we need a RNG, a HMAC function, a symmetric cipher and an asymmetric cipher. I have not yet decided what algorithms must be used. They could be specified in the message format, to permit future changes in algorithms.

Message format

  • nonce1
  • HMAC( sender’s public key, nonce1 )
  • expiration date
  • symcrypt( symmetric key, message )
  • nonce2
  • For each receiver:
    • asymcrypt( receiver1’s public key, symmetric key )
    • HMAC( receiver1’s public key, nonce2 )
    • asymcrypt( receiver2’s public key, symmetric key )
    • HMAC( receiver2’s public key, nonce2 )
  • asymsign( sender’s private key, whole message )

Here is how it works:
An identity is represented by one or more public keys (you can have a different public key for each of your contacts, it makes messages difficult to link to one person). They are not publicly linked to a name or email address, but the software layer could handle the complexity with a good enough UI. I do not cover key exchange: users must design their own way to meet or establish communications.

Every user is a hub: all messages are broadcasted by all users. To prevent data explosion, expiration dates are used. Users recognize the message they receive and the identity of the emitter, using the HMAC of the public keys. All communication are encrypted, but I use the convergent encryption ideas to have multirecipient messages.

Handling the messages


  • verify if one of my public keys is in the receivers by calculating the HMAC with nonce2
  • validate the signature (if I already know the emitter’s public key)
  • decrypt the symmetric key that was encrypted with my public key
  • decrypt the message

Creating messages

  • write the message
  • choose the emitter’s identity and public key
  • choose the receivers and the public keys used
  • choose an expiration date
  • generate two random nonces
  • generate a symmetric key
  • insert nonce 1 and the HMAC of nonce 1 and my key
  • insert the expiration date
  • encrypt the message with the symmetric key and insert it
  • insert nonce 2
  • for each receiver:
    • encrypt the symmetric key with the receiver’s public key and insert the result
    • insert the HMAC of nonce 2 and the receiver’s public key
  • sign the whole message with my private key and append the signature

Sending messages

  • Take all the messages you received
  • filter them according to some rules:
    • remove expired messages
    • remove messages too large?
    • etc
  • add your messages to the list
  • give the message list to the next node in the network

This protocol is voluntarily simple and extensible. New techniques can be devised based on this protocol, like dummy receivers in a message or dummy messages to complicate analysis. It is independent of the type of data transmitted, so any type of client could use this protocol (it is at the same level as IP). Most of the logic will be in the client and the contact manager, to present an interface easy to use.

I truly hope we will never need this to communicate, but recent events have convinced me that I need to release it, just in case.

I am open to any critique or suggestion about this protocol. I will soon open a repository to host some code implementing it, and it will of course be open to contributions 🙂

Manage your libraries with symlinks on Windows

My Windows development environment is a bit complex. I work on multiple projects, at multiple versions, with different compiler environments, and with dependencies on different libraries and versions of these libraries.

Now, how do I specify where the compiler must search the libraries, and which version to use? Most of the time, I will add it directly in the project configuration. Easy at first, but quickly,I find myself writing by hand the path to each library (and header) in each project and each configuration of this project. And then, writing by hand the different names of the libraries (mylibrary.lib, mylibraryd.lib, mylibrary-static.lib, mylibrary-MTD.lib, etc).

And when I want to update to a new version of the library? If I’m lucky, I just have to change the library and header paths (in every project using the library). If not, I also have to change the name, because of the library developer’s convention.

The first solution to these problems was to use a batch file to launch Visual Studio and MSYS, and set some environment variables in this file. I quickly ended up with one big file containing two environment variables (include path and lib path) per library, possibly more if there were some big changes in the library names. My Visual Studio configuration was cluttered with $(MYLIBRARY_LIBPATH), $(MYLIBRARY_INCLUDEPATH), $(MYLIBRARY_NAME). It is unreadable, and again, impossible to maintain.

My solution comes from the Unix world, where you have a correct organization for your development files:

  • one folder containing the subfolders include, bin and lib
  • library names including version, and a symlink (without the version number) to the latest version of the lib

Can I do that on Windows? YES \o/

Here is the trick: normal links on Windows won’t work, but the mklink tool can create symlinks. And Visual Studio will recognize those as files and folders while looking for libraries.

Now, how would I organize my development environment? I chose to use (and abuse) symlinks, to create include, lib and bin folders for each project and configuration, and use generic names for the libraries.

  • I create a folder containing include, lib and bin
  • in the  include/ folder, I put symlinks to the header file or the subfolder for each library I will use in that project
  • in the lib directory, I create symlinks to the library version I want, one symlink per static/dynamic, MT/MD, Debug/Release version. But I could create one lib folder per static/dynamic, etc. A bit complex, but feasible (most of the time, I use only debug and release version, so it’s still manageable).

With this setup, I only set the INCLUDE and LIB environment variables, and I use directly the library names I need.

Here is an example script I use to create different library folders for x86 and x64 libs:

echo "Building include and library directories for Windows %PLATFORM%"

@mkdir %PLATFORM%
@mkdir %PLATFORM%\include
@mkdir %PLATFORM%\lib

@mklink /D %PLATFORM%\include\boost %BOOST%\boost
@for %%i in (%BOOST%\lib\*.lib) do (mklink %PLATFORM%\lib\%%~ni.lib %%~fi)

@mklink /D %PLATFORM%\include\cpptest %CPPTEST%\include\cpptest
@for %%i in (%CPPTEST%\lib\*.lib) do (mklink %PLATFORM%\lib\%%~ni.lib %%~fi)

I set up the BOOST and CPPTEST environment variables in another file. Then, I launch Visual Studio from another script which includes it.

There may be better ways, and that system will evolve in the future, but I’m pretty comfortable with it right now 🙂

Depending on my needs, I may grab from the bottom of my disk the package manager I wrote back in school, and make a big solution to download, build and link libs and personal projects. But later, I have some procrastination planned right now.

Rails and oauth-plugin part 2: the consumer

In the previous post, I showed how you could build a provider with oauth-plugin and Rails. Now, I will demonstrate how to build a consumer (it’s a lot easier).

I will assume that your provider is already running on localhost:3000. The consumer will run on localhost:4000 (run it with “rails server -p 4000”).

Here we go!

rails new consumer
cd consumer

Put this in your Gemfile:

source 'http://rubygems.org'
gem 'rails', '3.0.7'
gem 'sqlite3'
gem 'devise'
gem "oauth-plugin", ">= 0.4.0.pre1"

And run these commands:

bundle install
rails generate devise:install
rails generate devise User
rake db:migrate
rails generate controller welcome index
rm public/index.html

And here is your routes.rb:

Provider::Application.routes.draw do
devise_for :users
root :to => "welcome#index"

Create the consumer

rails generate oauth_consumer user
rake db:migrate

in app/controllers/oauth_consumers_controller.rb, replace:

before_filter :login_required, :only=>:index


before_filter :authenticate_user!, :only=>:index

Uncomment the methods for devise (go_back, logged_in? currentuser=, deny_access!) in app/controllers/oauth_consumers_controller.rb.

Add to app/models/user.rb:

 has_one  :test, :class_name=>"TestToken", :dependent=>:destroy

Now go to http://localhost:3000/oauth_clients/ to register your first application with these parameters:

Name:                 Test consumer
Main Application URL: http://localhost:4000/
Callback URL:         http://localhost:4000/oauth_consumers/test/callback

You’re redirected to http://localhost:3000/oauth_clients/1. It shows:

Consumer Key:      CRcIJ15MwSqlDTxsH8MpO3En4wjaOxkqeofLioH4

Consumer Secret:   C7uci8xkyMShCf4SNXWPclKbBo3ml1Zf2W2XWu4W

Request Token URL: http://localhost:3000/oauth/request_token

Access Token URL:  http://localhost:3000/oauth/access_token

Authorize URL:     http://localhost:3000/oauth/authorize

Now, you need to put the key and secret in config/initializers/oauth_consumers.rb:

:test =>{
:key => "CRcIJ15MwSqlDTxsH8MpO3En4wjaOxkqeofLioH4",
     :secret => "C7uci8xkyMShCf4SNXWPclKbBo3ml1Zf2W2XWu4W",
     :expose => true

Create app/models/test_token.rb. This model will store the token for your provider. If you want to provide helpful methods, take inspiration from lib/oauth/models/consumers/services/.

class TestToken < ConsumerToken
:site => "http://localhost:3000",
:request_token_path => "/oauth/request_token",
:access_token_path => "/oauth/access_token",
:authorize_path => "/oauth/authorize"

def self.consumer(options={})
@consumer ||= OAuth::Consumer.new(credentials[:key], credentials[:secret], TEST_SETTINGS.merge(options))


You should now be able to use the URLs “/oauth_consumers/test/client/”, “/oauth_consumers/test/callback”, “/oauth_consumers/test/callback2″,” /oauth_consumers/test/edit”,
and “/oauth_consumers/test”.

Modify the welcome controller t get the provider data:

 class WelcomeController < ApplicationController
 def index
 # cf http://oauth.rubyforge.org/rdoc/classes/OAuth/AccessToken.html
 @consumer_tokens=TestToken.all :conditions=>{:user_id=>current_user.id}
 @token = @consumer_tokens.first.client
 logger.info "private data: "+@token.get("/data/index").body


To connect a user to an external service link or redirect them to:


Where SERVICE_NAME is the name you set in the OAUTH_CREDENTIALS hash. This will request the request token and redirect the user to the services authorization screen. When the user accepts the get redirected back to:


That’s it

This tutorial is really short, and could be explained a bit more, but I’ll leave that for another post. You have enough to start tinkering with OAuth. Have fun!

Rails and oauth-plugin part 1: the provider

These days, I have been playing a lot with Oauth and its RoR implementation, oauth-plugin. Its documentation is a bit short, so here is a tutorial to show how to use it, both in provider and consumer mode. And we will even make them communicate with each other.

We will now build an Oauth provider using oauth-plugin for authorization and Devise for authentication. And we will add a controller protected by Oauth.

Starting up

A few instructions to create the application. You won’t need an explanation for this:

rails new provider
cd provider

Put this in your Gemfile:

source 'http://rubygems.org'
gem 'rails', '3.0.7'
gem 'sqlite3'
gem 'devise'
gem "oauth-plugin", ">= 0.4.0.pre1"

And a few more commands:

bundle install
rails generate devise:install
rails generate devise User
rake db:migrate
rails generate controller welcome index
rm public/index.html

And don’t forget ‘root :to => “welcome#index”‘ in config/routes.rb.

Create the provider

rails generate oauth_provider oauth

rake db:migrate

You could put something else than “oauth” as parameter, but for the moment, the generator has some bugs (it always generate the class OauthController, but with a different name). I’ll check more recent versions of the code.

Now, modify config/application.rb and add:

require 'oauth/rack/oauth_filter'
config.middleware.use OAuth::Rack::OAuthFilter

Put in app/models/user.rb:

has_many :client_applications

has_many :tokens, :class_name=>"OauthToken",:order=>"authorized_at desc",:include=>[:client_application]

Put in app/controllers/oauth_controller.rb:

alias :logged_in? :user_signed_in?

alias :login_required :authenticate_user!

and uncomment authenticate_user.

Put in app/controllers/oauth_clients_controller.rb:

alias :login_required :authenticate_user!

And now some data

Create a new controller:

rails generate controller data index

And now, edit your controller:

class DataController < ApplicationController
  before_filter :oauth_required

  def index
    @data = { "coincoin" => "o< o<" }

    respond_to do |format|
      format.json { render :json => @data }



I discovered a few bugs in this tutorial, so here are the fixes.

oauth-plugin needs the function current_user=, so add this to your ApplicationController:

def current_user=(user)
  current_user = user

Next, to handle revocation, you need to add this to config/routes.rb:

post 'oauth/revoke'

And at last, you need to fix the rack filter. The current code doesn’t verify the token validity, and lets revoked tokens access your data.
You have to modify lib/oauth/rack/oauth_filter.rb in the oauth-plugin gem folder.
Replace the line 46:

oauth_token = client_application.tokens.first(:conditions=>{:token => request_proxy.token})


oauth_token = ClientApplication.find_token(request_proxy.token)

And that’s it!

You now have a working provider. OauthController handles all the communication with the consumers. OauthClientsController manages the registration of new consumers. They both have customizable views: oauth for the authorization part (for users) and oauth clients for the consumers. And you just need the oauth_required filter to manage access to your data.

And now, you can go to /users/sign_up, then /users/sign_in, then /oauth_clients to register a new client application. You just need to give a name for your application, your URL, and a callback URL.

In the next post, we will build a consumer, and this consumer will access the provider’s data.

Yet another authentication scheme

Recently, I was asked to design a new authentication protocol for a web service. I know that I shouldn’t do reinvent the wheel, so I immediatly proposed OAUTH. It turns out that it can’t be used in this situation. Here are the constraints:

-calls to the webservice must be authenticated: I can keep the tokens and signature from OAUTH here. The problem is: how do I get that token?

-calls are made from devices or applications without access to a webbrowser (embedded devices, phones, etc.). The redirection dance of OAUTH is not acceptable here

-communications are done over an untrusted network, without SSL.

-I can’t use application keys and secrets to encrypt and sign the authentication process: clients include open source software and smartphone applications. You can’t hide a secret key in these.

-the protocol has to be simple to implement, on a lot of languages

-the server must not store the password in cleartext (I shouldn’t have to precise this…), the client must not store the password

Summing it up: no preshared keys, no browser, no SSL, untrusted networks, no passwords stored, and an OAUTH-like environment once the client is authenticated (tokens, authorizations, revoking, etc)

Apparently, I should just give up. But I like to play, so I’ll try!

First, I must say that I am not an expert in security nor cryptography. But I’m really enthusiastic about these subjects, and my day job is at a company providing strong authentication solutions (no, this protocol is not related to my day job). So, I know a bit about the subject, and I know that I should ask for reviews, hence this post.

Rough ideas

We need a safe communication over an untrusted network. TLS immediatly comes to mind, but the targeted applications might not have access to a TLS implementation. I’d like to use SRP, but I don’t think I’m able to implement it correctly (and it has to be SIMPLE). Using Diffie-Hellman to establish a shared key is another idea, but it is not safe against MITM.

Here’s my idea: we don’t need to generate a shared secret, we already have it. It’s the password!

But how can I use the password if the server doesn’t store it in cleartext?

The trick: key derivation functions

Decveoplers are finally understanding that they should not use MD5 nor SHA1 to store their passwords, even with a salt, because computing power is so cheap these days that anyone could crack easily a lot of passwords.

It is now recommended to use other functrions tro store passwords. The key derivation functions are a class of functions that create a key from a password. Basically, they do it by interating a lot of times. That makes them very slow, which is an interesting property if you want to stpre passwords: it is too expensive to “crack” the password. PBKDF2, bcrypt and scrypt are well known key derivation functions. They’re simple to use and available in a lot of languages.

With these functions, I can safely store the passwords, and generate a key shared with the client.

In short: if I store kdf(password, N) with N the number of iterations, I can send any M > N to the client and ask him to compute the key, without compromising what I store.

Designing the protocol

Now that we have a way to use a shared key, we can look at what will go over the wire to establish it. If I use directly kdf(pass, M), anybody getting access to the client storage will be able to obtain the key for any L > M. So, the key establishment has to use a nonce. That way, the client will only use the password once and forget it, and store the derivated key.

I would rather use a truly random key that has no relation with the password. It could be given to the client, encrypted with the derivated key. The derivated key could then be thrown away. But I still do not know if it is really necesary.

The server still needs to authenticate the client. The client will make a second call to the web service, signing it with HMAC and the key.

That’s it! It is really simple, so if there are flaws I did not see, you will surely catch them.


The protocol is based on key derivation functions, like PBKDF or bcrypt.

  • The server stores login and H = kdf(pass, N), with N integer
  • The client wants to authenticate and makes a call to the server with the login as argument
  • The server replies with M > N and i nonce
  • The client calculates k1 = kdf(kdf(pass, M)+i, 1)
  • The server calculates k2 = kdf(kdf(H, M-N)+i, 1)
  • The client calls the server with args “user=login&sign=”.HMAC(“user=login”, k2)
  • If k1=k2. The signature matches and the client is authenticated.