Ongoing research into user authentication in public open source repositories demonstrates the importance of usability–even for IT professionals.
Open source software companies build products on the work of open source developers and free content creators. Products based on open source development may depend on hundreds of projects whose upstream developers have no relation to that company or its products. While we have many tools that provide code analysis, license tracking, and continuous integration—in keeping with today’s focus on the whole development supply chain—do we know who the independent developers upstream are and how they behave?
For open source software companies, improving the security of independent developers helps to prevent issues in the whole supply chain later. It is also quite crucial for enhancing the security of the entire open source ecosystem.
For this project, we focused on a simple piece in upstream development: authentication of independent developers on GitHub. No company policy for authentication binds these developers; no single sign-on is in place. How and if secure authentication will be used is entirely based on the project developers themselves.
Misusing a developer account can end in severe damage, and focusing only on detecting such incidents would be costly (and a response would come too late). There are many developers whose activity changes over a time period. For example, students may be active in some projects, focusing on new, exciting ideas, or developers may contribute only once. An upstream maintainer of a security-related project sees random attempts to get access to projects from unknown people or attempts to log in under existing developer accounts quite often. Strong authentication is crucial to prevent possible project tampering, which is inevitably followed by a loss of trust.
Do independent developers use strong authentication? What kind of strong authentication is considered user friendly, even in a situation when developers need to use recovery options? To start answering these questions, we asked developers at a large open source software company.
What do users actually use?
In our survey, participants were asked about their GitHub account usage, which type of projects they have maintained or contributed to in the last year, and whether they use any of the two-factor and fallback authentication methods offered by GitHub. The majority of them responded that they use two-factor authentication (and then have enabled fallback methods), which is a very positive finding. The authentication methods most often used as second factors were hardware and software tokens, with a larger representation of the software token. This could be influenced by the fact that our survey participants have to use hardware or software tokens for their internal single sign-on systems, so all of them have experience with at least one type of token. That experience could also influence their perception and willingness to use two-factor authentication in GitHub. Independent contributors who are not forced to use two-factor authentication for any other service could behave differently.
Among the developers we surveyed, some teams could use a GitHub subscription and have an authentication defined in team policies. In the survey, having a policy that specifies what GitHub authentication they should use was reported by 26 participants, while 37 reported not having such a policy, and 39 did not know. Since no survey participants were bound by an official company-wide policy regarding GitHub authentication, some policies are applicable only to some teams. A disturbing finding is that more than one-third of participants were not sure if there were any rules applicable for them. Both maintainers and contributors of open source and company projects were present in this group, as in the other two.
Another issue to keep in mind is that developers who responded to our questionnaire classified themselves as IT security savvy. It is possible that the questionnaire attracted responses from participants who consider security an important topic, so they are aware that it is important to constantly improve the security of open source repositories. If we have only this subsample of more aware users, the results for the whole population may not be as positive as the responses suggest, because two-factor authentication would be used only by IT security savvy users.
No Facebook for us!
The participants also perceived almost all offered authentication methods as (rather) positive in terms of usability and security. The only method perceived as not usable and not secure was using a Facebook account as a recovery option. For this method, we got the lowest number of answers; participants very often skipped this question. To be able to use this method, users must have an account on a specific social network. For recovery codes and fallback SMS codes, users do not need anything in addition to what they already have. In addition, Facebook is a third party for which users have to ensure security; if they use it only for GitHub, it could be perceived as burdensome. Nevertheless, for the users who already have a Facebook account, it could be perceived as a good fallback choice available just for a few clicks (which is also evident from the fact that few users rated it as very positive in terms of usability and security).
However, participants rated not only usability of a social network account as rather low, but security as well. These are not surprising results, because the security is outsourced to another company. And not just any company: Facebook has been in the news because of data breaches exposing users. In another user study about digital identity providers for online banking, our participants were not able to agree on any appropriate provider, but they were uniform in not wanting to use Facebook. As one participant said, “I would not trust Facebook; that is probably quite logical.” Respondents also mentioned that they interconnect their Facebook account only with not-so-important applications, such as applications monitoring exercise or e-shops. Facebook is a private-sector, international entity, which could be positive, because it works everywhere, but that also makes it hard to regulate and control the data processing. Further, when a user loses access to the account, access to interconnected accounts could also be lost. That raises another question: does deployment of a non-preferred authentication method influence user perception of the overall security of the secured website?
What Is Usable Security?
Usable security is commonly understood as an interdisciplinary approach in which the ultimate goal is to balance security and usability. The problem of balancing usability and security was first considered by two groups of researchers: Adams and Sasse1 and Whitten and Tygar.2 They pointed out that the reason users do not behave securely in the IT domain is a lack of usability in security systems. In the previous century, users were simply assumed to be careless about IT security, because security is not usually their primary goal. Then Adams and Sasse demonstrated the role of usability in the context of password policies. Near the same time, Whitten and Tygar revealed the importance of usability when researching how cryptography novices encrypt an email. That started the era of “Why can’t Johnny encrypt” studies, where even after many years there is still room for improvement. Their work shows that it is necessary to think about users when designing for IT security. For more details, see Martin Ukrop’s article “Don’t blame the developers: making security usable for IT professionals” in RHRQ 2:2.
Developer participation
To gather the data, we asked developers for participation primarily via internal mailing lists. We started distribution via mailing lists intended for non-official communication inside the company and the company newsletter. However, the response rate was very low: we got only 34 complete answers from 136 accesses to the questionnaire after one week. When the research was advertised via the official mailing lists from the research manager’s office, we got an additional 116 accesses with 55 complete responses in the following two weeks. The data were collected from November 9, 2020, until the end of the month.
Around 10,000 employees were recipients of the aforementioned mailings. Most of them met the survey entry conditions (having a GitHub account), and it was possible to fill it out during working hours. Even without looking at the results, we should think about possible interpretations of the response rate. The first possible explanation is that recipients simply overlooked this email in the number of incoming mails. This is understandable but problematic, because it is difficult to draw generalizable conclusions from the small number of answers.
Another possible explanation has more severe consequences. The low number of clicks on the link could indicate that the topic itself was not interesting enough to developers. If this were the real reason for the low response rate, that may indicate how users perceive the security of their GitHub accounts. Security emphasis is often on code integrity and related commit authorization, which is also an important topic. Fortunately, it has plenty of attention. However, user authentication is related to code integrity as well. When someone commits a code under a stolen identity, it could also have serious consequences.
Why GitHub?
We chose GitHub because it is one of the most used development platforms for open source. When there was a migration from GitHub to GitLab, we modified our questionnaire for GitLab users so participants who did not have a GitHub account could participate as well. However, we received only 3 answers from GitLab users, so we included only GitHub
Is usability for IT professionals necessary?
Most studies focus on regular end user authentication, where the problems are different than those of IT professionals. Regular end users often struggle with how to use a token at all, or sometimes have trouble installing a software token into their smartphone, which may prevent them from using it. By contrast, some may consider IT developers or other tech professionals to be more skillful and more aware of IT security than regular end users, so there is no need to focus on their understanding of strong authentication. However, one of the top three endpoint security risks in 2019 was a “compromise of privileged users or system administrators.”3
As discussed above, compromising the account of an independent developer can severely damage a project or company. At GitHub, breached credentials were used to attack the repositories,4 and a Microsoft GitHub account was hacked,5 proving that the risk is serious. We have to keep in mind that not every IT professional is trained in IT security. And even if there is not a barrier such as, for example, using cryptographic libraries during coding, we cannot assume that IT professionals use the most secure authentication methods simply because they probably know how. In fact, even the studies of IT security experts demonstrate that while IT security professionals follow security recommendations more often than regular end users, usability is an important factor for them as well.
Building secure products
Contributions from many volunteers or external developers are among the most important factors for the success of projects based on open source. For open source software companies, improving the security of independent developers helps to prevent issues in the whole supply chain later. It is also quite crucial for enhancing the security of the entire open source ecosystem. We hope that our research helps to highlight the importance of secure authentication in public repositories for our future product security. More detailed results will be part of the academic publication. When the results are published, the link will be available at Red Hat Research on the project page.
Acknowledgements
Thanks are due to Vashek Matyáš for supervision, Red Hat for support, and last but not least all those who participated in the survey and/or shared their comments via e-mails with us.
1 Anne Adams and Angela Sasse, “Users are not the enemy,” Communications of the ACM 42 (1999):
40–46. Available from doi:10.1145/322796.322806.
2 Alma Whitten and Doug Tygar, “Why Johnny can’t encrypt: a usability evaluation of PGP 5.0,” Proceedings of the 8th Conference on USENIX Security Symposium 8 (1999): 169-83.
3Jai Vijayan, “Assessing cybersecurity risk in today’s enterprises,” Dark Reading Reports, October 2019. https://www.anomali.com/files/Dark_Reading_Assessing_Cybersecurity_Risk_in_Todays_Enterprises_Research_Report_Anomali.pdf
4Michael Mimoso, “Breached credentials used to access GitHub repositories,” Threatpost, June 17, 2016. https://threatpost.com/breached-credentials-used-to-access-github-repositories/118746/
5Elizabeth Montalbano, “Report: Microsoft’s GitHub account gets hacked,” Threatpost, May 8, 2020. https://threatpost.com/report-microsofts-github-account-gets-hacked/155587/