90% of B2B buying happens during a buyer's internal meetings — not sales meetings. It's when champions pitch and teams debate your product's value, without sales reps around. But most champions wing their message, or create their own pitch materials, because they won’t send templates and marketing materials to their boss. That's why Fluint uses your buyer's own words to build a message your prospects are proud to champion with you. Apply for early access 👉🏼 fluint.io

Fluint

In this article, I want to share my experience setting up logging for our project. We transitioned from using ELK to New Relic for log storage. I'll explain how we chose our log delivery method, the options we considered, and why we settled on our current solution. I want to emphasize that this is not an advertisement for New Relic—you can use any log storage you prefer. The main focus will be on configuring Fluent Bit, which we used for log forwarding. In our AWS ECS project, we manage a dozen EC2 instances running various microservices. We use Sentry to collect errors from all applications. Until recently, we used an rsyslog-logstash-ELK stack for log collection. However, we encountered several issues: ELK was deployed on a separate instance and eventually stopped working due to resource shortages and insufficient configuration. Logstash often stopped under high load due to memory leaks. Additionally, this stack is not suitable for use with Fargate after transitioning from EC2. We needed a solution that could effectively work on both EC2 and Fargate, be easy to configure, and support sending logs to New Relic. Rsyslog does not support integration with New Relic, and Fluentd needs to be run on each instance. As a result, we chose the lightweight and versatile Fluent Bit. My solution looks as follows: each ECS service in the task definition is paired with a log router container. This container is configured to forward logs to a specific storage and collects logs only from the specific service. Thus, each service has its own log router. This method of log forwarding is essentially described in the documentation. However, none of the suggested options fully met my requirements, so I decided to document my solution in this article. The requirements for implementation were as follows: Simple integration with the service and log capture.


Easy configuration of Fluent Bit that would apply to all log routers at once.


Centralized storage of log storage authorization information. The following two parts are not necessary if you do not plan to configure parsers for Fluent Bit. I configured them so that Fluent Bit would combine multiline logs into a single message, which required creating a custom Fluent Bit image. For information on using the base image and a configuration stored on AWS S3, you can refer to this guide. Setting Up the Fluent Bit Docker Image Let's start with the Fluent Bit Docker image, which we will add to the task definition configuration. According to the official New Relic documentation, the task definition configuration needs to include a specific Fluent Bit image configured for New Relic and specify the AWS region, such as us-east-2. For my image, I used the image from the documentation for a specific region, although you can also use the official image from Docker Hub: amazon/aws-for-fluent-bit. FROM .../logging-firelens-fluentbit

COPY fluent-bit.conf /fluent-bit/alt/fluent-bit.conf
COPY parsers.conf /fluent-bit/etc/

CMD ["/fluent-bit/bin/fluent-bit", "-e", "/fluent-bit/bin/out_newrelic.so", "-c", "/fluent-bit/alt/fluent-bit.conf"] I created the following Dockerfile. Here, we inherit from one of the base images, copy our configurations and parsers (which will be discussed below), and in the startup command, we connect the plugin for New Relic. Configuring and Creating Parsers for Fluent Bit Now, we need to configure Fluent Bit. This is done using the fluent-bit.conf and parsers.conf files. fluent-bit.conf [SERVICE]
    Flush        1
    Grace        30
    Log_Level    debug
    parsers_file /fluent-bit/etc/parsers.conf

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    Mem_Buf_Limit 27MB

[INPUT]
    Name forward
    Listen 0.0.0.0
    Port 24224
    Mem_Buf_Limit 27MB

[INPUT]
    Name tcp
    Tag firelens-healthcheck
    Listen 127.0.0.1
    Port 8877
    Mem_Buf_Limit 27MB

[OUTPUT]
    Name null
    Match firelens-healthcheck
    
[OUTPUT]
    Name newrelic
    Match *
    apiKey ${apiKey_0}

[FILTER]
    Name modify
    Match *
    Add environment ${CLUSTER}
    Add app ${APP}

[FILTER]
    Name                multiline
    Match               *
    multiline.key_content log
    multiline.parser    python-multiline-ssl
    
[FILTER]
    Name            grep
    Match           *
    Exclude         log ^.*SSL with verify_certs=False.*$ parsers.conf [MULTILINE_PARSER]
    Name            python-multiline-ssl
    Type            regex
    flush_timeout   1000
    rule "start_state" "/^.*(http_urllib3.py).*(verify_certs=False).*/" "cont"
    rule "cont" "/^.*SSL.*$/" "cont" I mainly copied the settings from the Fluent Bit documentation, adjusting only for loading parser files, sending logs to New Relic, and setting up filters. Let me explain the filters in more detail. In my case, they are used for: Adding metadata to the log, such as environment and app. These data are taken from environment variables, which I will pass when configuring the task definition.


Defining multiline outputs. With parsers, you can determine that several lines of a log belong to one message, such as a multiline warning/error output from Python.


Ignoring messages that contain a specific set of data. The parsers.conf file contains rules for determining that multiple lines of a log belong to one message. Here, we define a named parser, which is then connected to the multiline filter. Next, we build the image with the docker build command and push it to the Docker repository with the docker push command, tagging it as latest. Now, this image can be used in the task definition. Configuring the AWS ECS Task Definition The last step is to configure the task definition. {
    "essential": true,
    "name": "app",
		"logConfiguration": {
		    "logDriver": "awsfirelens",
		    "options": {
		        "Name": "newrelic"
		    },
		    "secretOptions": [
		        {
		            "name": "apiKey",
		            "valueFrom": "arn:aws:secretsmanager:xxxxxx"
		        }
		    ]
		}
},
{
		"essential": true,
    "name": "app-log-router",
    "image": "your_repo/fluent-bit:latest",
    "cpu": 0,
    "memoryReservation": 50,
    "environment": [
        {
            "name": "CLUSTER",
            "value": "prod"
        },
        {
            "name": "APP",
            "value": "cms"
        }
    ],
    "firelensConfiguration": {
        "type": "fluentbit"
    }
} Within this task definition, there are two containers that run together. If either container fails to start, the entire service does not start, which is logically sound. The New Relic API key for access is passed through AWS Secret Manager. Additionally, environment variables are populated with metadata added earlier in the Fluent Bit fluent-bit.conf configuration filter. The task definition also specifies the latest Fluent Bit image available in the Docker repository. After the service starts, New Relic begins receiving logs. Challenges There is one non-obvious issue causing the service to not start immediately. As seen in the Fluent Bit configuration (apiKey ${apiKey_0}), the API key is retrieved from the apiKey_0 variable saved by AWS Secret Manager. Occasionally, the key is saved to apiKey_1, preventing the log router from starting and consequently halting the service. I have observed that after several restart attempts, the key is correctly placed back into apiKey_0, allowing the service to eventually start. Additionally, I sometimes wish to view logs using docker logs id command, but this setup does not support that. Conclusion I chose this approach because it provides the flexibility and scalability required for microservices architecture in AWS ECS. Fluent Bit enables easy configuration and centralized logging for all services, ensuring reliable log delivery. Using Docker images simplifies deployment and management of log routers, while AWS Secret Manager ensures secure storage and access to authorization data. This approach has helped me establish a resilient and efficient logging system that adapts smoothly to changing requirements and loads. In this article, I want to share my experience setting up logging for our project. We transitioned from using ELK to New Relic for log storage. I'll explain how we chose our log delivery method, the options we considered, and why we settled on our current solution. I want to emphasize that this is not an advertisement for New Relic—you can use any log storage you prefer. The main focus will be on configuring Fluent Bit, which we used for log forwarding. In our AWS ECS project, we manage a dozen EC2 instances running various microservices. We use Sentry to collect errors from all applications. Until recently, we used an rsyslog-logstash-ELK stack for log collection. However, we encountered several issues: ELK was deployed on a separate instance and eventually stopped working due to resource shortages and insufficient configuration. Logstash often stopped under high load due to memory leaks. Additionally, this stack is not suitable for use with Fargate after transitioning from EC2. We needed a solution that could effectively work on both EC2 and Fargate, be easy to configure, and support sending logs to New Relic. Rsyslog does not support integration with New Relic, and Fluentd needs to be run on each instance. As a result, we chose the lightweight and versatile Fluent Bit. My solution looks as follows: each ECS service in the task definition is paired with a log router container. This container is configured to forward logs to a specific storage and collects logs only from the specific service. Thus, each service has its own log router. This method of log forwarding is essentially described in the documentation. However, none of the suggested options fully met my requirements, so I decided to document my solution in this article. The requirements for implementation were as follows: Simple integration with the service and log capture. Easy configuration of Fluent Bit that would apply to all log routers at once. Centralized storage of log storage authorization information. Simple integration with the service and log capture. Simple integration with the service and log capture. Easy configuration of Fluent Bit that would apply to all log routers at once. Easy configuration of Fluent Bit that would apply to all log routers at once. Centralized storage of log storage authorization information. Centralized storage of log storage authorization information. The following two parts are not necessary if you do not plan to configure parsers for Fluent Bit. I configured them so that Fluent Bit would combine multiline logs into a single message, which required creating a custom Fluent Bit image. For information on using the base image and a configuration stored on AWS S3, you can refer to this guide. The following two parts are not necessary if you do not plan to configure parsers for Fluent Bit. I configured them so that Fluent Bit would combine multiline logs into a single message, which required creating a custom Fluent Bit image. For information on using the base image and a configuration stored on AWS S3, you can refer to this guide . this guide Setting Up the Fluent Bit Docker Image Let's start with the Fluent Bit Docker image, which we will add to the task definition configuration. According to the official New Relic documentation , the task definition configuration needs to include a specific Fluent Bit image configured for New Relic and specify the AWS region, such as us-east-2. For my image, I used the image from the documentation for a specific region, although you can also use the official image from Docker Hub: amazon/aws-for-fluent-bit . New Relic documentation amazon/aws-for-fluent-bit FROM .../logging-firelens-fluentbit

