Biblio

Phishing emails are becoming more and more sophisticated, making current detection techniques ineffective. The reporting of phishing emails from users is, thus, crucial for organizations to detect phishing attacks and mitigate their effect. Despite extensive research on how the believability of a phishing email affects detection rates, there is little to no research about the relationship between the believability of a phishing email and the associated reporting rate. In this work, we present a controlled experiment with 446 subjects to evaluate how the reporting rate of a phishing email is linked to its believability and detection rate. Our results show that the reporting rate decreases as the believability of the email increases and that around half of the subjects who detect the mail as phishing, have an intention to report the email. However, the group intending to report an email is not a subset of the group detecting the mail as phishing, suggesting that reporting is still a concept misunderstood by many.

Potentially dangerous cryptography errors are well-documented in many applications. Conventional wisdom suggests that many of these errors are caused by cryptographic Application Programming Interfaces (APIs) that are too complicated, have insecure defaults, or are poorly documented. To address this problem, researchers have created several cryptographic libraries that they claim are more usable, however, none of these libraries have been empirically evaluated for their ability to promote more secure development. This paper is the first to examine both how and why the design and resulting usability of different cryptographic libraries affects the security of code written with them, with the goal of understanding how to build effective future libraries. We conducted a controlled experiment in which 256 Python developers recruited from GitHub attempt common tasks involving symmetric and asymmetric cryptography using one of five different APIs. We examine their resulting code for functional correctness and security, and compare their results to their self-reported sentiment about their assigned library. Our results suggest that while APIs designed for simplicity can provide security benefits - reducing the decision space, as expected, prevents choice of insecure parameters - simplicity is not enough. Poor documentation, missing code examples, and a lack of auxiliary features such as secure key storage, caused even participants assigned to simplified libraries to struggle with both basic functional correctness and security. Surprisingly, the availability of comprehensive documentation and easy-to-use code examples seems to compensate for more complicated APIs in terms of functionally correct results and participant reactions, however, this did not extend to security results. We find it particularly concerning that for about 20% of functionally correct tasks, across libraries, participants believed their code was secure when it was not. Our results suggest that while ne- cryptographic libraries that want to promote effective security should offer a simple, convenient interface, this is not enough: they should also, and perhaps more importantly, ensure support for a broad range of common tasks and provide accessible documentation with secure, easy-to-use code examples.