Connect with us

Security

Study shows programmers will take the easy way out and not implement proper password security

Published

on

Freelance developers need to be explicitly told to write code that stores passwords in a safe and secure manner, a recent study has revealed.

In an experiment that involved 43 programmers hired via the Freelancer.com platform, University of Bonn academics have discovered that developers tend to take the easy way out and write code that stores user passwords in an unsafe manner.

For their study, the German academics asked a group of 260 Java programmers to write a user registration system for a fake social network.

Of the 260 developers, only 43 took up the job, which involved using technologies such as Java, JSF, Hibernate, and PostgreSQL to create the user registration component.

Of the 43, academics paid half of the group with €100, and the other half with €200, to determine if higher pay made a difference in the implementation of password security features.

Further, they divided the developer group a second time, prompting half of the developers to store passwords in a secure manner, and leaving the other half to store passwords in their preferred method –hence forming four quarters of developers paid €100 and prompted to use a secure password storage method (P100), developers paid €200 and prompted to use a secure password storage method (P200), devs paid €100 but not prompted for password security (N100), and those paid €200 but not prompted for password security (N200).


Image: Naiakshina et al.

Researchers said developers took three days to submit their work, and that they had to ask 18 of the 43 to resubmit their code to include a password security system when they first sent a project that stored passwords in plaintext.

Of the 18 who had to resubmit their code, 15 developers were part of the group that were never told the user registration system needed to store password securely, showing that developers don’t inherently think about security when writing code.

Not-prompted results

Image: Naiakshina et al.

The other three were from the half that was told to use a secure method to store passwords, but who stored passwords in plaintext anyway.

Prompted results

Image: Naiakshina et al.

The results show that the level of understanding of what “secure passwords” mean differs greatly in the web development community.

Of the secure password storage systems developers chose to implement for this study, only the last two, SHA-256 and Bcrypt, are considered secure.

8 – Base64
10 – MD5
1 – SHA-1
3 – 3DES
3 – AES
5 – PBKDF2
1 – HMAC/SHA1
5 – SHA-256
7 – Bcrypt

The first, Base64, isn’t even an encryption algorithm, but an encoding function, something that the participating developers didn’t seem to know. Similarly for MD5, which is a hashing function.

“Many participants used hashing and encryption as synonyms,” the team of academics said in their research paper.

“Of the 18 participants who received the additional security request, 3 decided to use Base64 and argued, for example: ‘[I] encrypted it so the clear password is not visible’ and ‘It is very tough to decrypt’,” researcher said –highlighting that some study participants didn’t know the basic difference between an encryption algorithm and a function that just jumbles characters around.

Furthermore, only 15 of the 43 developers chose to implement salting, a process through which the encrypted password stored inside an application’s database is made harder to crack with the addition of a random data factor.

The study also found that 17 of the 43 developers copied their code from internet sites, suggesting that the freelancers didn’t have the necessary skills to develop a secure system from scratch, and chose to use code that might be outdated or even riddled with bugs.

Paying developers higher rates didn’t help considerably, researchers said.

However, the research team found that giving programmers specific instructions to implement a secure password storage system did yield better results than not saying anything at all and then expecting developers to think of security by themselves.

Nonetheless, without precise instructions, developers choose what they “believed” was a secure password storage system, but in reality, was not, suggesting that oversight from a professional is needed when designing any type of security system.

The study’s results clearly show that each freelance developer’s knowledge of cyber-security best practices varies wildly from person to person. This might be to outdated training or no training at all –yet again making a case against using developers without cyber-security experience for such jobs.

Attacks against encryption algorithms have been disclosed left and right in the past two decades, and something a developer might have learned in an outdated school manual might not stand scrutiny today. A good starting point for better password practices is this OWASP cheat sheet.

More details on this University of Bonn study are available in the research paper entitled “‘If you want, I can store the encrypted password.’ A Password-Storage Field Study with Freelance Developers.”

This study is a continuation of two similar studies –from 2017 and 2018— that used students as subjects, instead of freelance developers.

In the previous studies, students said they would have implemented secure password storage if they were creating code for a company.” The 2019 study showed that current developers aren’t any better than unsupervised students.

More cyber-security reports:



Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Security

GigaOm Radar for Unified Endpoint Management (UEM)

Published

on

Endpoint management is one of the most significant challenges enterprises face today. The modern workforce is becoming more distributed and demanding the flexibility to work where they want, when they want. Business leaders must respond to this demand and provide access to the services employees require, while also maintaining security and control of the business’s data assets.