COPY fluent-bit.conf /fluent-bit/alt/fluent-bit.conf
COPY parsers.conf /fluent-bit/etc/

CMD ["/fluent-bit/bin/fluent-bit", "-e", "/fluent-bit/bin/out_newrelic.so", "-c", "/fluent-bit/alt/fluent-bit.conf"] FROM .../logging-firelens-fluentbit

COPY fluent-bit.conf /fluent-bit/alt/fluent-bit.conf
COPY parsers.conf /fluent-bit/etc/

CMD ["/fluent-bit/bin/fluent-bit", "-e", "/fluent-bit/bin/out_newrelic.so", "-c", "/fluent-bit/alt/fluent-bit.conf"] I created the following Dockerfile. Here, we inherit from one of the base images, copy our configurations and parsers (which will be discussed below), and in the startup command, we connect the plugin for New Relic. Configuring and Creating Parsers for Fluent Bit Now, we need to configure Fluent Bit. This is done using the fluent-bit.conf and parsers.conf files. fluent-bit.conf parsers.conf fluent-bit.conf [SERVICE]
    Flush        1
    Grace        30
    Log_Level    debug
    parsers_file /fluent-bit/etc/parsers.conf

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    Mem_Buf_Limit 27MB

[INPUT]
    Name forward
    Listen 0.0.0.0
    Port 24224
    Mem_Buf_Limit 27MB

[INPUT]
    Name tcp
    Tag firelens-healthcheck
    Listen 127.0.0.1
    Port 8877
    Mem_Buf_Limit 27MB

[OUTPUT]
    Name null
    Match firelens-healthcheck
    
[OUTPUT]
    Name newrelic
    Match *
    apiKey ${apiKey_0}

[FILTER]
    Name modify
    Match *
    Add environment ${CLUSTER}
    Add app ${APP}

[FILTER]
    Name                multiline
    Match               *
    multiline.key_content log
    multiline.parser    python-multiline-ssl
    
[FILTER]
    Name            grep
    Match           *
    Exclude         log ^.*SSL with verify_certs=False.*$ [SERVICE]
    Flush        1
    Grace        30
    Log_Level    debug
    parsers_file /fluent-bit/etc/parsers.conf

[INPUT]
    Name forward
    unix_path /var/run/fluent.sock
    Mem_Buf_Limit 27MB

[INPUT]
    Name forward
    Listen 0.0.0.0
    Port 24224
    Mem_Buf_Limit 27MB

[INPUT]
    Name tcp
    Tag firelens-healthcheck
    Listen 127.0.0.1
    Port 8877
    Mem_Buf_Limit 27MB

[OUTPUT]
    Name null
    Match firelens-healthcheck
    
[OUTPUT]
    Name newrelic
    Match *
    apiKey ${apiKey_0}

[FILTER]
    Name modify
    Match *
    Add environment ${CLUSTER}
    Add app ${APP}

[FILTER]
    Name                multiline
    Match               *
    multiline.key_content log
    multiline.parser    python-multiline-ssl
    
[FILTER]
    Name            grep
    Match           *
    Exclude         log ^.*SSL with verify_certs=False.*$ parsers.conf [MULTILINE_PARSER]
    Name            python-multiline-ssl
    Type            regex
    flush_timeout   1000
    rule "start_state" "/^.*(http_urllib3.py).*(verify_certs=False).*/" "cont"
    rule "cont" "/^.*SSL.*$/" "cont" [MULTILINE_PARSER]
    Name            python-multiline-ssl
    Type            regex
    flush_timeout   1000
    rule "start_state" "/^.*(http_urllib3.py).*(verify_certs=False).*/" "cont"
    rule "cont" "/^.*SSL.*$/" "cont" I mainly copied the settings from the Fluent Bit documentation , adjusting only for loading parser files, sending logs to New Relic, and setting up filters. Let me explain the filters in more detail. In my case, they are used for: Fluent Bit documentation Adding metadata to the log, such as environment and app. These data are taken from environment variables, which I will pass when configuring the task definition. Defining multiline outputs. With parsers, you can determine that several lines of a log belong to one message, such as a multiline warning/error output from Python. Ignoring messages that contain a specific set of data. Adding metadata to the log, such as environment and app. These data are taken from environment variables, which I will pass when configuring the task definition. Adding metadata to the log, such as environment and app. These data are taken from environment variables, which I will pass when configuring the task definition. Defining multiline outputs. With parsers, you can determine that several lines of a log belong to one message, such as a multiline warning/error output from Python. Defining multiline outputs. With parsers, you can determine that several lines of a log belong to one message, such as a multiline warning/error output from Python. Ignoring messages that contain a specific set of data. Ignoring messages that contain a specific set of data. The parsers.conf file contains rules for determining that multiple lines of a log belong to one message. Here, we define a named parser, which is then connected to the multiline filter. parsers.conf Next, we build the image with the docker build command and push it to the Docker repository with the docker push command, tagging it as latest . Now, this image can be used in the task definition. docker build docker push latest Configuring the AWS ECS Task Definition The last step is to configure the task definition. {
    "essential": true,
    "name": "app",
		"logConfiguration": {
		    "logDriver": "awsfirelens",
		    "options": {
		        "Name": "newrelic"
		    },
		    "secretOptions": [
		        {
		            "name": "apiKey",
		            "valueFrom": "arn:aws:secretsmanager:xxxxxx"
		        }
		    ]
		}
},
{
		"essential": true,
    "name": "app-log-router",
    "image": "your_repo/fluent-bit:latest",
    "cpu": 0,
    "memoryReservation": 50,
    "environment": [
        {
            "name": "CLUSTER",
            "value": "prod"
        },
        {
            "name": "APP",
            "value": "cms"
        }
    ],
    "firelensConfiguration": {
        "type": "fluentbit"
    }
} {
    "essential": true,
    "name": "app",
		"logConfiguration": {
		    "logDriver": "awsfirelens",
		    "options": {
		        "Name": "newrelic"
		    },
		    "secretOptions": [
		        {
		            "name": "apiKey",
		            "valueFrom": "arn:aws:secretsmanager:xxxxxx"
		        }
		    ]
		}
},
{
		"essential": true,
    "name": "app-log-router",
    "image": "your_repo/fluent-bit:latest",
    "cpu": 0,
    "memoryReservation": 50,
    "environment": [
        {
            "name": "CLUSTER",
            "value": "prod"
        },
        {
            "name": "APP",
            "value": "cms"
        }
    ],
    "firelensConfiguration": {
        "type": "fluentbit"
    }
} Within this task definition, there are two containers that run together. If either container fails to start, the entire service does not start, which is logically sound. The New Relic API key for access is passed through AWS Secret Manager. Additionally, environment variables are populated with metadata added earlier in the Fluent Bit fluent-bit.conf configuration filter. The task definition also specifies the latest Fluent Bit image available in the Docker repository. fluent-bit.conf After the service starts, New Relic begins receiving logs. Challenges There is one non-obvious issue causing the service to not start immediately. As seen in the Fluent Bit configuration ( apiKey ${apiKey_0} ), the API key is retrieved from the apiKey_0 variable saved by AWS Secret Manager. Occasionally, the key is saved to apiKey_1 , preventing the log router from starting and consequently halting the service. I have observed that after several restart attempts, the key is correctly placed back into apiKey_0 , allowing the service to eventually start. apiKey ${apiKey_0} apiKey_0 apiKey_1 apiKey_0 Additionally, I sometimes wish to view logs using docker logs id command, but this setup does not support that. docker logs id Conclusion I chose this approach because it provides the flexibility and scalability required for microservices architecture in AWS ECS. Fluent Bit enables easy configuration and centralized logging for all services, ensuring reliable log delivery. Using Docker images simplifies deployment and management of log routers, while AWS Secret Manager ensures secure storage and access to authorization data. This approach has helped me establish a resilient and efficient logging system that adapts smoothly to changing requirements and loads.

