[MUSIC] Let's revisit our login activity. And we're going to use it to look at why secure defaults are such an important concept. Now, secure default is about making sure that if we do nothing at all from the security perspective. If we specify nothing at all, we get the right expected or most secure behavior out of the system. And this can take all kinds of forms. For example, if we are storing data. And we're going to decide if we encrypt it or we don't encrypt it. Well, we should default to encrypting it. But I want to look at an example that goes back to our login activity example. And what we want to do is look at an alternative way that we could have gone and implemented this click listener to show why security defaults are important. And a subtle bug that could be introduced by having an insecure default. So, we saw the example where we had a map. And we went and we looked up the crack action in the map. We saw why that wasn't a great thing. Now in this case, I've still gone through. And how all of the buttons register with the login activity as its click listener. Well, we're going to go and do a different implementation of this onClick method that does not use the map and violate the economy of mechanism principle. So, we could go through and we could say. We could check what object was clicked. And we could say, if it's the loginButton, we're going to go do one thing. If it's the registerButton, we're going to do another one. And if it's not the login or register button, it must be the forgotPasswordButton. So we'll have our forgot password link action here. We'll have our register user action here, whatever we're going to do with that. Now again, we're not using the actual interface login action anymore. We're just going to have our logic there and some other method. We're going to have our login action here. Now, this certainly seems much cleaner than the previous example we showed. That, yes, it was extensible, but it made it much harder to see what was going on. When we look at this, it's much easier to see. If this onClick method gets called, once these three buttons here adding click listeners, one of these three things is going to happen. And we can see that because of the if-else statements that are shown here. So, from a security perspective, it is easier to audit than before. And there is a downside, yes, if we want to go add actions. Well, if we really needed this thing to be extensible, we'd have to go and edit this if-else statement. And add new conditionals here for what things could be clicked that we would care about. But what we can also see here is the subtle problem that we've created, where we have not created a secure default. Now, I want you to take a second and take a look at this code in these if-else statements. And see if you can spot the insecure default that we have created. Now, if you don't see it right away, that's okay. But let me go ahead and walk you through it to help you see what it is. Well, if this click listener is called, one of three things is going to happen. And the first thing we need to do is define what is the default thing that's going to happen. Whenever you think of secure defaults, you need to identify for a particular set of logic what is the default action. Well, in the case of this, the default action is sending a password reset link. Which obviously could be a highly sensitive operation, depending on how this action is implemented. Now, for example, if we went and we had another type of button that got created here. We had created a shareWithFriendsOnSocialMedia button, and we set the OnClickListener. And we set it to ourselves. Well now, this shareWithFriendsOnSocialMedia. You can imagine this is something where you were trying to promote your app. It is not defined down here. So this means that if a developer goes and creates this button. And they don't think through going and updating the case statement down here. Or they forget for whatever reason. Or something unexpected, where a click listener gets added to something that the developer didn't think about. The default action is going to be this send the forgot password link action. And depending on how this is implemented, maybe they just go and take the email address that's in the password link edit text and send the password link there. So there's all kinds of bad things that could happen in this case. Where we're not making our default thing the most secure thing. Well, what would the default most secure thing. Well, the better thing to do would have been do something like this. Where we say = forgotPasswordButton. And make the default do nothing. Or send an error report back to the developer, do something. But the default before was to take one of these actions. Which is not what the user actually necessarily intended. So, whenever we're building a default, we want to always make sure that that default is a secure thing. In this case, probably the most secure thing is to do nothing at all. And probably to tell the developer or make it, More explicit that something bad happened. We want to know if something that we did not expect is happening. And we also don't want to do anything at all. Because this should be the default mechanism. So in this simple example, we've created a set of logic. And by stopping and taking a moment to identify the default. And then thinking about what is the most secure action for that default. What we've done is identified a potential security issue or a way of improving security in our application. And you can do this all over the place in your application. Wherever there's choices about what's being done. Wherever there's conditional flow through the logic in your application. You want to think about what is the default condition going to be. And is that default behavior the most secure thing? And, in this case, for example, it wasn't. And often you'll find that when you start thinking of things that are what is the conditional logic. What is the default case going to be? And is that default case the most secure thing I can do? And if you can't answer yes to that question then you should try to refactor that into something where it is the most secure.
