Posts tagged with ‘security’

Securely using passwords with R

kinow @ Jun 03, 2017 20:21:39

It is quite common to have code that needs to interact with another system, database, or third party application, and need to use some sort of credentials to securely communicate.

Most of the code I wrote in R, or reviewed, had normally no borders (from a system analysis perspective) with other systems, or basically just interacted with the file system to retrieve NetCDF or JSON files.

However, after I saw a comment in Reddit [1] some time ago about this, I decided to check what others used. With R Shiny becoming more popular, and moving more R code to the web, I think this will become a common requirement for R code.

There is a blog post from RevolutionAnalytics [2] that does a nice summary of the options for that. The post is from 2015, but I do not think much changed now in 2017. From the blog post and comments, there are seven methods listed:

  1. Put credentials in your source code
  2. Put credentials in a file in your project, but do not share this file (#3, #4, and #5 are similar to this one)
  3. Put credentials in a .Rprofile file
  4. Put credentials in a .Renviron file
  5. Put credentials in a JSON or YAML file
  6. Put credentials in a secure store that you can access from R
  7. Ask the user for the credentials when the script is executed (possibly not useful for R Shiny applications)

My preferred way for R is the .Renviron (or a dotEnv) file. You basically store your password in this file, make sure you do not share this (a global gitignore could be helpful to prevent any accident) and read the variables when you start your code.

## Secrets

If you would like to increase the security, you can combine it with a variation of #6. You use a .Renviron file, and use an encryption service like Amazon KMS (KMS stands for Key Management Service).

With AWS KMS in R, you can encrypt your values, put them encrypted in your .Renviron, and even if someone gets hold of your .Renviron file, you have an extra layer of protection, as the attacker would require access to your cloud environment to decrypt it too.

## Secrets


♥ Open Source

Using AWS MFA without a mobile phone

kinow @ Feb 28, 2017 00:47:03

If you use AWS, the chances are that you use MFA - Multi-factor Authentication - to authenticate. I don’t like to install apps in my mobile phone, unless I need to, so having bought a new phone recently, I decided to find a replacement for Google Authenticator.

There are several command line utilities, browser extensions, libraries, and tools (free and paid) that implement the TOTP - time-based one-time password -, the standard required by Amazon for MFA authentication.

I decided to use a Go tool for the first time: gauth. Note that you won’t be able to use it from home, in case you don’t bring your laptop home. You can have one MFA device linked to your AWS account, so you may have to remove an existing one. Follow these instructions with care :^)

Install Go

sudo apt update && sudo apt upgrade -y
cd tmp/ && wget
tar -zxvf go1.*.tar.gz
sudo mv go /usr/local
vim ~/.bashrc

Add the following at the bottom of the file.


And you can test it with . ~/.bashrc && go version.

Install gauth

Given your environment is correctly set up, you should be able to use the following command to install gauth, and have it available in your $PATH.

go get

Edit ~/.config/gauth.csv adding a value for the AWS MFA key.

Getting the AWS MFA key

To get the value that you must place in your gauth.csv file, you must add a new MFA device. When asked to scan a QR code, look for an option to enter the manual value. That will give you a long string. That’s the value you are looking for.

Extra: Auto copy-paste from command line

If you would like to quickly copy and paste, try creating an alias as described on this gist.

I used these instructions, and can now run one command line, that will put the next MFA code in my clipboard. Then just paste into my browser, and that’s that!

Happy hacking!


Learning afl and testing MapServer

kinow @ Feb 27, 2016 23:21:03

afl is a fuzzer, an application that combines a series of algorithms in order to try invoking programs with several different input values. It then analyses the application execution flow given different test case scenarios. You can read more about fuzzing at this OWASP page, or in other blogs that I also used while learning about afl 1 2

At work we are using MapServer for serving WFS and WMS. And I am using it for the NZ OpenStreetMap maps too. MapServer is written in C++ and is normally exposed as a CGI script, so I thought it was worth learning about afl and trying it on MapServer, as in case it finds any interesting bug I can submit it to the MapServer project.

( Read more … )

How does the Jenkins Credentials Plug-in store passwords?

kinow @ Sep 07, 2015 01:25:03

Jenkins Credentials Plug-in manages credentials stored in Jenkins. These credentials can be used in many jobs and by plug-ins for executing SSH commands, authenticating to systems, or running other commands that need some sort of authentication or authorisation.

I recently used its API for the first time in the BioUno figshare Plug-in to store OAuth 1.0 credentials (consumer key, consumer secret, token key, token secret). This blog post has more details about how we used the plug-in, but this post is specifically on how the passwords are stored by Jenkins.

Secret and ciphers

Jenkins stores its configuration on disk as XML using the XStream library. Plug-in developers using the Credentials Plug-in API must use the Secret class to encrypt sensitive information.

The Secret.fromString method is responsible for creating a cipher from a given String. As in the Secret Javadoc, “this is not meant as a protection against code running in the same VM, nor against an attacker who has local file system access on Jenkins master”. But at least makes things more complicated :-)

public static Secret fromString(String data) {
    data = Util.fixNull(data);
    Secret s = decrypt(data);
    if(s==null) s=new Secret(data);
    return s;

The first line simply replaces a null string by an empty “”, or keeps the current value of not null.

After that, the decrypt method is called.

public static Secret decrypt(String data) {
    if(data==null)      return null;
    try {
        byte[] in = Base64.decode(data.toCharArray());
        Secret s = tryDecrypt(KEY.decrypt(), in);
        if (s!=null)    return s;

        // try our historical key for backward compatibility
        Cipher cipher = getCipher("AES");
        cipher.init(Cipher.DECRYPT_MODE, getLegacyKey());
        return tryDecrypt(cipher, in);
    } catch (GeneralSecurityException e) {
        return null;
    } catch (UnsupportedEncodingException e) {
        throw new Error(e); // impossible
    } catch (IOException e) {
        return null;

The KEY.decrypt() call will return a javax.crypto.Cipher. The Cipher class is handled in CryptoConfidentialKey in Jenkins API, where it defines the algorithm used to create the cipher: AES.

Jenkins has also a ConfidentialStore, that is required to create the cipher. This class must be initialized before someone tries to create or read a cipher. This extra step also increases security, though access to the JVM is still a problem.

It is a bit late, so it is all for today. In summary: the credentials plug-in gives you a central place to manage credentials, but it is up to plug-in developers to use it. Sensitive values can be encrypted with AES on disk. So it is important that your file permissions, ACL and system auditing processes are in place and well maintained and monitored.

Happy hacking!