Centralized Logging for AWS ECS in New Relic using FluentBit

Authors:
(1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch);
(2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction
II. Related Work
III. Background and Motivation
IV. FluentCrypto
V. Study Setup
VI. Study Result
VII. Threats to Validity
VIII. Conclusion and References VII. THREATS TO VALIDITY We had not the possibility to conduct an on-site experiment due to the COVID-19 pandemic. The participants themselves had to record the time spent on each task. It is possible that how each participant calculated the time varies from the actual time. We mitigated this issue by explaining how to measure the time. Each participant had to read a task, comprehend basic concepts, and then start the task. The experience of participants and their familiarity with cryptography could impact the result. We tried to mitigate this threat by recruiting participants with different level of experience and expertise in this domain, and by briefing them on the basics of cryptography. Participants self-reported their cryptography knowledge and rated the difficulty of each task based on their personal perceptions of their experience. It is possible that each subject had a different perception about his/her experience, which may not have been necessarily true. Likewise, a perceived “level of knowledge” in cryptography may not precisely reflect how developers perform in practice. We mitigated this threat by defining what each level means. Every participant used both tools, i.e., Node.js API and FluentCrypto, for each task. We did not specify which tool to use first, but the one used second may be subject to learning bias. Therefore, a study with two groups of participants that exclusively use either of these tools may mitigate this threat. Nevertheless, this has no effect on the security of a provided solution. We assessed the security of each solution manually, which may be prone to observers’ expectancy and subjectivity. We mitigated this threat by reviewing each solution based on a check list of risks provided by a team of external security experts. There is a threat to external validity due to the small number of subjects in this study. We reduced this threat by only recruiting participants who were employed at the software industry. Nevertheless, future studies with a more representative number of participants is necessary. What’s more, we cannot rule out the possibility that the results could have been different if the tasks were more complex and within a real-world software development context. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Authors: Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction II. Related Work III. Background and Motivation IV. FluentCrypto V. Study Setup VI. Study Result VII. Threats to Validity VIII. Conclusion and References Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Background and Motivation III. Background and Motivation IV. FluentCrypto IV. FluentCrypto V. Study Setup V. Study Setup VI. Study Result VI. Study Result VII. Threats to Validity VII. Threats to Validity VIII. Conclusion and References VIII. Conclusion and References VII. THREATS TO VALIDITY We had not the possibility to conduct an on-site experiment due to the COVID-19 pandemic. The participants themselves had to record the time spent on each task. It is possible that how each participant calculated the time varies from the actual time. We mitigated this issue by explaining how to measure the time. Each participant had to read a task, comprehend basic concepts, and then start the task. The experience of participants and their familiarity with cryptography could impact the result. We tried to mitigate this threat by recruiting participants with different level of experience and expertise in this domain, and by briefing them on the basics of cryptography. Participants self-reported their cryptography knowledge and rated the difficulty of each task based on their personal perceptions of their experience. It is possible that each subject had a different perception about his/her experience, which may not have been necessarily true. Likewise, a perceived “level of knowledge” in cryptography may not precisely reflect how developers perform in practice. We mitigated this threat by defining what each level means. Every participant used both tools, i.e., Node.js API and FluentCrypto, for each task. We did not specify which tool to use first, but the one used second may be subject to learning bias. Therefore, a study with two groups of participants that exclusively use either of these tools may mitigate this threat. Nevertheless, this has no effect on the security of a provided solution. We assessed the security of each solution manually, which may be prone to observers’ expectancy and subjectivity. We mitigated this threat by reviewing each solution based on a check list of risks provided by a team of external security experts. There is a threat to external validity due to the small number of subjects in this study. We reduced this threat by only recruiting participants who were employed at the software industry. Nevertheless, future studies with a more representative number of participants is necessary. What’s more, we cannot rule out the possibility that the results could have been different if the tasks were more complex and within a real-world software development context. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

FluentCrypto: Cryptography in Easy Mode: Threats to Validity

Authors:
(1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch);
(2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction
II. Related Work
III. Background and Motivation
IV. FluentCrypto
V. Study Setup
VI. Study Result
VII. Threats to Validity
VIII. Conclusion and References III. BACKGROUND AND MOTIVATION Node.js is a popular open-source, cross-platform, backend JavaScript runtime environment to build scalable network applications.[1] It provides a built-in library called “crypto” which developers can use to perform cryptographic operations on data. According to the latest survey conducted by the Stack Overflow website in 2020,[2] for the second year in a row, Node.js is a worldwide leader among frameworks. However, to the best of our knowledge, there exists no work in academia to address crypto misuses in this environment. Consider Listing 1 that shows a code example to encrypt data with a private key. We access the cryptography module at line 1. We specify the encryption algorithm i.e., “des”, derive the encryption key using the Scrypt function, and define the initialization vector (iv) at line 2-4, respectively. Instances of the Cipher class are used to encrypt data, and we create and initialize such an instance at line 5. The cipher.update() method performs the actual encryption. It takes three arguments i.e., the data, the input encoding, and the output encoding. We call this method at line 6 to encrypt a piece of “utf-8”-encoded text and store the result in the hex format. In the end, at line 7, we call the cipher.final() method to indicate that the Cipher object is no longer needed and the encryption process is finalized. There are a number of caveats that developers should take into account to ensure that this code and its counterpart for decryption work correctly. For instance, the default string encoding used by the crypto module is utf-8. We also need a key of a certain length, depending on which cipher algorithm we choose for encryption. In this example, the iv and the key must have the same length i.e., number of bytes. If the encoding of the input data is given to the cipher.update() method, the data argument is a string in the specified encoding. Otherwise, data must be a Buffer. Likewise, if the encoding of the output is specified, a string in the specified encoding is returned. Otherwise, a Buffer is returned. Even if we assume that a novice developer will figure out how to write the code in Listing 1 that is functioning, it suffers from a number of security issues. We used Scrypt, a password-based key derivation function, which requires three arguments namely password, salt and the key length to construct the secret key. A salt is combined with the password to avoid producing an identical key for the same password, which substantially lessens the impact of pre-computed hash attacks especially against commonly used passwords[3]. Therefore, salt should be as unique as possible and it is recommended that salt is random and at least 16 bytes long. However, in the example, the salt is a fixed value and does not help in deriving distinct keys. The next security issue concerns the IV whose purpose is to ensure that an identical message encrypted with the same key leads to different encrypted outputs. This requires the IV to be unpredictable and unique; and ideally, cryptographically random so that an attacker cannot predict ahead of time what a given IV will be. Nevertheless, in the example, the IV is always a zero-filled buffer. Finally, DES is no longer a secure algorithm due to its comparatively short key size. We investigated obstacles as well as security risks that are associated with hashing, symmetric and asymmetric encryption in Node.js. We decided to focus on these cryptographic tasks as research as well as our experience show that they are commonly used to secure software systems [4]. It is notable that a developer must have knowledge about, for instance, the choice of algorithm, the correct key and IV generation process, and input and output encoding. Even worse, error messages are sometimes cryptic. For example, by default, Node.js crypto API assumes that the input encoding must be a buffer, and the failure in setting the right character encoding during decryption yields the “error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length” error, which does not guide developers per se toward resolving the issue. It would have been much easier if developers could have just told the API that, for example, they want to encrypt data and then decrypt it later, without necessarily having to search for a (secure) algorithm; understanding how long the key and the IV have to be, and how to generate them securely; and with more useful error messages when something goes wrong. This paper is available on arxiv under CC BY 4.0 DEED license. [1] https://nodejs.org [2] Stack Overflow Developer Survey 2020 [3] NIST recommendation for password-based key derivation Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Authors: Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction II. Related Work III. Background and Motivation IV. FluentCrypto V. Study Setup VI. Study Result VII. Threats to Validity VIII. Conclusion and References Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Background and Motivation III. Background and Motivation IV. FluentCrypto IV. FluentCrypto V. Study Setup V. Study Setup VI. Study Result VI. Study Result VII. Threats to Validity VII. Threats to Validity VIII. Conclusion and References VIII. Conclusion and References III. BACKGROUND AND MOTIVATION Node.js is a popular open-source, cross-platform, backend JavaScript runtime environment to build scalable network applications.[1] It provides a built-in library called “crypto” which developers can use to perform cryptographic operations on data. According to the latest survey conducted by the Stack Overflow website in 2020,[2] for the second year in a row, Node.js is a worldwide leader among frameworks. However, to the best of our knowledge, there exists no work in academia to address crypto misuses in this environment. Consider Listing 1 that shows a code example to encrypt data with a private key. We access the cryptography module at line 1. We specify the encryption algorithm i.e., “des”, derive the encryption key using the Scrypt function, and define the initialization vector (iv) at line 2-4, respectively. Instances of the Cipher class are used to encrypt data, and we create and initialize such an instance at line 5. The cipher.update() method performs the actual encryption. It takes three arguments i.e., the data, the input encoding, and the output encoding. We call this method at line 6 to encrypt a piece of “utf-8”-encoded text and store the result in the hex format. In the end, at line 7, we call the cipher.final() method to indicate that the Cipher object is no longer needed and the encryption process is finalized. There are a number of caveats that developers should take into account to ensure that this code and its counterpart for decryption work correctly. For instance, the default string encoding used by the crypto module is utf-8. We also need a key of a certain length, depending on which cipher algorithm we choose for encryption. In this example, the iv and the key must have the same length i.e., number of bytes. If the encoding of the input data is given to the cipher.update() method, the data argument is a string in the specified encoding. Otherwise, data must be a Buffer. Likewise, if the encoding of the output is specified, a string in the specified encoding is returned. Otherwise, a Buffer is returned. Even if we assume that a novice developer will figure out how to write the code in Listing 1 that is functioning, it suffers from a number of security issues. We used Scrypt, a password-based key derivation function, which requires three arguments namely password, salt and the key length to construct the secret key. A salt is combined with the password to avoid producing an identical key for the same password, which substantially lessens the impact of pre-computed hash attacks especially against commonly used passwords[3]. Therefore, salt should be as unique as possible and it is recommended that salt is random and at least 16 bytes long. However, in the example, the salt is a fixed value and does not help in deriving distinct keys. The next security issue concerns the IV whose purpose is to ensure that an identical message encrypted with the same key leads to different encrypted outputs. This requires the IV to be unpredictable and unique; and ideally, cryptographically random so that an attacker cannot predict ahead of time what a given IV will be. Nevertheless, in the example, the IV is always a zero-filled buffer. Finally, DES is no longer a secure algorithm due to its comparatively short key size. We investigated obstacles as well as security risks that are associated with hashing, symmetric and asymmetric encryption in Node.js. We decided to focus on these cryptographic tasks as research as well as our experience show that they are commonly used to secure software systems [4]. It is notable that a developer must have knowledge about, for instance, the choice of algorithm, the correct key and IV generation process, and input and output encoding. Even worse, error messages are sometimes cryptic. For example, by default, Node.js crypto API assumes that the input encoding must be a buffer, and the failure in setting the right character encoding during decryption yields the “error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length” error, which does not guide developers per se toward resolving the issue. It would have been much easier if developers could have just told the API that, for example, they want to encrypt data and then decrypt it later, without necessarily having to search for a (secure) algorithm; understanding how long the key and the IV have to be, and how to generate them securely; and with more useful error messages when something goes wrong. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv [1] https://nodejs.org [2] Stack Overflow Developer Survey 2020 [3] NIST recommendation for password-based key derivation

FluentCrypto: Cryptography in Easy Mode: Background and Motivation

FluentCrypto: Cryptography in Easy Mode: FluentCrypto

FluentCrypto: Cryptography in Easy Mode: Study Setup

Authors:
(1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch);
(2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction
II. Related Work
III. Background and Motivation
IV. FluentCrypto
V. Study Setup
VI. Study Result
VII. Threats to Validity
VIII. Conclusion and References VIII. CONCLUSION We developed FluentCrypto to relieve mainstream developers from dealing with low-level cryptography complexities. It is built on top of the standard Node.js API and provides a task-based solution i.e., developers only state “what” they need rather than being concerned about “how” to implement a cryptography task. We also developed a domain-specific language, called CryRule, that crypto experts can use to specify constraints on crypto objects. FluentCrypto relies on these constraints to determine a secure configuration of the API. Through an initial study, we found that FluentCrypto greatly helps developers to deliver secure solutions in a shorter time. It prevents common errors by novice developers, but at the same time it still allows experienced developers to access advanced settings. This work is the first step toward supporting mainstream developers with a crypto API that is secure by design, and further studies are essential to claim any generalization. We plan to conduct an extensive experiment with more subjects when COVID-19 restrictions relax and developers come back to their work offices. Particularly, we are interested to assess the usability of FluentCrypto in depth as well as its runtime overhead. In terms of extending FluentCrypto, we will investigate whether its current design would support other cryptography tasks as well. Besides, in this work we relied on a dynamic approach to enforce crypto constraints mainly due to the use of JavaScript, but it is worthwhile to investigate the possibility of adopting statical techniques to provide developers with JIT feedback especially in other settings. REFERENCES [1] T. IBM and the Ponemon Institute, “Cost of a data breach report,” Tech. Rep., 2020. [2] N. Patnaik, J. Hallett, and A. Rashid, “Usability smells: An analysis of developers’ struggle with crypto libraries,” in Fifteenth Symposium on Usable Privacy and Security (SOUPS 2019). Santa Clara, CA: USENIX Association, Aug. 2019. [Online]. Available: https://www.usenix.org/conference/soups2019/presentation/patnaik [3] M. Hazhirpasand, M. Ghafari, S. Krüger, E. Bodden, and O. Nierstrasz, “The impact of developer experience in using Java cryptography,” in 2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 2019, pp. 1–6. [4] M. Hazhirpasand, M. Ghafari, and O. Nierstrasz, “Java cryptography uses in the wild,” in Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), ser. ESEM ’20. New York, NY, USA: Association for Computing Machinery, 2020. [Online]. Available: https://doi.org/10.1145/3382494.3422166 [5] T. Zhang, G. Upadhyaya, A. Reinhardt, H. Rajan, and M. Kim, “Are code examples on an online q&a forum reliable?: a study of api misuse on stack overflow,” in 2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE). IEEE, 2018, pp. 886–896. [6] M. Ghafari, P. Gadient, and O. Nierstrasz, “Security smells in android,” in 2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM), 2017, pp. 121–130. [7] P. Gadient, M. Ghafari, P. Frischknecht, and O. Nierstrasz, “Security code smells in android icc,” Empirical Software Engineering, vol. 24, 2019. [8] S. Krüger, S. Nadi, M. Reif, K. Ali, M. Mezini, E. Bodden, F. Göpfert, F. Günther, C. Weinert, D. Demmler et al., “Cognicrypt: supporting developers in using cryptography,” in 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2017, pp. 931–936. [9] S. Rahaman, Y. Xiao, S. Afrose, F. Shaon, K. Tian, M. Frantz, M. Kantarcioglu, and D. D. Yao, “Cryptoguard: High precision detection of cryptographic vulnerabilities in massive-sized java projects,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 2455–2472. [Online]. Available: https://doi.org/10.1145/3319535.3345659 [10] Y. Tymchuk, M. Ghafari, and O. Nierstrasz, “Jit feedback - what experienced developers like about static analysis,” in 2018 IEEE/ACM 26th International Conference on Program Comprehension (ICPC), 2018, pp. 64–6409. [11] J. Smith, L. N. Q. Do, and E. Murphy-Hill, “Why can’t johnny fix vulnerabilities: A usability evaluation of static analysis tools for security,” in Sixteenth Symposium on Usable Privacy and Security (SOUPS 2020). USENIX Association, Aug. 2020, pp. 221– 238. [Online]. Available: https://www.usenix.org/conference/soups2020/ presentation/smith [12] C. Corrodi, T. Spring, M. Ghafari, and O. Nierstrasz, “Idea: Benchmarking android data leak detection tools,” in Engineering Secure Software and Systems, M. Payer, A. Rashid, and J. M. Such, Eds. Cham: Springer International Publishing, 2018, pp. 116–123. [13] V.-P. Ranganath and J. Mitra, “Are free android app security analysis tools effective in detecting known vulnerabilities?” Empirical Software Engineering, vol. 25, 2020. [14] M. Hazhirpasand, M. Ghafari, and O. Nierstrasz, “Cryptoexplorer: An interactive web platform supporting secure use of cryptography APIs,” arXiv preprint arXiv:2001.00773, 2020. [15] S. Nadi, S. Krüger, M. Mezini, and E. Bodden, “Jumping through hoops: Why do Java developers struggle with cryptography APIs?” in Proceedings of the 38th International Conference on Software Engineering, 2016, pp. 935–946. [16] M. Green and M. Smith, “Developers are not the enemy!: The need for usable security APIs,” IEEE Security & Privacy, vol. 14, no. 5, pp. 40–46, 2016. [17] S. Das, V. Gopal, K. King, and A. Venkatraman, “IV= 0 security: Cryptographic misuse of libraries,” Massachusetts Institute of Technology, Final Rep, vol. 6, 2014. [18] S. Krüger, K. Ali, and E. Bodden, “CognicryptGEN : Generating code for the secure usage of crypto apis,” in Proceedings of the 18th ACM/IEEE International Symposium on Code Generation and Optimization, ser. CGO 2020. New York, NY, USA: Association for Computing Machinery, 2020, p. 185–198. [Online]. Available: https://doi.org/10.1145/3368826.3377905 [19] D. C. Nguyen, D. Wermke, Y. Acar, M. Backes, C. Weir, and S. Fahl, “A stitch in time: Supporting android developers in writingsecure code,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 1065–1077. [Online]. Available: https://doi.org/10.1145/3133956.3133977 [20] L. Singleton, R. Zhao, M. Song, and H. Siy, “Cryptotutor: Teaching secure coding practices through misuse pattern detection,” in Proceedings of the 21st Annual Conference on Information Technology Education, ser. SIGITE ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 403–408. [Online]. Available: https://doi.org/10.1145/3368308.3415419 [21] L. Piccolboni, G. Di Guglielmo, L. P. Carloni, and S. Sethumadhavan, “Crylogger: Detecting crypto misuses dynamically,” in IEEE Symposium on Security & Privacy (SP) 2021, 2021. [22] P. L. Gorski, Y. Acar, L. Lo Iacono, and S. Fahl, “Listen to developers! a participatory design study on security warnings for cryptographic apis,” in Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems, ser. CHI ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 1–13. [Online]. Available: https://doi.org/10.1145/3313831.3376142 [23] M. Fowler. (2005) Fluentinterface. [Online]. Available: https://www. martinfowler.com/bliki/FluentInterface.html This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Authors: Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction II. Related Work III. Background and Motivation IV. FluentCrypto V. Study Setup VI. Study Result VII. Threats to Validity VIII. Conclusion and References Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Background and Motivation III. Background and Motivation IV. FluentCrypto IV. FluentCrypto V. Study Setup V. Study Setup VI. Study Result VI. Study Result VII. Threats to Validity VII. Threats to Validity VIII. Conclusion and References VIII. Conclusion and References VIII. CONCLUSION We developed FluentCrypto to relieve mainstream developers from dealing with low-level cryptography complexities. It is built on top of the standard Node.js API and provides a task-based solution i.e., developers only state “what” they need rather than being concerned about “how” to implement a cryptography task. We also developed a domain-specific language, called CryRule, that crypto experts can use to specify constraints on crypto objects. FluentCrypto relies on these constraints to determine a secure configuration of the API. Through an initial study, we found that FluentCrypto greatly helps developers to deliver secure solutions in a shorter time. It prevents common errors by novice developers, but at the same time it still allows experienced developers to access advanced settings. This work is the first step toward supporting mainstream developers with a crypto API that is secure by design, and further studies are essential to claim any generalization. We plan to conduct an extensive experiment with more subjects when COVID-19 restrictions relax and developers come back to their work offices. Particularly, we are interested to assess the usability of FluentCrypto in depth as well as its runtime overhead. In terms of extending FluentCrypto, we will investigate whether its current design would support other cryptography tasks as well. Besides, in this work we relied on a dynamic approach to enforce crypto constraints mainly due to the use of JavaScript, but it is worthwhile to investigate the possibility of adopting statical techniques to provide developers with JIT feedback especially in other settings. REFERENCES [1] T. IBM and the Ponemon Institute, “Cost of a data breach report,” Tech. Rep., 2020. [2] N. Patnaik, J. Hallett, and A. Rashid, “Usability smells: An analysis of developers’ struggle with crypto libraries,” in Fifteenth Symposium on Usable Privacy and Security (SOUPS 2019). Santa Clara, CA: USENIX Association, Aug. 2019. [Online]. Available: https://www.usenix.org/conference/soups2019/presentation/patnaik [3] M. Hazhirpasand, M. Ghafari, S. Krüger, E. Bodden, and O. Nierstrasz, “The impact of developer experience in using Java cryptography,” in 2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 2019, pp. 1–6. [4] M. Hazhirpasand, M. Ghafari, and O. Nierstrasz, “Java cryptography uses in the wild,” in Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), ser. ESEM ’20. New York, NY, USA: Association for Computing Machinery, 2020. [Online]. Available: https://doi.org/10.1145/3382494.3422166 [5] T. Zhang, G. Upadhyaya, A. Reinhardt, H. Rajan, and M. Kim, “Are code examples on an online q&a forum reliable?: a study of api misuse on stack overflow,” in 2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE). IEEE, 2018, pp. 886–896. [6] M. Ghafari, P. Gadient, and O. Nierstrasz, “Security smells in android,” in 2017 IEEE 17th International Working Conference on Source Code Analysis and Manipulation (SCAM), 2017, pp. 121–130. [7] P. Gadient, M. Ghafari, P. Frischknecht, and O. Nierstrasz, “Security code smells in android icc,” Empirical Software Engineering, vol. 24, 2019. [8] S. Krüger, S. Nadi, M. Reif, K. Ali, M. Mezini, E. Bodden, F. Göpfert, F. Günther, C. Weinert, D. Demmler et al., “Cognicrypt: supporting developers in using cryptography,” in 2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2017, pp. 931–936. [9] S. Rahaman, Y. Xiao, S. Afrose, F. Shaon, K. Tian, M. Frantz, M. Kantarcioglu, and D. D. Yao, “Cryptoguard: High precision detection of cryptographic vulnerabilities in massive-sized java projects,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 2455–2472. [Online]. Available: https://doi.org/10.1145/3319535.3345659 [10] Y. Tymchuk, M. Ghafari, and O. Nierstrasz, “Jit feedback - what experienced developers like about static analysis,” in 2018 IEEE/ACM 26th International Conference on Program Comprehension (ICPC), 2018, pp. 64–6409. [11] J. Smith, L. N. Q. Do, and E. Murphy-Hill, “Why can’t johnny fix vulnerabilities: A usability evaluation of static analysis tools for security,” in Sixteenth Symposium on Usable Privacy and Security (SOUPS 2020). USENIX Association, Aug. 2020, pp. 221– 238. [Online]. Available: https://www.usenix.org/conference/soups2020/ presentation/smith [12] C. Corrodi, T. Spring, M. Ghafari, and O. Nierstrasz, “Idea: Benchmarking android data leak detection tools,” in Engineering Secure Software and Systems, M. Payer, A. Rashid, and J. M. Such, Eds. Cham: Springer International Publishing, 2018, pp. 116–123. [13] V.-P. Ranganath and J. Mitra, “Are free android app security analysis tools effective in detecting known vulnerabilities?” Empirical Software Engineering, vol. 25, 2020. [14] M. Hazhirpasand, M. Ghafari, and O. Nierstrasz, “Cryptoexplorer: An interactive web platform supporting secure use of cryptography APIs,” arXiv preprint arXiv:2001.00773, 2020. [15] S. Nadi, S. Krüger, M. Mezini, and E. Bodden, “Jumping through hoops: Why do Java developers struggle with cryptography APIs?” in Proceedings of the 38th International Conference on Software Engineering, 2016, pp. 935–946. [16] M. Green and M. Smith, “Developers are not the enemy!: The need for usable security APIs,” IEEE Security & Privacy, vol. 14, no. 5, pp. 40–46, 2016. [17] S. Das, V. Gopal, K. King, and A. Venkatraman, “IV= 0 security: Cryptographic misuse of libraries,” Massachusetts Institute of Technology, Final Rep, vol. 6, 2014. [18] S. Krüger, K. Ali, and E. Bodden, “CognicryptGEN : Generating code for the secure usage of crypto apis,” in Proceedings of the 18th ACM/IEEE International Symposium on Code Generation and Optimization, ser. CGO 2020. New York, NY, USA: Association for Computing Machinery, 2020, p. 185–198. [Online]. Available: https://doi.org/10.1145/3368826.3377905 [19] D. C. Nguyen, D. Wermke, Y. Acar, M. Backes, C. Weir, and S. Fahl, “A stitch in time: Supporting android developers in writingsecure code,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 1065–1077. [Online]. Available: https://doi.org/10.1145/3133956.3133977 [20] L. Singleton, R. Zhao, M. Song, and H. Siy, “Cryptotutor: Teaching secure coding practices through misuse pattern detection,” in Proceedings of the 21st Annual Conference on Information Technology Education, ser. SIGITE ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 403–408. [Online]. Available: https://doi.org/10.1145/3368308.3415419 [21] L. Piccolboni, G. Di Guglielmo, L. P. Carloni, and S. Sethumadhavan, “Crylogger: Detecting crypto misuses dynamically,” in IEEE Symposium on Security & Privacy (SP) 2021, 2021. [22] P. L. Gorski, Y. Acar, L. Lo Iacono, and S. Fahl, “Listen to developers! a participatory design study on security warnings for cryptographic apis,” in Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems, ser. CHI ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 1–13. [Online]. Available: https://doi.org/10.1145/3313831.3376142 [23] M. Fowler. (2005) Fluentinterface. [Online]. Available: https://www. martinfowler.com/bliki/FluentInterface.html This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

FluentCrypto: Cryptography in Easy Mode: Conclusion and References

Authors:
(1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch);
(2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction
II. Related Work
III. Background and Motivation
IV. FluentCrypto
V. Study Setup
VI. Study Result
VII. Threats to Validity
VIII. Conclusion and References II. RELATED WORK We discuss related work from two perspectives. Firstly, we discuss an excerpt of literature that investigated why developers struggle with using crypto APIs. Secondly, we discuss previous work that aimed to help developers in circumventing crypto misuses. Nevertheless, to the best of our knowledge, there is no such research on Node.js cryptography. A. API design Nadi et al. conducted a survey with 11 developers who posted crypto-related questions on the Stack Overflow website, and 37 developers who had experience with Java’s cryptography APIs [15]. They realized that developers are able to understand crypto concepts but they fail to adopt them in practice. They concluded that the concepts behind crypto APIs are low-level and developers welcome task-based solutions for working with crypto APIs. Green and Smith found that many misuses of cryptographic libraries originate in the developer having trouble understanding the API [16]. They criticized that while it has become accepted that systems should be user-friendly for the end user, a different attitude where the end-user is expected to be an expert prevails amongst cryptographic libraries. They then proposed a set of characteristics that should lead to more secure cryptographic APIs, including: the API should be easy to use, even without documentation; incorrect use should lead to visible errors; defaults should be safe and never ambiguous; and code that uses the API should be easy to read and update. Das et al. selected the most popular cryptographic libraries from C, C++, Java, Python and Go and examined them for properties that cause cryptographic misuse by developers [17]. They examined the libraries based on a set of common potential issues such as initialization vector reuse, library defaults or incomplete features. Their work highlighted the disconnect between the actual user of such a library and the user for whom it is designed. B. Developer support Several tools have been developed to support developers in using cryptography. For example, Krüger et al. developed the CogniCrypt Eclipse plug-in that generates code snippets for cryptography tasks [18]. Nguyen et al developed FixDroid which helps developers in fixing crypto-related issues in the AndroidStudio IDE [19]. Hazhirpasand et al. developed an interactive web platform named CryptoExplorer that provides developers with real-world examples, specifically 3263 secure and 5897 insecure uses of Java Cryptography Architecture [14]. Singleton et al. developed CryptoTutor, an educational tool that flags common cryptographic misuses and suggests possible repairs [20]. The authors discussed how such a tool can be integrated into programming courses to improve developer knowledge in the cryptography domain. Several tools also exist to detect crypto misuses. For instance, Rahaman et al. developed CryptoGuard to identify crypto issues statically [9]. Piccolboni et al. proposed CryLogger, an open-source tool to detect crypto misuses dynamically [21]. Gorski surveyed 25 professional software developers to identify what kind of feedback is helpful to them in avoiding crypto misuses during programming [22]. They found that participants appreciate a clear warning message (including title, content, and code location) that is tailored to the context. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Authors: Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction II. Related Work III. Background and Motivation IV. FluentCrypto V. Study Setup VI. Study Result VII. Threats to Validity VIII. Conclusion and References Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Background and Motivation III. Background and Motivation IV. FluentCrypto IV. FluentCrypto V. Study Setup V. Study Setup VI. Study Result VI. Study Result VII. Threats to Validity VII. Threats to Validity VIII. Conclusion and References VIII. Conclusion and References II. RELATED WORK We discuss related work from two perspectives. Firstly, we discuss an excerpt of literature that investigated why developers struggle with using crypto APIs. Secondly, we discuss previous work that aimed to help developers in circumventing crypto misuses. Nevertheless, to the best of our knowledge, there is no such research on Node.js cryptography. A. API design A. API design Nadi et al. conducted a survey with 11 developers who posted crypto-related questions on the Stack Overflow website, and 37 developers who had experience with Java’s cryptography APIs [15]. They realized that developers are able to understand crypto concepts but they fail to adopt them in practice. They concluded that the concepts behind crypto APIs are low-level and developers welcome task-based solutions for working with crypto APIs. Green and Smith found that many misuses of cryptographic libraries originate in the developer having trouble understanding the API [16]. They criticized that while it has become accepted that systems should be user-friendly for the end user, a different attitude where the end-user is expected to be an expert prevails amongst cryptographic libraries. They then proposed a set of characteristics that should lead to more secure cryptographic APIs, including: the API should be easy to use, even without documentation; incorrect use should lead to visible errors; defaults should be safe and never ambiguous; and code that uses the API should be easy to read and update. Das et al. selected the most popular cryptographic libraries from C, C++, Java, Python and Go and examined them for properties that cause cryptographic misuse by developers [17]. They examined the libraries based on a set of common potential issues such as initialization vector reuse, library defaults or incomplete features. Their work highlighted the disconnect between the actual user of such a library and the user for whom it is designed. B. Developer support B. Developer support Several tools have been developed to support developers in using cryptography. For example, Krüger et al. developed the CogniCrypt Eclipse plug-in that generates code snippets for cryptography tasks [18]. Nguyen et al developed FixDroid which helps developers in fixing crypto-related issues in the AndroidStudio IDE [19]. Hazhirpasand et al. developed an interactive web platform named CryptoExplorer that provides developers with real-world examples, specifically 3263 secure and 5897 insecure uses of Java Cryptography Architecture [14]. Singleton et al. developed CryptoTutor, an educational tool that flags common cryptographic misuses and suggests possible repairs [20]. The authors discussed how such a tool can be integrated into programming courses to improve developer knowledge in the cryptography domain. Several tools also exist to detect crypto misuses. For instance, Rahaman et al. developed CryptoGuard to identify crypto issues statically [9]. Piccolboni et al. proposed CryLogger, an open-source tool to detect crypto misuses dynamically [21]. Gorski surveyed 25 professional software developers to identify what kind of feedback is helpful to them in avoiding crypto misuses during programming [22]. They found that participants appreciate a clear warning message (including title, content, and code location) that is tailored to the context. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

FluentCrypto: Cryptography in Easy Mode: Related Work

Authors:
(1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch);
(2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction
II. Related Work
III. Background and Motivation
IV. FluentCrypto
V. Study Setup
VI. Study Result
VII. Threats to Validity
VIII. Conclusion and References VI. STUDY RESULT This study showed that FluentCrypto helped participants to complete more crypto tasks in a shorter time compared to when they used the Node.js crypto API. Figure 3 presents the mean time that participants spent on each task as well as the perceived level of difficulty when dealing with each task. Notably, participants spent on average 43% shorter time to complete each task when they relied on FluentCrypto as compared to Node.js cryptography API. We also found that the participants succeeded to complete five more tasks when they relied on FluentCrypto. The investigation of the solutions revealed that there was no security issue in the ones developed for the first task. Only three solutions were secure when participants used Node.js cryptography API to develop the second and third tasks, whereas every solution developed with FluentCrypto was secure. We applied statistical tests to determine whether these findings are significant. We found that the p-values of all tests are smaller than 0.05 indicating that we can reject the null hypotheses. In other words, there is sufficient evidence with a high confidence to conclude that participants are more efficient to develop secure solutions when adopting FluentCrypto as compared to the Node.js crypto API. In general, participants perceived a higher level of difficulty as the tasks became more complex. We noted that the subjects mostly relied on the built-in crypto operations in FluentCrypto which handle low-level complexities. This could explain why the gain of using FluentCrypto increased with more complex task, especially, for novices who lacked programming experience or had limited crypto knowledge. Unexpectedly though, when dealing with Task 2, a couple of experienced developers perceived a higher level of difficulty with FluentCrypto than when they used the Node.js standard crypto library. However, these developers often completed their tasks faster when they used FluentCrypto. Moreover, participants rated the third task, on average, easier and spent shorter time on this task than the second task when they used the FluentCrypto. Although these two tasks are different, FluentCrypto is designed in such a way that the solutions are similar to implement. Therefore, what the subjects experienced earlier, especially when dealing with the second task, may have contributed to their success in the third task. In the following, we discuss the result of each task based on participant characteristics such as years of experience in programming, level of self-reported knowledge in cryptography, and prior experience with the Node.js crypto API. A. Does adopting FluentCrypto increase developer efficiency when working on a cryptographic task? We discuss our findings regarding the time that participants invested in each task as well as the perceived level of difficulty. 1) Task 1: All participants solved the first task with both the Node.js crypto API and FluentCrypto. Table IIa explains the results regarding task one. The difficulty level looks similar among the groups but the time needed for the task increases for less experienced participants and decreases for more experienced participants. Nevertheless, the one participant who had more than 10 years’ programming experience completed the task with the help of the standard Node.js API three times faster than using the FluentCrypto. Table IIb and Table IIc reveal similar results based on the perceived level of cryptographic knowledge and experience with the Node.js crypto API. Similarly to our observation from the programming experience perspective, developers who had solid knowledge in cryptography as well as those who were familiar with the Node.js crypto API, completed the task faster than when they used the FluentCrypto. 2) Task 2: The second task was more challenging for participants than the first task. The overall perceived difficulty was increased and the task took more time to solve (see Table IIIb and Table IIIc). Two participants could not finish the task with Node.js crypto API, whereas everyone completed the task when using FluentCrypto. It is evident that FluentCrypto decreased the perceived difficulty for less experienced participants. The time taken to finalize the task when using FluentCrypto reduced for all participant groups except for the group “5-10 years of experience” (Table IIIa). 3) Task 3: The third task had the highest difficulty for the participants when using the Node.js crypto API (Table IVa). It also took on average more time to complete by participants than the other two tasks. FluentCrypto decreased the difficulty and time required to complete the task for all groups, especially for the less experienced group (Table IVb). FluentCrypto improved difficulty and the required time to solve the task for both participants with and without knowledge of Node.js crypto API (Table IVc). One of the senior participants who had beyond 10 years’ experience opted out of the study at this phase. When we asked the reason, he said “I must deal with an urgent matter at work”. Of the remaining participants, three failed to finish the task with Node.js crypto API, but everyone succeeded in this task when they used FluentCrypto. B. Is FluentCrypto effective in developing secure cryptographic solutions? We manually assessed the security of each functioning solution against a check list of risks provided by a team of external security experts. We also checked any hindrances raised by the participants. 1) Task 1: Participants were satisfied by the current Node.js documentation, but had difficulties in finding the right part of documentation for FluentCrypto. All participants chose the SHA256 algorithm when they used Node.js cryptography API. In case of FluentCrypto, participants either relied on the default secure algorithm specified by CryRule, or they provided their own choices that were acceptable by FluentCrypto. 2) Task 2: The participants mostly complained about the Node.js documentation and mentioned that it is either incomplete or confusing, and consequently, they had to do additional research on the internet. When using FluentCrypto, one participant attempted to generate an IV for an unsupported cipher algorithm and was not satisfied with the thrown error message. A majority of participants who completed this task misused Node.js crypto API. Only two participants used a key that was not hardcoded, and others used a hardcoded secret from which they generated the key. None of the participants hardcoded a secret when they used FluentCrypto. They mostly relied on the provided call to generate a key. 3) Task 3: In Node.js crypto API, participants were unhappy about a lack of useful examples in the documentation and therefore, had to explore other information sources. They mainly had difficulties in grasping how to generate a key pair or how to use the keys. Conversely, developers appreciated the level of details in FluentCrypto documentation. What’s more, they found the solution very similar to what they followed while dealing with the previous task. Three participants also acknowledged that FluentCrypto is expressive e.g., “It is great that the name of an API speaks about its functionality” – a participant mentioned. Except one participant, the rest used hard-coded values to generate the key pairs when they used the Node.js cryptography API, which brings severe security risks. Two solutions also suffered from a small key size. In contrary, none of the FluentCrypto-based solutions suffered from these issues. The participants unanimously employed the secure default key-pair generation provided by FluentCrypto. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Authors: Authors: (1) Simon Kafader, University of Bern, Bern, Switzerland (simon.kafader@inf.unibe.ch); (2) Mohammad Ghafari, University of Auckland, Auckland, New Zealand (m.ghafari@auckland.ac.nz). Table of Links Abstract and I. Introduction II. Related Work III. Background and Motivation IV. FluentCrypto V. Study Setup VI. Study Result VII. Threats to Validity VIII. Conclusion and References Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Background and Motivation III. Background and Motivation IV. FluentCrypto IV. FluentCrypto V. Study Setup V. Study Setup VI. Study Result VI. Study Result VII. Threats to Validity VII. Threats to Validity VIII. Conclusion and References VIII. Conclusion and References VI. STUDY RESULT This study showed that FluentCrypto helped participants to complete more crypto tasks in a shorter time compared to when they used the Node.js crypto API. Figure 3 presents the mean time that participants spent on each task as well as the perceived level of difficulty when dealing with each task. Notably, participants spent on average 43% shorter time to complete each task when they relied on FluentCrypto as compared to Node.js cryptography API. We also found that the participants succeeded to complete five more tasks when they relied on FluentCrypto. The investigation of the solutions revealed that there was no security issue in the ones developed for the first task. Only three solutions were secure when participants used Node.js cryptography API to develop the second and third tasks, whereas every solution developed with FluentCrypto was secure. We applied statistical tests to determine whether these findings are significant. We found that the p-values of all tests are smaller than 0.05 indicating that we can reject the null hypotheses. In other words, there is sufficient evidence with a high confidence to conclude that participants are more efficient to develop secure solutions when adopting FluentCrypto as compared to the Node.js crypto API. In general, participants perceived a higher level of difficulty as the tasks became more complex. We noted that the subjects mostly relied on the built-in crypto operations in FluentCrypto which handle low-level complexities. This could explain why the gain of using FluentCrypto increased with more complex task, especially, for novices who lacked programming experience or had limited crypto knowledge. Unexpectedly though, when dealing with Task 2, a couple of experienced developers perceived a higher level of difficulty with FluentCrypto than when they used the Node.js standard crypto library. However, these developers often completed their tasks faster when they used FluentCrypto. Moreover, participants rated the third task, on average, easier and spent shorter time on this task than the second task when they used the FluentCrypto. Although these two tasks are different, FluentCrypto is designed in such a way that the solutions are similar to implement. Therefore, what the subjects experienced earlier, especially when dealing with the second task, may have contributed to their success in the third task. In the following, we discuss the result of each task based on participant characteristics such as years of experience in programming, level of self-reported knowledge in cryptography, and prior experience with the Node.js crypto API. A. Does adopting FluentCrypto increase developer efficiency when working on a cryptographic task? A. Does adopting FluentCrypto increase developer efficiency when working on a cryptographic task? We discuss our findings regarding the time that participants invested in each task as well as the perceived level of difficulty. 1) Task 1: All participants solved the first task with both the Node.js crypto API and FluentCrypto. Table IIa explains the results regarding task one. The difficulty level looks similar among the groups but the time needed for the task increases for less experienced participants and decreases for more experienced participants. Nevertheless, the one participant who had more than 10 years’ programming experience completed the task with the help of the standard Node.js API three times faster than using the FluentCrypto. Table IIb and Table IIc reveal similar results based on the perceived level of cryptographic knowledge and experience with the Node.js crypto API. Similarly to our observation from the programming experience perspective, developers who had solid knowledge in cryptography as well as those who were familiar with the Node.js crypto API, completed the task faster than when they used the FluentCrypto. 1) Task 1: 2) Task 2: The second task was more challenging for participants than the first task. The overall perceived difficulty was increased and the task took more time to solve (see Table IIIb and Table IIIc). Two participants could not finish the task with Node.js crypto API, whereas everyone completed the task when using FluentCrypto. It is evident that FluentCrypto decreased the perceived difficulty for less experienced participants. The time taken to finalize the task when using FluentCrypto reduced for all participant groups except for the group “5-10 years of experience” (Table IIIa). 2) Task 2: 3) Task 3: The third task had the highest difficulty for the participants when using the Node.js crypto API (Table IVa). It also took on average more time to complete by participants than the other two tasks. FluentCrypto decreased the difficulty and time required to complete the task for all groups, especially for the less experienced group (Table IVb). FluentCrypto improved difficulty and the required time to solve the task for both participants with and without knowledge of Node.js crypto API (Table IVc). One of the senior participants who had beyond 10 years’ experience opted out of the study at this phase. When we asked the reason, he said “I must deal with an urgent matter at work”. Of the remaining participants, three failed to finish the task with Node.js crypto API, but everyone succeeded in this task when they used FluentCrypto. 3) Task 3: B. Is FluentCrypto effective in developing secure cryptographic solutions? B. Is FluentCrypto effective in developing secure cryptographic solutions? We manually assessed the security of each functioning solution against a check list of risks provided by a team of external security experts. We also checked any hindrances raised by the participants. 1) Task 1 : Participants were satisfied by the current Node.js documentation, but had difficulties in finding the right part of documentation for FluentCrypto. All participants chose the SHA256 algorithm when they used Node.js cryptography API. In case of FluentCrypto, participants either relied on the default secure algorithm specified by CryRule, or they provided their own choices that were acceptable by FluentCrypto. 1) Task 1 2) Task 2: The participants mostly complained about the Node.js documentation and mentioned that it is either incomplete or confusing, and consequently, they had to do additional research on the internet. When using FluentCrypto, one participant attempted to generate an IV for an unsupported cipher algorithm and was not satisfied with the thrown error message. 2) Task 2: A majority of participants who completed this task misused Node.js crypto API. Only two participants used a key that was not hardcoded, and others used a hardcoded secret from which they generated the key. None of the participants hardcoded a secret when they used FluentCrypto. They mostly relied on the provided call to generate a key. 3) Task 3: In Node.js crypto API, participants were unhappy about a lack of useful examples in the documentation and therefore, had to explore other information sources. They mainly had difficulties in grasping how to generate a key pair or how to use the keys. Conversely, developers appreciated the level of details in FluentCrypto documentation. What’s more, they found the solution very similar to what they followed while dealing with the previous task. Three participants also acknowledged that FluentCrypto is expressive e.g., “It is great that the name of an API speaks about its functionality” – a participant mentioned. 3) Task 3: Except one participant, the rest used hard-coded values to generate the key pairs when they used the Node.js cryptography API, which brings severe security risks. Two solutions also suffered from a small key size. In contrary, none of the FluentCrypto-based solutions suffered from these issues. The participants unanimously employed the secure default key-pair generation provided by FluentCrypto. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

FLUINT

fluint.io

1-10 employees

Since n.d.

COMPANY RANKING

FLUINT

EVERGREEN INDEX #4255

Representing this company? Click here to claim and customize this page!

Fluint WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

FLUINT

fluint.io

1-10 employees

Since n.d.

COMPANY RANKING

FLUINT

EVERGREEN INDEX #4255

RELATED COMPANIESRANK

STORIES ABOUT FLUINT

Representing this company? Click here to claim and customize this page!

Fluint WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!