Now we're looking at the process of authenticating for services. We want to minimize authentication risks in a way that's technologically neutral. So what we'll do is we'll look at assigning user IDs, handling sensitive accounts, issues of handling authentication errors. Logging and monitoring of course, and resisting automated attacks. Now, when we assign user IDs, the smart thing these days is to make them case insensitive. They have to be unique for heaven's sakes. And then there's the question of. Are these public are these secret? Strictly speaking, we don't consider a user ID to be secret in the sense that we consider a password to be secret. But, if you've got a high security site, there's certainly no point in having user IDs that other people know. So, if the accounts are set, are particularly sensitive, you might want to assign Account Login names. If they're not that sensitive, you may just allow the user to pick their login name, which gets back to the notion of emails as account logins. Emails have to be unique, and the way people acquire their email addresses they tend to be unique. On the other hand, they also tend to be public even if you try to keep them private, so that spammers won't find them. Okay, so in handling sensitive accounts, let's look at the types of sensitive accounts we might have to deal with. We got a bunch of them here. And the first question is, does somebody need to use a particular sensitive account. For example, we have the login to the database server that we use that is used by our application in order to do database queries or updates. Is there any reason a human should use that? Probably not. We set that aside, we use it for that purpose. And if we need an administrative log into the server, that's a different login. Similar with Linux Unix root or admin accounts those sorts of things if you don't need to use it don't use it, use a personal account that has been assigned the appropriate privileges. Now, there's also another issue of remote access. Now some of these sensitive accounts you can just say, we're not going to allow remote access. Well, that doesn't work so well in the cloud world does it? So you have to balance what things you want to allow what things you don't. Now, there may be some mechanism by which you can have an administrative environment within your cloud employment. Implementation that you can connect to. And then it looks like you're administering locally from there. Some sites can do that. On the other hand, that's also the way an attacker could work. Sensitive account naming Yeah. The best thing to do is rename or disable the default ones. There's no point in everybody knowing there's no point in using admin as an administrative account name. Everybody knows that's what it is, better to choose something hard to guess, maybe randomly selected, and try to keep those IDs secret. Now for sensitive account usage, restrict remote access. Sometimes you can forget it entirely but not always. Typically, the recommended thing to do is multi factor authentication in order to do remote access. So you need multiple authentication factors and we'll be talking about those factors in another video shortly. Also you have some things like service only accounts. If you go to windows and look at the list of running, running applications and the accounts they're running under. There'll be a lot of service activities that literally have the name service as the username, you don't want to be logging into accounts like that. Okay, handling authentication errors, well, step one, don't disclose user IDs. So when somebody puts in a user ID and puts in a password, you don't say, well, we can't log you in because that accounts locked because what you're saying is that's illegal user ID, but it's currently locked. You don't want to say no user ID, right? You don't want to say password incorrect because that immediately says, this is a valid account. You just guessed wrong. Now, creating account goes another opportunity to disclose which user IDs already exist or don't. So you don't want to be explicit when somebody creates an account as to whether that name was accepted or not. An account activation link has been emailed to you. Maybe, maybe not. And then there is resetting a password via email. You can say we have sent you a link if your account exists, see that's even cleaner than that last one. Okay, and of course, logging and monitoring. This is crucial with authentication because you always want to log successes and failures. However, you don't want to log secret credentials. And you want to review all failures, so you want to collect the information, but you have to be careful about the collecting. Also, you want to monitor rates of activity. I think we've talked about this earlier. We're in order to detect automated attacks you just notice hey, there's a lot of failed password attempt all over sudden Okay, logging secrets without logging them. Now there's a lot to be said for putting information in the event log saying this person tried to log in with this user ID on the other hand. People occasional will type a password where they should have passed their typed in their user ID. So logging the user IDs is people log in as a little tricky. Now one of the tricks you can grab from privacy measures and PCI DSS recommendations is the notion of saving secret. Saving the secrets like that in a special data table, either real secrets or possible secrets, keep that table protected, but then have like the key or index value of the data. Go into the blog. Log in Message. So if there's something bad going on, it's possible to retrieve the sensitive data index and re refer to that in order to track down what's going on with an attack. Now, let's look briefly at automated trial and error password attacks. It's a big deal. They'll be with us forever at least as long as we have passwords. There's the password dictionary attack where you have one user ID, and it runs at 11 million different possible passwords against that. That's one type of attack, also have kind of the opposite of that, where you have one week password like Password or password 123. And you run that against all the user IDs who you know have. Well that gets back to the thing of, you have to create a list of user IDs for that site. But then you've got your raw material for this type of attack. And then the third is credential staffing attack, where there's been a site breach somewhere. This provided you with user ID password pairs that you plausibly assume work against the site you're attacking. And then you just run those against the site and see whether or not any of the passwords and user IDs match up with the way they're registered in there. Now for resisting automated attacks, well monitoring authentication rates is the main thing and add delays as the rates rise captures, those annoying little things where you're supposed to type in with the hard to read numbers are or how many light poles there are boats or something. There's also the notion of account lockout. A problem with account locked out is it only addresses one of the cases of an automatic attack. And it creates a denial of service risk. Now, also resisting automated attacks, multi-factor authentication, it's right there. Really the recommended solution and as I said, we'll talk about it in a future video. [MUSIC]
