Broken Authentication and Session Management

[MUSIC] 0:00 Welcome back, over the next few videos we'll be looking into how developers fail 0:05 to protect the basic gateways to their application and its users. 0:09 From authentication methods, 0:13 to user authorization, developers tend to mess up in this area far too often. 0:14 It's our goal in this stage to explore ways to prevent these slots 0:19 from happening. 0:22 First we're going to look at the number two vulnerability on the OS top ten. 0:23 Broken authentication and session management. 0:27 Sessions and web apps are used to manage the information that identifies a user. 0:30 They are usually created when a user logs into the web application, 0:34 whether on the web or on mobile. 0:37 Sessions make user's lives easy. 0:40 They don't require users that are logged in or 0:42 recently logged in to enter passwords on every new click. 0:44 Before a session is created, when the user logs in they typically pass through some 0:48 kind of authentication mechanism, which is often handled by a username password 0:53 combination, a third party like Facebook or Google, or two factor authentication. 0:57 After a user is successfully authenticated, a session is created with 1:02 information that identifies that user for the current use of the application. 1:06 Usually via tokens or codes stored within the applications cookies. 1:10 With this knowledge an attacker can use flies in the session authentication or 1:15 session management functions to impersonate other users. 1:19 These attackers can be an external attacker, a normal user with an account 1:23 that is attempting to steal data from other users, or someone on the inside of 1:27 the company or group that wants to disguise their actions. 1:31 The functions used in session management are often not implemented correctly. 1:34 Which can allow attackers to see your passwords, secret keys, and 1:38 tokens used to authenticate sessions. 1:42 By compromising this data, attackers can take over users and accounts 1:44 which can lead to severe consequences about the user and for the developer. 1:48 When building session workloads, 1:53 developers need to implement many pieces of functionality. 1:55 By building custom authentication and session management methods, 1:58 developers often leave flaws in a variety of functions. 2:02 Finding flaws in these functions can be difficult since implementations 2:06 are often unique. 2:10 Though session management is a very diverse topic, 2:11 there are three common flaws here which every developer should know. 2:13 First, application timeouts were often set improperly. 2:17 If an application token is compromised or 2:21 leaked, properly set timeouts prevent an attacker 2:23 from using a token to impersonate the user if the token was generated too long ago. 2:26 However, tokens are often left valid for days or even weeks. 2:31 Second, attackers can acquire a user's session ID or 2:36 token from network traffic by getting in between a user and 2:39 the application on an unsecured network connection. 2:43 If the session ID is in the URL or unencrypted in the request body, 2:45 then the attacker can capture it from network traffic and use it as they wish. 2:49 Third, an internal attacker or 2:53 a remote attacker can gain access to the user database via a variety of methods. 2:55 If passwords are not hashed, 3:00 then these passwords can be directly used to log in as the user. 3:02 Good news for us, though. 3:05 Preventing session management issues is easily prevented in most cases. 3:07 First, user authentication credentials should always be hashed when stored and 3:11 sent over encrypted connection. 3:15 Session tokens should never be exposed in the URL, 3:17 since this is sent in the clear in most cases. 3:20 Session tokens should also timeout after a short time, and be invalidated at logout. 3:23 THis prevents attackers from stealing a session token and using it over and 3:28 over again to access a user's account. 3:31 In addition to invalidating tokens at logout, 3:34 they should always be recreated on logins. 3:36 Finally, these credentials should always, 3:39 always, always be sent over HEPS, with no exceptions. 3:41 By following these simple rules, 3:46 the majority of session management flaws can be prevented. 3:48 Remember, using well known authentication methods such as OAuth 2.0 can 3:51 prevent many of these issues. 3:56 These topics are covered as well in several other Treehouse courses. 3:58 In particular, the introduction to application security course. 4:02 To really explore how session management issues arise in an app, 4:06 let's look back in our app from the first stage. 4:09 In our application, user passwords are start without hashing them first, 4:12 which we can see by looking at the user model in userdao.js. 4:16 To fix this issue, we can use the bcrypt algorithm, the currently most trusted 4:23 password hashing algorithm, with implementations in nearly every language. 4:27 With bcrypt, we first generate a salt for the password. 4:32 A salt essentially adds more difficulty to breaking the password. 4:35 In practice, a salt is a random, 4:39 unique, per-user complex string added to every password before hashing. 4:41 By doing this, developers can prevent attackers from calculating 4:45 the corresponding hashes for common passwords ahead of time. 4:48 Where those common passwords can come from data breaches that other users 4:52 can be exposed in or they could come from common password combinations in lists. 4:55 These precomputed passwords make up something called a rainbow table, and 4:59 using a salt with a strong algorithm such as B-grip. 5:04 We can prevent our hash passwords from being translated 5:07 back to the actual password in nearly all cases, 5:09 even if the attacker has the fastest modern super computer. 5:12 With the salt calculated pick up library, we hash the user's password with the salt. 5:15 By hashing the password and storing the password hash, 5:32 when a user attempts to login with a plain text non-hashed password, we can then 5:35 proceed to hash the entered password and check it against the stored hash password. 5:39 If this two match, we know the user can be authenticated and 5:44 proceed to the application. 5:47 Another issue with our application is the no time out is forced in the user session. 5:54 Which means the session will say active until the user explicitly logs out, 5:58 even if the browser window is closed. 6:03 Even worse, 6:05 the application does not prevent cookies from being accessed via JavaScript, 6:06 which leaves the site vulnerable to XSS attacks as we discussed in the last stage. 6:10 Not only are cookies able to be accessed via JavaScript, queries also be sent over 6:14 unsecured connects, meaning the sessions lack encryption. 6:19 When the session lack encryption, the attacker can steal the session ID if they 6:22 able to intercept user's traffic, which can be easily done if you and the attacker 6:27 are sitting together in a coffee shop on a public unsecured WiFi connect. 6:31 In order to address these issues we need to close the session when the browser 6:35 closes and when the user logs out. 6:39 And we also need to add headers to the HTTP request to ensure that cookies can be 6:41 accessed via JavaScript. 6:46 And the cookies can't be sent over non-secure, or non-HTTPS connections. 6:47 In a video later in the stage, we will make the application speak over HTTPS. 6:52 But for now, let's deal with the cookie issues. 6:55 Within our application, 6:59 we need to make sure that the max age setting is on cookies. 7:00 Which means express with these session cookies will be invalidated on browser 7:03 close analogue out. 7:07 Now, let's add this in the main server file. 7:08 First we will set the maximum age to one day. 7:13 Then we will ensure the cookies are invalidated when the browser closes. 7:16 In other languages, this same kind of thing can be done, so 7:33 refer to the documentation for your particular web framework. 7:36 Next, you must ensure that cookies are only sent over https and 7:40 not accessible via Java Script. 7:43 To do this, we can set the http only and 7:45 secure http headers in the main server file as well. 7:48 We could also use JavaScript libraries to set specific http headers 7:59 to add more security. 8:03 The best known library for this is Helmet, 8:04 which we'll discuss in the video on security misconfiguration. 8:07 Regardless of language, these features are available nearly anywhere, so look for 8:10 them when you implement authentication in your applications. 8:14 Before we move on to broken access controls in the next video, 8:17 let's wrap up session management by discussing password handling issues. 8:21 When developers don't require strong passwords, attackers can more easily 8:25 guess passwords and break into user accounts via brute force methods. 8:29 Unfortunately for developers, there are many security tools for 8:33 guessing passwords as efficient as possible and 8:36 with the ability to try many common password combinations. 8:39 To prevent password brute-force attacks, 8:43 developers must ensure passwords are long and complex., 8:45 preferably more than eight characters, and requiring both letters and numbers. 8:48 And if possible, special characters like punctuation. 8:53 Another flaw in apps occurs when apps divulge more information than necessary 8:56 on an unsuccessful log in attempt. 9:00 Authentication responses should never indicate which part of the data 9:02 was incorrect. 9:05 For example, instead of saying invalid username or invalid password, 9:06 simply use invalid username and or password or just log in error. 9:11 Even though this may be frustrating for 9:15 innocent users, this simple fix prevents attackers from 9:17 easily knowing whether their brute force attempts are working effectively. 9:20 Beyond simply requiring complex passwords, 9:24 developers can disable accounts after too many failed login attempts. 9:27 This prevents attackers from trying to log in too many times, 9:30 while allowing normal users who simply forget their password 9:34 to just have to wait some time before logging back in again. 9:37 As we've discussed, session management flaws can arise in many, many ways. 9:40 Most of these flaws can be prevented. 9:44 In the next video we'll look beyond authentication towards how a developer 9:45 can apply permission to users for preventing security flaws 9:49