An Evaluation of Secure Storage of Authentication Data
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Argon and Argon2
Argon and Argon2 Designers: Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich University of Luxembourg, Luxembourg [email protected], [email protected], [email protected] https://www.cryptolux.org/index.php/Password https://github.com/khovratovich/Argon https://github.com/khovratovich/Argon2 Version 1.1 of Argon Version 1.0 of Argon2 31th January, 2015 Contents 1 Introduction 3 2 Argon 5 2.1 Specification . 5 2.1.1 Input . 5 2.1.2 SubGroups . 6 2.1.3 ShuffleSlices . 7 2.2 Recommended parameters . 8 2.3 Security claims . 8 2.4 Features . 9 2.4.1 Main features . 9 2.4.2 Server relief . 10 2.4.3 Client-independent update . 10 2.4.4 Possible future extensions . 10 2.5 Security analysis . 10 2.5.1 Avalanche properties . 10 2.5.2 Invariants . 11 2.5.3 Collision and preimage attacks . 11 2.5.4 Tradeoff attacks . 11 2.6 Design rationale . 14 2.6.1 SubGroups . 14 2.6.2 ShuffleSlices . 16 2.6.3 Permutation ...................................... 16 2.6.4 No weakness,F no patents . 16 2.7 Tweaks . 17 2.8 Efficiency analysis . 17 2.8.1 Modern x86/x64 architecture . 17 2.8.2 Older CPU . 17 2.8.3 Other architectures . 17 3 Argon2 19 3.1 Specification . 19 3.1.1 Inputs . 19 3.1.2 Operation . 20 3.1.3 Indexing . 20 3.1.4 Compression function G ................................. 21 3.2 Features . 22 3.2.1 Available features . 22 3.2.2 Server relief . 23 3.2.3 Client-independent update . -
Passwordless Authentication: How Giving up Your Password Might Make You More Secure
thalesgroup.com Passwordless Authentication: How Giving Up Your Password Might Make You More Secure White Paper Why Passwords Are Bad Passwords are one of the oldest security tools in the world of software and the internet. But in today’s environment, passwords cannot provide enough protection for businesses for several reasons. Password Fatigue Leads to Bad Hygiene Policy-driven password strengths and rotation leads to password fatigue, thereby contributing to poor password management. Verizon’s Data Breach Investigation Report1 indicates that over 70 percent of employees reuse passwords for work and personal accounts. A malicious actor could therefore abuse an employee’s credentials to access other applications and sensitive customer information. % out “123456” 81 ~40 4 of 5 “password” of breaches involve Average person People reuse same still among most use of weak or has roughly 40 passwords across popular password stolen credentials online accounts dierent accounts choices in 2018 People also tend to pick easy-to-hack passwords because of the trouble they have with remembering passwords. An analysis of over five million leaked passwords showed that 10 percent of people used one of the 25 worst passwords2. Seven percent of enterprise users had extremely weak passwords. Passwords Hurt User Experience Research by Carnegie Mellon University indicates that a properly written password policy can provide an organization with increased security. However, there is less accord over what should be in this policy to make it effective. To illustrate this fact, users commonly react to a policy rule that requires them to include numbers by picking the same number or by using the number in the same location in their passwords3. -
CASH: a Cost Asymmetric Secure Hash Algorithm for Optimal Password Protection
CASH: A Cost Asymmetric Secure Hash Algorithm for Optimal Password Protection Jeremiah Blocki Anupam Datta Microsoft Research Carnegie Mellon University August 23, 2018 Abstract An adversary who has obtained the cryptographic hash of a user's password can mount an offline attack to crack the password by comparing this hash value with the cryptographic hashes of likely password guesses. This offline attacker is limited only by the resources he is willing to invest to crack the password. Key-stretching techniques like hash iteration and memory hard functions have been proposed to mitigate the threat of offline attacks by making each password guess more expensive for the adversary to verify. However, these techniques also increase costs for a legitimate authentication server. We introduce a novel Stackelberg game model which captures the essential elements of this interaction between a defender and an offline attacker. In the game the defender first commits to a key-stretching mechanism, and the offline attacker responds in a manner that optimizes his utility (expected reward minus expected guessing costs). We then introduce Cost Asymmetric Secure Hash (CASH), a randomized key-stretching mechanism that minimizes the fraction of passwords that would be cracked by a rational offline attacker without increasing amortized authentication costs for the legitimate authentication server. CASH is motivated by the observation that the legitimate authentication server will typically run the authentication procedure to verify a correct password, while an offline adversary will typically use incorrect password guesses. By using randomization we can ensure that the amortized cost of running CASH to verify a correct password guess is significantly smaller than the cost of rejecting an incorrect password. -
Modern Password Security for System Designers What to Consider When Building a Password-Based Authentication System
Modern password security for system designers What to consider when building a password-based authentication system By Ian Maddox and Kyle Moschetto, Google Cloud Solutions Architects This whitepaper describes and models modern password guidance and recommendations for the designers and engineers who create secure online applications. A related whitepaper, Password security for users, offers guidance for end users. This whitepaper covers the wide range of options to consider when building a password-based authentication system. It also establishes a set of user-focused recommendations for password policies and storage, including the balance of password strength and usability. The technology world has been trying to improve on the password since the early days of computing. Shared-knowledge authentication is problematic because information can fall into the wrong hands or be forgotten. The problem is magnified by systems that don't support real-world secure use cases and by the frequent decision of users to take shortcuts. According to a 2019 Yubico/Ponemon study, 69 percent of respondents admit to sharing passwords with their colleagues to access accounts. More than half of respondents (51 percent) reuse an average of five passwords across their business and personal accounts. Furthermore, two-factor authentication is not widely used, even though it adds protection beyond a username and password. Of the respondents, 67 percent don’t use any form of two-factor authentication in their personal life, and 55 percent don’t use it at work. Password systems often allow, or even encourage, users to use insecure passwords. Systems that allow only single-factor credentials and that implement ineffective security policies add to the problem. -
The Tangled Web of Password Reuse
The Tangled Web of Password Reuse Anupam Das∗, Joseph Bonneauy, Matthew Caesar∗, Nikita Borisov∗ and XiaoFeng Wangz ∗University of Illinois at Urbana-Champaign fdas17, caesar, [email protected] yPrinceton University [email protected] zIndiana University at Bloomington [email protected] Abstract—Today’s Internet services rely heavily on text-based password meters to help users understand the strength of their passwords for user authentication. The pervasiveness of these passwords. Studies have shown that password composition services coupled with the difficulty of remembering large numbers policies along with password meters (or verbal notifications) of secure passwords tempts users to reuse passwords at multiple do help users to choose stronger passwords [35], [44], [46]. sites. In this paper, we investigate for the first time how an However, they also increase user fatigue. attacker can leverage a known password from one site to more easily guess that user’s password at other sites. We study several Unfortunately, the number of passwords a user must re- hundred thousand leaked passwords from eleven web sites and member continues to increase, with typical Internet user es- conduct a user survey on password reuse; we estimate that 43- timated to have 25 distinct online accounts [10], [11], [32]. 51% of users reuse the same password across multiple sites. Because of this, users often reuse passwords across accounts We further identify a few simple tricks users often employ to on different online services. Password reuse introduces a secu- transform a basic password between sites which can be used by an attacker to make password guessing vastly easier. We develop the rity vulnerability as an attacker who is able to compromise one first cross-site password-guessing algorithm, which is able to guess service can compromise other services protected by the same 30% of transformed passwords within 100 attempts compared to password, reducing overall security to that of the weakest site. -
Rifflescrambler – a Memory-Hard Password Storing Function ⋆
RiffleScrambler – a memory-hard password storing function ? Karol Gotfryd1, Paweł Lorek2, and Filip Zagórski1;3 1 Wrocław University of Science and Technology Faculty of Fundamental Problems of Technology Department of Computer Science 2 Wrocław University Faculty of Mathematics and Computer Science Mathematical Institute 3 Oktawave Abstract. We introduce RiffleScrambler: a new family of directed acyclic graphs and a corresponding data-independent memory hard function with password independent memory access. We prove its memory hard- ness in the random oracle model. RiffleScrambler is similar to Catena – updates of hashes are determined by a graph (bit-reversal or double-butterfly graph in Catena). The ad- vantage of the RiffleScrambler over Catena is that the underlying graphs are not predefined but are generated per salt, as in Balloon Hashing. Such an approach leads to higher immunity against practical parallel at- tacks. RiffleScrambler offers better efficiency than Balloon Hashing since the in-degree of the underlying graph is equal to 3 (and is much smaller than in Ballon Hashing). At the same time, because the underlying graph is an instance of a Superconcentrator, our construction achieves the same time-memory trade-offs. Keywords: Memory hardness, password storing, Markov chains, mixing time. 1 Introduction In early days of computers’ era passwords were stored in plaintext in the form of pairs (user; password). Back in 1960s it was observed, that it is not secure. It took around a decade to incorporate a more secure way of storing users’ passwords – via a DES-based function crypt, as (user; fk(password)) for a se- cret key k or as (user; f(password)) for a one-way function. -
Hash Functions
11 Hash Functions Suppose you share a huge le with a friend, but you are not sure whether you both have the same version of the le. You could send your version of the le to your friend and they could compare to their version. Is there any way to check that involves less communication than this? Let’s call your version of the le x (a string) and your friend’s version y. The goal is to determine whether x = y. A natural approach is to agree on some deterministic function H, compute H¹xº, and send it to your friend. Your friend can compute H¹yº and, since H is deterministic, compare the result to your H¹xº. In order for this method to be fool-proof, we need H to have the property that dierent inputs always map to dierent outputs — in other words, H must be injective (1-to-1). Unfortunately, if H is injective and H : f0; 1gin ! f0; 1gout is injective, then out > in. This means that sending H¹xº is no better/shorter than sending x itself! Let us call a pair ¹x;yº a collision in H if x , y and H¹xº = H¹yº. An injective function has no collisions. One common theme in cryptography is that you don’t always need something to be impossible; it’s often enough for that thing to be just highly unlikely. Instead of saying that H should have no collisions, what if we just say that collisions should be hard (for polynomial-time algorithms) to nd? An H with this property will probably be good enough for anything we care about. -
Cs 255 (Introduction to Cryptography)
CS 255 (INTRODUCTION TO CRYPTOGRAPHY) DAVID WU Abstract. Notes taken in Professor Boneh’s Introduction to Cryptography course (CS 255) in Winter, 2012. There may be errors! Be warned! Contents 1. 1/11: Introduction and Stream Ciphers 2 1.1. Introduction 2 1.2. History of Cryptography 3 1.3. Stream Ciphers 4 1.4. Pseudorandom Generators (PRGs) 5 1.5. Attacks on Stream Ciphers and OTP 6 1.6. Stream Ciphers in Practice 6 2. 1/18: PRGs and Semantic Security 7 2.1. Secure PRGs 7 2.2. Semantic Security 8 2.3. Generating Random Bits in Practice 9 2.4. Block Ciphers 9 3. 1/23: Block Ciphers 9 3.1. Pseudorandom Functions (PRF) 9 3.2. Data Encryption Standard (DES) 10 3.3. Advanced Encryption Standard (AES) 12 3.4. Exhaustive Search Attacks 12 3.5. More Attacks on Block Ciphers 13 3.6. Block Cipher Modes of Operation 13 4. 1/25: Message Integrity 15 4.1. Message Integrity 15 5. 1/27: Proofs in Cryptography 17 5.1. Time/Space Tradeoff 17 5.2. Proofs in Cryptography 17 6. 1/30: MAC Functions 18 6.1. Message Integrity 18 6.2. MAC Padding 18 6.3. Parallel MAC (PMAC) 19 6.4. One-time MAC 20 6.5. Collision Resistance 21 7. 2/1: Collision Resistance 21 7.1. Collision Resistant Hash Functions 21 7.2. Construction of Collision Resistant Hash Functions 22 7.3. Provably Secure Compression Functions 23 8. 2/6: HMAC And Timing Attacks 23 8.1. HMAC 23 8.2. -
Nfront Password Filter Documentation 2
nFront Password Filter Multiple Policy Edition for Domain Controllers Single Policy Edition for Domain Controllers Single Policy Edition for Member Servers Multiple Policy Edition for Member Servers Desktop Edition Version 7.1.0 © 2000 – 2021 nFront Security. Documentation All Rights Reserved. nFront Security, the nFront Security logo and nFront Password Filter are trademarks of Altus Network Solutions, Inc. All other trademarks or registered trademarks are the property of their Copyright © 2021 nFront Security. All Rights Reserved. Contents 1.0 nFront Password Filter Overview ........................................................................... 2 1.1 Versions ................................................................................................................. 2 1.2 Compatibility and System Requirements ................................................................ 3 1.3 What’s New ............................................................................................................ 4 1.3 Notes to Evaluators ................................................................................................ 5 1.4 Overview of Features ............................................................................................. 7 1.4.1 The logic behind multiple policies (MPE version only) ................................................... 8 1.4.2 The Message Box for Rejected Passwords ...................................................................... 8 1.5 Information about your Evaluation Copy. ............................................................... -
Sketch of Lecture 34 Mon, 4/16/2018
Sketch of Lecture 34 Mon, 4/16/2018 Passwords Let's say you design a system that users access using personal passwords. Somehow, you need to store the password information. The worst thing you can do is to actually store the passwords m. This is an absolutely atrocious choice, even if you take severe measures to protect (e.g. encrypt) the collection of passwords. Comment. Sadly, there is still systems out there doing that. An indication of this happening is systems that require you to update passwords and then complain that your new password is too close to the original one. Any reasonably designed system should never learn about your actual password in the rst place! Better, but still terrible, is to instead store hashes H(m) of the passwords m. Good. An attacker getting hold of the password le, only learns about the hash of a user's password. Assuming the hash function is one-way, it is infeasible for the attacker to determine the corresponding password (if the password was random!!). Still bad. However, passwords are (usually) not random. Hence, an attacker can go through a list of common passwords (dictionary attack), compute the hashes and compare with the hashes of users (similarly, a brute-force attack can simply go through all possible passwords). Even worse, it is immediately obvious if two users are using the same password (or, if the same user is using the same password for dierent services using the same hash function). Comment. So, storing password hashes is not OK unless all passwords are completely random. -
A Survey of Password Attacks and Safe Hashing Algorithms
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 04 Issue: 12 | Dec-2017 www.irjet.net p-ISSN: 2395-0072 A Survey of Password Attacks and Safe Hashing Algorithms Tejaswini Bhorkar Student, Dept. of Computer Science and Engineering, RGCER, Nagpur, Maharashtra, India ---------------------------------------------------------------------***--------------------------------------------------------------------- Abstract - To authenticate users, most web services use pair of message that would generate the same hash as that of the username and password. When a user wish to login to a web first message. Thus, the hash function should be resistant to application of the service, he/she sends their user name and second-pre-image. password to the web server, which checks if the given username already exist in the database and that the password is identical to 1.2 Hashing Algorithms the password set by that user. This last step of verifying the password of the user can be performed in different ways. The user Different hash algorithms are used in order to generate hash password may be directly stored in the database or the hash value values. Some commonly used hash functions include the of the password may be stored. This survey will include the study following: of password hashing. It will also include the need of password hashing, algorithms used for password hashing along with the attacks possible on the same. • MD5 • SHA-1 Key Words: Password, Hashing, Algorithms, bcrypt, scrypt, • SHA-2 attacks, SHA-1 • SHA-3 1.INTRODUCTION MD5: Web servers store the username and password of its users to authenticate its users. If the web servers store the passwords of This algorithm takes data of arbitrary length and produces its users directly in the database, then in such case, password message digest of 128 bits (i.e. -
Client-CASH: Protecting Master Passwords Against Offline Attacks Jeremiah Blocki, Anirudh Sridhar Motivation: Password Storage
Client-CASH: Protecting Master Passwords against Offline Attacks Jeremiah Blocki, Anirudh Sridhar Motivation: Password Storage asridhar, 123456 Username Salt Hash 85e23cfe002 asridhar 89d978034a3f 1f584e3db87 6 aa72630a9a2 345c062 SHA1(12345689d978034a3f6) =85e23cfe0021f584e3db87aa + 72630a9a2345c062 2 Offline Attacks: A Common Problem • Password breaches at major companies have affected millions of users. No key stretching? Dictionary of 1000 words Password of 4 words: Horse battery staple 1012 possibilities correct 3.5 x 1011 hashes/second ~ 3 seconds to crack Key Stretching Hash Function Cost: C H Hk … Memory Hard Functions Hash Iteration A Fundamental Tradeoff Increased Costs for Honest Party A Fundamental Tradeoff Is the extra effort worth it? A Fundamental Tradeoff Can I tip the scales? A Key Observation password 12345 letmein abc123 …. …… password unbreakable unbr3akabl3 Most …. …… guesses are wrong unbr3akabl3 A Key Observation unbr3akabl3 unbr3akabl3 unbr3@k@bl3 …. password 12345 unbr3akabl3 letmein abc123 …. …… password unbreakable unbr3akabl3 …. …… Most guesses are correct unbr3akabl3 A Key Observation unbr3akabl3 unbr3akabl3 unbr3akabl3 …. password 12345 unbr3akabl3 letmein abc123 …. …… password unbreakable unbr3akabl3 …. …… Goal Asymmetry: COST < COST Pepper [M96],[BD16] Pepper: t asridhar, 123456 Username Salt Hash asridhar 89d978034a3f 85e23cfe002 1f584e3db87 aa72630a9a2 345c062 SHA1(12345689d978034a3f6)=85e23cfe 0021f584e3db87aa72630a9a2345c062 Pepper [Manber96],[BD16] asridhar, 123456 Pepper: t Username Salt Hash asridhar