Why Johnny Can't Store Passwords Securely? A Usability Evaluation of Bouncycastle Password Hashing
•Download as PPTX, PDF•
0 likes•197 views
Slides I used to present our paper "Why Johnny Can't Store Passwords Securely? " at Evaluation and Assessment in Software Engineering (EASE) 2018 Conference. The full paper can be accessed at https://arxiv.org/ftp/arxiv/papers/1805/1805.09487.pdf
More Related Content
What's hot
What's hot (20)
Similar to Why Johnny Can't Store Passwords Securely? A Usability Evaluation of Bouncycastle Password Hashing
Similar to Why Johnny Can't Store Passwords Securely? A Usability Evaluation of Bouncycastle Password Hashing (20)
More from Chamila Wijayarathna
More from Chamila Wijayarathna (20)
Recently uploaded
Recently uploaded (20)
Why Johnny Can't Store Passwords Securely? A Usability Evaluation of Bouncycastle Password Hashing
- 1. Why Johnny Can’t Store Passwords Securely? A Usability Evaluation of Bouncy Castle Password Hashing Chamila Wijayarathna, Dr. Nalin Asanka Gamagedara Arachchilage School of Engineering and IT University of New South Wales Australia
- 2. • Password breaches at major companies have affected billions of user accounts.
- 3. Cryptography is hard for programmers.
- 4. Research Questions. • What are the usability issues exist in the password hashing functionality of Bouncy Castle API? • How those issues affect the security of the applications that programmers develop?
- 5. Methodology Identified issues by analyzing recordings, code artifacts and questionnaire responses Participant completed cognitive dimensions questionnaire based on their experience with the API Participant completed programming task while thinking aloud and recording their screen Designed a programming task that use the password hashing functionality of Bouncy Castle API. Participant signed up and completed demographic questionnaire and consent form
- 6. Study Results • Identified 63 usability issues of Bouncy Castle SCrypt password hashing. • Average 15 usability issues were encountered by each participant.
- 7. Selecting parameters for Scrypt.generate() method • Difficult to understand meaning of method parameters. • Difficult to select correct values for these parameters. • IDE suggestions does not help to understand parameters and select correct values.
- 8. Issues encountered related to Salt • Using a salt when hashing passwords helps to defend against dictionary attacks and pre-computed rainbow attacks. • Participants used constant values for salt, because their lack of knowledge in salt and other related security concepts. • API did not help participants to identify their mistakes.
- 9. Issues of API Documentation • Lack of sufficient documentation to refer. • Difficult to find existing documentation. • No enough usage examples. • Google search results do not show official documentation at the top.
- 10. Usage of Byte Array vs. String • Byte arrays and char arrays are recommended over Strings to store passwords because while using Strings, password will be stored in the memory for longer and cannot be deleted until garbage collector clears them. • Some participants used string to save passwords before/after calling the API, which made the application’s security weak.
- 11. Where to Improve? • Provide programmers with overloaded Scrypt.generate() method o Byte[] Scrypt.generate (byte[] password, byte[] salt) o Object Scrypt.generate (byte[] password) • Improve documentation • Include more examples for documentation
- 12. Questions ?
- 14. “Security API is an application programming interface that provides developers with security functionalities that enforce one or more security policies on the interaction between at least two entities.” Gorski and Iacono (2016) P. L. Gorski and L. L. Iacono, “Towards the usability evaluation of security apis,”, In HAISA 2016. 252–265.
Editor's Notes
- Good morning, I am chamila wijayarathna, I am a PhD student from University of New South Wales, Australia. In this presentation, I am going to present our work, Why Johny Can’t store passwords securely, A usability evaluation of Bouncy Castle Password Hashing This paper is co-authored by Dr. Nalin Asanka.
- Security breaches related to stealing passwords are an increasingly common problem and have affected billions of people. These are some of the popular organizations that faced this issue in recent years. However, there are so many technologies, algorithms, etc introduced every now and then to protect user passwords from attacker. Despite these mechanisms, it appears that some software applications are still contain vulnerabilities that open backdoors for attackers to steal user passwords.
- So, why applications still contain vulnerabilities when there are many technologies to protect those applications from attackers. One of the main reasons for this is that programmers have been unable to use these technologies correctly when developing applications, Especially they have been unable to correctly use Application Programming Interfaces that provide security functionalities. Research has found that most programmers involved in the software development process are not experts of security. these non expert programmers find it difficult to use security APIs correctly, when they are not usable, Hence results in using security APIs incorrectly and leave their applications vulnerable to attacks. In this study, we attempted to evaluate the usability of a security API, that provides functionalities to secure passwords of application, Bouncy Castle API. Bouncycastle is a vastly used open source API that provides a variety of cryptographic functionalities. In this study, we mainly expected to evaluate the usability of the password hashing functionality of Bouncy castle API, and identify usability issues of it.
- We mainly tried to identify What are the usability issues exist in the password hashing functionality of Bouncy Castle API And how those issues affect the security of applications that programmers develop using the API.
- To answer these two questions, we conducted a user study based usability evaluation for the Bouncy Castle API. This diagram shows a summary of the methodology we followed. In this study, few programmers completed a programming task using the Bouncy Castle API, And we tried to identify usability issues they encountered by observing them and from the feedback they gave. So, first we designed a task for participants to follow. Bouncy castle has a number of different password hashing algorithm implementations, Designing a task to evaluate all of them in one study was not a feasible thing, So we selected to evaluate Scrypt hashing implementation of Bouncy castle API. Scrypt was the most secure password hashing algorithm implementation available in Bouncycastle at the time we conducted the study. The task was to securely store passwords of a web application that has user registration and login functionalities. We provided them source code for an application that stores passwords insecurely in plain text, and asked them to secure password storage by hashing passwords using Bouncy castle’s Scrypt functionality. We needed software developers to participate in the study. We identified Java developers from Github and invited them to participate. Response rate was low, since software developers are busy people. This is a common issue in this area of research. Once they signed up, we sent them guidelines and study material. They participated remotely, using their own equipment. We asked them to think-aloud while completing the task, and they recorded their screens with voice. Once they completed the task, they had to answer the cognitive dimensions questionnaire. This was developed by us previously, by improving a questionnaire that was proposed to evaluate the usability of general APIs. Cognitive dimensions questionnaire method is a common method used to identify usability issues of applications as well as of APIs. Then we analysed questionnaire responses, screen recordings and code artifacts and identified usability issues of the API from them.
- A total of 10 programmers participated in the study. We could identify 63 usability issues of the API, Average of 15 issues were identified from the results of each participant. Some of these issues caused participants to make choices that are incorrect and hence reduced the security of programmes they developed. Some of the issues just reduced their efficiency. Our main focus for discussion is the issues that affected the security of developed solutions.
- Scrypt password hashing of bouncy castle API is exposed to programmer via the static generate method of Scrypt class. This method invocation requires 6 parameters, which are password, salt, work factor, blocksize for underline hash, parallelization factor and length of key to generate. We observed that participants of our study found it difficult to understand meanings of the last 4 parameters. These 4 parameters decides the cost of generating the hash from password. Selecting weaker values for them would make it less costly for attackers to perform attacks, and hence make the security of the application weak. Not having a proper idea about these parameters made it difficult for participants to select proper values for these parameters. There was not much help available for selecting proper parameters either. Specially, participants expected to see more information about how strength of the hash and processing time varies with these parameters.
- Other than those 4 parameters, participants also incorrectly used salt parameter. Using salt in password hashing makes passwords more secure, specially against dictionary attacks and pre computed rainbow attacks. To achieve this, API expected programmers to use unique salt for every user and save it with the password hash. But some participants used same value among all users of the application as the salt value. This made having a salt value useless. Main reason for this mistake was the lack of security knowledge of the programmers. Also, there was not much guidance available and participants had no way to identify that they are using it incorrectly.
- Many participants encountered issues related to API documentation. There was not much information available about using the particular functionality, other than few StackOverflow discussions and API java doc. Specially, information about method parameters was difficult to find. Participants had to put some effort to find details about using the API which reduced their efficiency. Most participants expected to see some examples on using the functionality, in their learning process. But it was difficult to find enough examples, which made it difficult to get a good understanding about using the API. This made it difficult to use the API correctly. Furthermore, we observed that, when programmers search Google to get help, Top results popped up were from third parties such as Stack Overflow. Some of the third party resources they used had some incorrect solutions. Some had used parameter values without giving a proper explanation, which made participants to use those values assuming that they are recommended. Even though, this is not something directly related to the API, it definitely reduced the effectiveness of using the API and therefore reduced the usability of it.
- Finally, as same as other Java crypto APIs, Bouncy castle also used Byte arrays as the data type for allocating memory for passwords This is considered secure and recommended. However, participants preferred using Strings, Therefore, this reduced their satisfaction on the API. Furthermore, some of them intermediately used Strings to save passwords, before and after using the API, which reduced the security of their application. Bouncy castle API or if we more generally talk about Java APIs, they should consider this and provide more usable options for programmers to use them effectively and in a way that make them satisfied.
- Some participants suggested some improvements for the API also, to improve its usability. These are only suggestions and need to study more to see whether they actually work, or whether they have any tradeoffs: Most participants who faced difficulties with method parameters of Scrypt.generate method, suggested that API should provide overloaded method options with less parameters, These are the two options they suggested, They wanted the API to use defaults with values that suits majority of hardware. They also suggested to improve API documentation and include more examples in to the documentation.
- However, programmers are not required to implement all the security related stuff that are required for their applications. Most of them are already there, Developed by security experts, And made available to use for non expert programmers via security APIs Non-expert programmers can use those functionalities to embed security into their applications via these security APIs. For password protection also, there are so many security APIs that provide required functionalities. So why programmers still make mistakes, making their applications vulnerable? Security APIs that programmers use being not usable, is one of the reasons for this. When security APIs are not usable, programmers find it difficult to use them correctly, Hence results in using them incorrectly and Leave their applications vulnerable to attacks. In this study, we attempted to evaluate the usability of a security API, that provides functionalities to secure passwords of applications from attackers, Bouncy Castle API. Bouncycastle is a vastly used open source API that provides a variety of cryptographic functionalities. In this study, we mainly expected to evaluate the usability of the password hashing functionality of Bouncy castle API, and identify usability issues of it.