7. Authentication and Authorizationwords include public-key mechanisms, such as Microsoft’s CardSpace [122]and TLS client certificates [155], graphical passwords [103], and many more;unfortunately, none of the proposed alternatives has proven sufficiently enticing[108]. Two-factor authentication [77] is the most common way to complementpassword-based systems by requiring an additional password acqui<strong>red</strong>through a secondary independent channel. Currently, high-value services, suchas online banking services and e-mail providers, have deployed such solutionsin the form of either hardware tokens or smart-phone applications. Besides theobvious overhead of such a system in terms of both cost and effort, a surveyhas shown that it can push users to choose weaker passwords [399]. Moreover,it does not scale as the services increase. Single-sign-on services, such asOpenID and Face<strong>book</strong> Connect [277], offer the option of maintaining a singleonline identity protected by a single password, though which users may accessthird-party services. However, they present a single point of failure, do notchange the users’ habit of selecting weak passwords, may carry privacy-relatedrisks, and can also suffer vulnerabilities themselves [391].7.1 What Is the Problem?Password-based authentication has changed little in the many decades it hasbeen in use, and today it is more popular than ever, with countless webapplications using passwords to authenticate their users. In brief, on firstregistering with a service, a user selects the username and password thatwill be used for authentication. The application stores the username in plaintext, while it attaches a random prefix to the password, usually known as asalt, hashes the outcome using a cryptographic hash function such as SHA1or SHA2, stores the hash output along with the salt in the database, anddiscards the plain-text password. The salt is prefixed to ensure that, even if apassword is sha<strong>red</strong> by multiple users, a different hash will be generated andsto<strong>red</strong> in the database, and identical passwords cannot be identified. Most webservices require that authenticating users send their username and passwordin plain text to the service, and authentication is performed by using thesto<strong>red</strong> salt and transmitted password to reproduce a hash, and compare it withthe password in store. Users could also authenticate without sending theirplain-text password [248]; however, such mechanisms are less prevalent anda hash is still sto<strong>red</strong> on the server. We should also note that there are caseswhere passwords are simply sto<strong>red</strong> verbatim in the database [43].Passwords can be stolen, either in their plain-text form, or hashed. Assumingthat the device used to enter the password (e.g., a PC or smartphone) hasnot been compromised, and, thus, is not running malware than can captureuser input, passwords can be obtained by monitoring unencrypted communications[81], tricking users to divulge them voluntarily (e.g., through phishing or52
7.2. Who Is Going to Be Affected?social engineering) [153], or, as we have frequently observed recently, throughleaking the password database of services [26, 59]. Hardware advances haveovercome the irreversibility of hash functions.Moreover, users frequently reuse the same password at multiple web sites.In fact, Florencio et al. [181] studied the password habits of more than half amillion users, and found that on average a password is sha<strong>red</strong> with six othersites. Password reuse imposes a significant problem because it implies thatan attacker cracking a single password can gain access to multiple sites andservices for which the user holds an account. Password reuse also acts as acounterincentive for sites to use hash functions like bcrypt, as an attackercould target a less secure site—for instance one that saves passwords in plain—compromise its database, and use the obtained passwords in other services.7.2 Who Is Going to Be Affected?Users of all systems that implement text-based password authentication experiencerisks. If a system is compromised, then passwords may be leaked.We stress here that an attacker can expose a system’s passwords without fullycompromising it. For example, a successful SQL injection can reveal all passwordssto<strong>red</strong> in a web site’s database. Furthermore, users that recycle the samepassword in many different services potentially receive the security offe<strong>red</strong>by the service providing the least security guarantees. If a weak service iscompromised, then all the user information sto<strong>red</strong> in services where the victimhas registe<strong>red</strong> with the same password is at risk.7.3 What Is Expected to Happen?An attacker who somehow obtains hashed passwords from the database of aweb service has all the data needed to attempt to crack them. He holds thepassword hashes and knows the function as well as any salt used to generatethem.With this information in hand, an attacker can employ various methodologiesto crack the passwords in the obtained database [234]. The simplestapproach is by brute force. He can try every possible combination of validcharacters, generate a hash, and check it against the values in the database.Obviously, this approach requires abundant processing cycles and time. Alternatively,the attacker can also use a pre-constructed dictionary containingpotential passwords (offline dictionary attack). Using dictionaries can greatlyspeedup the cracking process, especially assuming that most users do not usestrong passwords [107].The parallelism of modern GPUs can greatly improve the speed of passwordcracking. The complexity of the hash function used greatly affects the amountof time requi<strong>red</strong> to crack a password hash. Recently, GPUs were able to crack53
- Page 1:
SEVENTH FRAMEWORK PROGRAMMETHERED B
- Page 4 and 5:
The Red Book. ©2013 The SysSec Con
- Page 7 and 8:
PrefaceAfter the completion of its
- Page 9 and 10: Contents1 Executive Summary 32 Intr
- Page 11 and 12: 1 Executive SummaryBased on publish
- Page 13: 1.2. Grand Challenges4. will have t
- Page 16 and 17: 2. Introductionwho want to get at t
- Page 18 and 19: 2. Introduction• Although conside
- Page 20 and 21: 2. Introductionfuture, where each a
- Page 22 and 23: 2. Introductiondrones), such sensor
- Page 24 and 25: 2. Introductioncover our energy nee
- Page 27: Part I: Threats Identified
- Page 30 and 31: 3. In Search of Lost Anonymity3.2 W
- Page 32 and 33: 3. In Search of Lost Anonymityguide
- Page 35 and 36: 4 Software VulnerabilitiesExtending
- Page 37 and 38: 4.1. What Is the Problem?infrastruc
- Page 39 and 40: 4.5. State of the Artparts of criti
- Page 41: 4.7. Example Problemstem mitigation
- Page 44 and 45: 5. Social Networks5.1 Who Is Going
- Page 46 and 47: 5. Social Networksby such an applic
- Page 48 and 49: 5. Social Networksdisasters. This r
- Page 50 and 51: 6. Critical Infrastructure Security
- Page 52 and 53: 6. Critical Infrastructure Security
- Page 54 and 55: 6. Critical Infrastructure Security
- Page 56 and 57: 6. Critical Infrastructure Security
- Page 59: 7 Authentication and AuthorizationH
- Page 63 and 64: 7.5. State of the ArtFinally, ident
- Page 65 and 66: 7.6. Research Gapshashes and evalua
- Page 67 and 68: 8 Security of Mobile DevicesIn an e
- Page 69 and 70: 8.3. What Is the Worst That Can Hap
- Page 71 and 72: 8.4. State of the ArtAll the other
- Page 73: 8.6. Example Problemserated anomaly
- Page 76 and 77: 9. Legacy Systemsthe execution of a
- Page 78 and 79: 9. Legacy Systemsparts of the progr
- Page 81 and 82: 10 Usable SecurityKeys, locks, and
- Page 83 and 84: 10.4. What Is the Worst That Can Ha
- Page 85 and 86: 10.6. Research Gaps10.6 Research Ga
- Page 87: 10.7. Example Problemsof value for
- Page 90 and 91: 11. The Botnet that Would not DieNu
- Page 92 and 93: 11. The Botnet that Would not Diefa
- Page 94 and 95: 11. The Botnet that Would not Dieti
- Page 96 and 97: 12. Malwarethan 128 million malware
- Page 98 and 99: 12. Malwareequipped with auto-updat
- Page 100 and 101: 12. Malwarethe introduction of App
- Page 102 and 103: 13. Social Engineering and Phishing
- Page 104 and 105: 13. Social Engineering and Phishing
- Page 106 and 107: 13. Social Engineering and Phishing
- Page 108 and 109: 13. Social Engineering and Phishing
- Page 111 and 112:
14 Grand ChallengesOne of the most
- Page 113:
Part II: Related Work
- Page 116 and 117:
15. A Crisis of Prioritization•
- Page 118 and 119:
16. Forwardare accessible from the
- Page 120 and 121:
16. ForwardRecommendation 4: “The
- Page 122 and 123:
17. Federal Plan for Cyber Security
- Page 124 and 125:
17. Federal Plan for Cyber Security
- Page 126 and 127:
18. EffectsPlus18.1 Roadmap Structu
- Page 128 and 129:
18. EffectsPlus18.6 Identified Prio
- Page 130 and 131:
19. Digital GovernmentThe roadmap o
- Page 132 and 133:
20. Horizon2020• “Making cyber
- Page 135 and 136:
21 Trust in the Information Society
- Page 137:
21.2. Recommendationsallows for the
- Page 140 and 141:
22. ENISA Threat Landscape2. Malwar
- Page 142 and 143:
22. ENISA Threat LandscapeSocial Te
- Page 144 and 145:
22. ENISA Threat Landscapewriters w
- Page 146 and 147:
23. Cyber Security Research Worksho
- Page 149 and 150:
24 Cyber Security Strategy of theEu
- Page 151 and 152:
24.2. Strategic PrioritiesProposed
- Page 153 and 154:
25 The Dutch National Cyber Securit
- Page 155 and 156:
25.1. ContextsInternet (e.g., smart
- Page 157 and 158:
25.1. Contextsdefensive approaches
- Page 159 and 160:
25.2. Research Themesand radio broa
- Page 161 and 162:
25.2. Research Themesconsists of se
- Page 163 and 164:
25.2. Research ThemesRisk managemen
- Page 165 and 166:
AMethodologiesIn this appendix we o
- Page 167 and 168:
BSysSec Threats Landscape Evolution
- Page 169 and 170:
B.4. SysSec 2013 Threats LandscapeT
- Page 171 and 172:
B.4. SysSec 2013 Threats LandscapeS
- Page 173 and 174:
Bibliography[1] 10 Questions for Ke
- Page 175 and 176:
Bibliography[45] SCADA & Security o
- Page 177 and 178:
Bibliography[88] A. Avizienis, J.-C
- Page 179 and 180:
Bibliography[130] G. Cluley. 600,00
- Page 181 and 182:
Bibliography[172] D. Evans. Top 25
- Page 183 and 184:
Bibliography[214] ICS-CERT. Monthly
- Page 185 and 186:
Bibliography[253] C. Lever, M. Anto
- Page 187 and 188:
Bibliography[291] Mozilla. Browseri
- Page 189 and 190:
Bibliography[329] F. Raja, K. Hawke
- Page 191 and 192:
Bibliography[370] T. Telegraph. Bog
- Page 193 and 194:
Bibliography[407] W. Yang, N. Li, Y