To address these issues, organizations need an appropriate endpoint management strategy. The modern approach should be holistic and unified, bringing together control of devices, management of applications, security of data, and user access controls. Failing to deliver an effective endpoint strategy can have significant business impact, negatively affecting efficiency and competitiveness. Now, more than ever, the inability to offer a positive and flexible end user experience can make a business less attractive to potential employees.

The management of endpoint devices is not a new challenge; however, the way we operate has changed. This is reflected clearly in how market-leading vendors have shifted their approach, moving from “point solutions” to developing unified endpoint management (UEM) solutions. UEM solutions provide a single platform to manage a wide variety of endpoints, from desktops and laptops to cloud repositories. They offer granular control policies from configuration and applications to security based on geography, and from complete device restrictions to nuanced data controls.

This GigaOM radar report evaluates the leading UEM vendors that can underpin your endpoint management strategy. We look at tools that effectively meet the demands of the modern enterprise by providing robust management, security, and control. This report aims to give enterprise decision makers an overview of how these offerings can help address the complex challenge of endpoint management.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post GigaOm Radar for Unified Endpoint Management (UEM) appeared first on Gigaom.

Continue Reading

Security

Key Criteria for Evaluating Deception Technology

Published

on

Attacker techniques and behaviors are constantly improving and evolving. As cyber security defenses zig, attackers zag. This dynamic creates a changed environment—what worked in the past to detect malicious actions most likely won’t work today or in the future. Deception technology (DT) tackles this quandary head on and provides defenders the ability to set traps for attackers and to gather valuable information for making better decisions.

Historically, DT would be executed in the form of either a honeypot or a sandbox. A honeypot is a trap set by defenders to emulate a real device in the network, while a sandbox is a virtual environment meant to deceive malware and allow analysis of the malware post-exploitation without endangering the organization.

Today, DT is described in much broader terms. Legacy DT solutions that attempt to emulate typical on-premises infrastructure like Linux and Windows hosts are ill fitting for modern organizations that have no perimeter or physical data centers. Components like cloud, SDN, remote workers, and the need for forensic analysis of attacker techniques have driven the evolution of DT to include features like mapping to the MITRE ATT&CK or SHIELD frameworks, low-code/no-code customization, and leveraging bait or lures for agentless deception.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post Key Criteria for Evaluating Deception Technology appeared first on Gigaom.

Continue Reading

Security

Key Criteria for Evaluating Developer Security Tools

Published

on

Software needs to be written, built, and deployed with security in mind. This is true for both the application being created and the activities involved in its creation. In an ideal world, developers would be security engineers also and would build appropriate risk-mitigation features into their software applications, as well as follow appropriate procedures and apply policies to mitigate potential risk. The reality for many organizations, however, is that the urgency for software updates or new software often outweighs the ability to apply appropriate security at every step throughout the development and operation of a software product’s lifecycle.

Expanding the DevOps movement by considering security alongside every development or operational step in an application’s lifecycle, DevSecOps has become as popular a term as DevOps itself. Unfortunately, just as with DevOps, DevSecOps is not a single product or SKU that an organization can procure. There is no “one-size-fits-all” approach. The term itself may be defined differently to take into account the specific needs of an organization or department and touches all people, processes, and tooling across a software development workflow.

One key approach, often the one most associated with the term “DevSecOps,” is the focus on development security tools with a “shift-left” mindset; that is, tools that consider security as early as possible in the software development lifecycle. This mindset involves rapid security education, insights, and direct feedback to developers and engineers early in the development process. We describe this in more detail later.

This Key Criteria report examines the capabilities and trends that decision makers should look for when adopting that shift-left mindset to increase application security and release velocity, while reducing cost and risk.

The report also considers how to evaluate vendors’ capabilities to provide security-related insights, automation, and compliance closer to the developer—earlier in the development workflow—addressing ways to reduce risk while writing code, storing code, and deploying it across process and pipeline. Among our findings:

  • Development security tooling reduces risk and increases developer velocity by applying and enforcing “shift-left” security practices.
  • Developer security tooling automation can close the gap between security engineers and developers without sacrificing development speed.
  • Developer security tooling integrates with existing development and operational tools to increase the visibility of security-related events across development, operations, and security teams.
  • Developer security tooling delivers value by building on software and architecture (cloud and on-prem) vulnerability scanning, application and infrastructure hardening, and other well-established areas of IT security.

Developer security tools and a “shift-left” mindset are key building blocks for helping enterprises reduce the security risks associated with building and deploying applications. In addition to establishing security as a first-class citizen across the development workflow, this approach offers more traditional enterprises with long-established software development practices a connection point to leading-edge best practices, enabling them to develop and deliver software both quickly and in compliance with organizational policies.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post Key Criteria for Evaluating Developer Security Tools appeared first on Gigaom.

Continue Reading

Trending