Authentication done right. So we're gonna talk about my journey of creating a federated login system or like you can call it single sign-on server in Node.js. I have a disclaimer in the beginning. I am like, don't consider me a expert in Node.js or cybersecurity, should do your due diligence when you're creating authentication system, figure out things on your own, definitely. And this is like, I don't want it to appear like a best practices talk. I would like presented more like the things that we did, things, some of them that went wrong, what we did to fix that. Maybe when you're making a similar system, some of these things might be helpful for you. So to start with, what did we build? Like, I mean, what kind of a system do you call SSO, whether it's a federated identity management system or LDAP? So here's what we needed actually. Something very simple. We wanted a single system in which users can log in using external service providers. If they want to, like they can use a Twitter login or Facebook login or something like that. And we have like a lot of different client apps. So we have one e-learning app, we can watch videos. We have an app where people can participate in a lot of contests. So like a microservice kind of architecture. So there are a lot of different apps and people should be able to like log in with a single identity. So there are two parts to it. One part is an OAuth client, which helps us get people logged in to our system for using some other third-party server. So like the upper part of the system. So they can log in using some other systems. And of course, we do have support for local logins. That is keeping an account with a username and password on the system, not use a third-party login if they want to. So things that we're using to build it. So we're using PostgreSQL as a database be equipped for saving the passwords. And one of the most beautiful things that we're using, so the last talk you heard was also from OAuth0. And they have a beautiful service which allows you to create like a completely outsourced identity management system. What I really like is that everything that they have used to build their own system, a lot of those tools are open source. So you can literally create a copy of OAuth0 on your own, which like our system is much like that, using their own tools. So passport, common library for authentication using Node.js, it's made by the people who have built OAuth0. Then there's the second part to the system which is the OAuth server, which is a system which allows all of our client apps to be able to use a single login system. Basically the lower half of this. So there might be some systems that use authentication plus they also use user roles for doing some ACL. There is, we have an app which basically needs the GitHub data of the user to give some scores and all. Then there could be some apps which do some two way data updates also. Like users information can be changed from the client app on the SSO server, other way around as well. And to do this, we are using a Node.js library called OAuth2 ORIZE. The first version was called OAuth ORIZE and they just added two in the middle to call it OAuth2 ORIZE. It is a very simple way to create a OAuth 2.0 server. You don't need to implement a lot of things by hand. And we're using stuff for sending emails for verification and stuff. And we have SpeakEasy, it's a library made by a lot of Googlers which helps you use Google Authenticator or any time-based OTP methods. So when you went out building it, a few of the things that we had in mind right from the beginning, like basic tenets that will definitely follow these things is these. First, Node JavaScript. So speaking at a JavaScript conference, Node JavaScript, I mean Node JavaScript on the front end. So our system does not rely the login server only. I'm not talking about the client apps. They are all, some of them are Ember apps, some of them are Vue.js apps. I'm talking about the authentication system itself, does not rely on any front-end JavaScript. So we just completely eliminate the case of XSS. No cross-site scripting to be handled at all. I mean, and also our cookies are then HTTP-only cookies.  So you can build pretty complex stuff without using JavaScript on the front end. And that's the way the web was built at one point of time in the past. So, and it helps in security. For saving the passwords, you're using Bcrypt. And I think this is something I have seen a lot of people and even we ourselves, we experimented with a few things here and there. And it really boils down to, you like, just keep it simple, Pbkdf or Bcrypt, these two are some of the best methods. We are using sorts, but we are not using Pepper. I think for the kind of scale that we operate on, the kind of attacks that we can possibly face, I don't think Peppers are not needed. I think it would be an overkill to do that. Then, so if you're creating an authentication system and you want like, a lot of your products are using the same authentication system, and in today's day and age, I think one thing you definitely should have is allow users to opt into 2FA.  You can maybe use some OTP generation methods via SMS and email or something like that, but, or you can use OTHI or Google Authenticator, so use a TOTP solution for that. Okay, so pretty contrasting after the last talk, but we use JWTs a lot. We use JWTs a lot across our client apps. So when like, say for example, we have a video player, the video gets signed by a JWT. We use that JWT to download the chunks of that video. So we're doing that in a lot of our application servers. The authentication server does not use JWT because of two reasons. One of them, I told already, we are not using JavaScript on the front end. So I think one of the good ways of using JWTs, keeping it in the RAM, not in the storage. So that won't be possible if we don't use JavaScript on the front end. Two, we want server-side logouts for the central authentication system. You want that. If you don't use, if you use JWTs, you end up turning them stateful. You keep a blacklist or you keep a whitelist. And if you end up with a blacklist or a whitelist, then you are at the end of the day storing in the database, so it's better just fall back to tokens itself. Okay, that's the reason. Not using JWTs. Also, the entire knowledge that download happened here last half an hour, the developers don't need to understand that to implement the system. Because yes, JWTs is easy to implement, but to correctly implement, you have to keep in mind a lot of those things. This, I think if you're creating a single-sign-on system, this is something that we follow is that we have some mobile apps also. And in mobile apps, when we log in, the username password entering happens through a web view. We don't get the username and password on the client and then pass it over the API. We don't do that. So that's like, I think I prefer doing it this way because when you're doing it via a web view, the users can see that you are, so phishing gets prevented, man-in-the-middle attacks get prevented. The users can see if it is over HTTPS or not, which on an app, it's hard to see. It's easy for somebody to maybe decompile your app, modify it, and then fish some password or something out of it. And unless you are like somebody like Facebook or Google where people have a lot of trust on that app and they know for sure that they're using the correct app for something else, I prefer to just use a single UI for taking the password. There should be not two, three different places where the user is submitting his trust. So a few things. I think building a security system, let's decide what we cannot protect. This is very important because they are attack vectors everywhere. And if you try to protect all of them, you're gonna end up with a mess. This is one of my favorite XKCD comics that all kinds of security measures one side and you can just beat a person and get his password. Okay, so that's the case we are not covering. So very simple. If somebody shares this password, tells his password to somebody else or somebody looks at somebody typing the password, we can't protect that. And basically we're gonna protect our system. We're gonna protect till the extent of our SSL certificate. If there is any client side proxies or anything, we don't want to cover that case. It just complicates the thinking process. Like then you start thinking, okay, I'll protect against this, I'll protect against that. No point doing that. Just do the ones that are possible. Okay, this is very important. So how many of you here have used an Adharka to enter an airport? So were you identified or authenticated? So identification is just, you tell your name is something that's identification. Getting this difference clear is very important when you're creating an authorization system. Authentication, now that's when you actually verify whether the identity that has been provided is correct or not. And this authentication can happen in two ways. One is using implied trust. So if you say, for example, show your passport to somebody, and somebody sees the passport and sees that it looks authentic as in the paper and the quality of it that looks authentic. So they trust the government of India and they think that you are authentic because the passport does not look like it has been forged. The other way of authentication is what it's called tofu. Trust on first use, that is you first time meet a person, you tell that there's a secret word that we share with each other. In future, whenever I share this secret word, you know that it's me. That's the password way of doing authentication. But either you need to trust a third party to identify the person or you need to trust that person first time by default and then next, from next time, use the first trust factor, okay? So, but it is more than just identification. And then this authorization, so you have access to something, allow somebody else to use it as simple as that. That's authorization. Here, there's a question here. What's the official name of the HTTP error code 401? Unauthorized or what? Authorized? 403? For a bit, okay. Somebody who is logged in can they get a 401 error? And somebody who is logged out can they get a 403 error? Okay, can the same route generate a 401 and a 403 in different use cases? Okay, so I think, Mushad answers correct? 401, the name is unauthorized, but it actually means unauthenticated. With a HTTP, as per the HTTP spec, the name is unauthorized, but it does not mean unauthorized. It means unauthorized. And forbidden is what actually means unauthorized. So, only when you're not logged in, you can get unauthorized. When you're logged in, but you don't have access to that particular route, you get a forbidden, okay? This brings us to authentication via authorization. So, quick example, you want to prove that you own a house, you can show the sale deed or property certificate or something like that. The other way to prove it, you invite somebody home. They assume it's your house. Okay, so that's authentication or authorization. You authorize somebody to use your house. It's implied that you own that house. Okay, so when we're doing OAuth, we're doing something very similar to this. Let's just take a look. The steps go like this. You go to a browser. Browser sends a request to server. It gives you a login page. You got a login page. Click login with GitHub, okay? Browser sends a request to GitHub now and it adds some client ID redirect to your eyes so that GitHub knows which app is trying to log in. Okay, GitHub sends me back the GitHub login page. GitHub login page, I add my username and password. Now, this is going to post request to GitHub. The challenge will get verified, username and password are correct or not. I'm not sharing my username or password with the coding blocks app. Sharing only with GitHub, okay? And now there are two ways forward, okay? Red Pill Blue Pill. We've got implicit way and explicit way of authenticating from here forward. So let's look at what implicit way means. So GitHub redirects me back to my website and the URL contains the OAuth token. Okay, so at this point, I'm already trusting that my browser has opened my website correctly. It's implied trust there. And now if I want to get my profile details, my profile page can simply make our Ajax request to say api.github.com slash profile pass this header OAuth token equal to something. I will get name, email, username. And see this is where authentication of authorization is happening. I get the name, email and username from GitHub. So I authorized this app to get my profile information and the app takes this profile information and it just trust that this name and this email is correct. So I think this Blue Pill, this is Red Pill, explicit author case, GitHub takes me back to my website but this time it gives a grant code instead of a OAuth token. Now for this to work, obviously you need your backend server. This cannot work on only front end base systems. You have to pass the grant code, you get OAuth token, pass the OAuth token, get your profile data, then you show your profile page. So this is the kind of system we are using. This need not have front end JavaScript to work. You can do the actual transfer in the backend. If you laid out all the steps together, this is what the implicit steps look like. This is what the explicit steps look like. So when you do a fetch client page, then that information is actually exchanged. Okay, so while you're building this, things that we learned, sometimes we burned our fingers on certain things. I think the first thing, and you have had two security talks and lot of the things might have been like captain obvious and here is one of the captain obvious slides, but this is important. We ran the system for, I think more than one year, had about 10,000 users till that point. We did not have CSRF protection. We did not have a content security policy and that's like the story of a lot of startups. Just start building things. Prototype, prototype becomes production. You don't know when it becomes production. Okay, users start pouring in. Your friends and family are using tomorrow, like people are using, but I mean, as much as possible, not do this. I mean, first time you do this, maybe second time you make an app, don't do this because one major problem we had is you were actually saving the sessions in memory. We had to, when we had to scale up, we created cluster mode. I mean, it did not even hit me first. Some guy says, I'm trying to log into your website. I logged in, but when I refresh the page, sometimes the page opens, sometimes it says I'm logged out. I'm like, sometimes, what do you mean by sometimes? Okay, and so what happened was that, depending on the kind of name resolving strategy you're using in NGINX, my requests were all being served by one of the clusters, not by the second one. Somebody else was using, their IP was rotating and sometimes they're using node one, sometimes node two, and their token is in the memory of node one, not in node two, okay? You can't scale if you save stuff in memory, of course. It took us three, four days to figure out, okay, that's the problem here. So, here's like, after doing this, I think with the transport layer stuff, I think we figured out basic security versus overkill kind of checklist. Using X frame options, probably using deny so that people cannot put your website inside an iFrame. That's a good option to do. Content security policy, keeping one, definitely very useful. I can recommend looking up GitHub's engineering blog. They have a very nice article on how to do content security policy, okay? Should ideally have a specific CDN which sends your images, styles, and fonts, and you whitelist that in your content security policy because XSS via images are seeing one of the easiest way people do. Don't do that, keep a whitelist for that. And, this is the place where you can actually, with a hard switch, you can disable JavaScript on the front end. You can use script SRC and pass an empty area to script SRC. In that case, no JavaScript will get executed on your site at all, okay? Some websites and production level, like Facebook, GitHub, what they do is, they have a separate CDN from where they send their JavaScript files, okay? And the script SRC does not contain self, which means any lines of code part of the HTML does not get executed. Only the JavaScript that comes from the CDN gets executed. Okay, so like if there are some Chrome extensions or somebody man-in-the-middle injecting JavaScript into your page, that does not work out, okay? CSR protection, very easy to do these days in Node.js, you see surf, replay the token. This is something, basic hygiene should be done, of course. Okay, this is very important. I know a lot of people who think this way that if you're using a very popular SQL library, you're using an ORM, statements are always prepared, so you don't need to worry about SQL injection. It's a problem solved in the bygone era, but it's not, so like just last year in SQLize, the most popular ORM in Node.js, two vulnerabilities on SQL injection was found out. It was patched, current version does not have any, but you never know when a new feature that started an SQL injection might get added to it. Okay, so for this, I think you can read up a nice article by Snick, SNYK, it's also a good tool to check out whether your code has vulnerabilities and all. So I mean, this is a strategy security experts say, defense in depth, validate your variables at every layer, validate on the client, if you have client JavaScript, if not, then M layer, V layer, C layer, every layer, validate the input, okay? Don't just think that in one layer, you're validated next layer, it will come out to be validated automatically, okay? And rock varies and all, if you are doing that, of course, manually escape stuff. This thing also we learned is that we download a RFC paper and we see, okay, the spec is fine. You start implementing one thing, two things. You find one thing, okay, refreshed tokens, okay? There are, you have to make a post call, then a get call and all of that. Okay, I will just make a separate endpoint which will refresh my tokens, okay?  And we have now figured this out, we never sidestep the specs ever doing things like this. So the refreshed token thing was something that we implemented our own way of doing refreshed token server to server refreshed token calls without using the user scope. And that obviously first of all created a vulnerability. Second, the thing is in security, I think once insecure, if you are having a mobile app or a PW or something like that, where you cannot control the rate at which people are updating their clients, then once it is insecure, it's going to remain insecure for a long time. Because if you have an API which is insecure, now you update to a secure API, the clients stop working. You don't know, business guys won't allow that to happen. They will say, okay, keep the old API open for two months, wait for the people to update. Till then, you know there is a vulnerability and you're living with that vulnerability. You can't get out of that. Either you delete like 10,000 users who are using that every day, they stop using it, something like that will happen. Okay, so turning things insecure and then turning it back to secure very hard.  Another one incident is we initially thought that, people will always log in using a user scope. But then some client might want to edit data, not using a user scope, like as a client itself. The OAuth spec supports this. We thought such a case will never happen. We had to rewrite a lot of our project to support such things. For OAuth, I think some of the things that you can defer, not ignore, is say refresh tokens. You can make that people will just log in once again if their tokens have expired. But don't implement a different way to refresh token. Either don't implement it at all. That's fine. Similarly, scopes and all for clients, you can use a star scope for everything. And later on, you can add scopes if you want to. Okay. And one thing I know what is something called a password grant type, like I said with the single UI model. Don't support a scheme where the username and password can be sent over a post request and you can give a grant type. That exists so that OAuth 2 is compliant with OAuth 1. It's a backwards compatibility thing, but it makes OAuth insecure. It's better not to implement that. This, now coming more towards the business side aspects of creating a system like this and whether things that not work out well and we had to. So state management is a very important part of UX and I'd like to show you a couple of things. So here is a zero login system. So what does zero login mean? So I'm, this is one of our client apps and I'm logged into that right now. If I go to another of my client apps, so I'm logged in. Okay. So, I mean basically when I went to the online.coding.com, this site I did not have to log in again. Other ways, if I am on one of the apps and in any other tab I have logged in, I can click on login and I get logged in automatically. So, I mean saying say one click login and two click login path, which is like if I click on login and I'm not logged in right now, then I can either put my challenge or I can use one of the social providers and if I'm logged into the social provider, then two clicks takes me to log in. Finally, if I'm not logged in anywhere. Okay. So in that case, I have of course it'll be a three click model but then I have to log into Facebook also. Okay. Then there's another case which I call as the broken flow model. Somebody comes to our website and they don't have account with our website now and they click on login, takes me to the single sign on server. There they sign up with their account. Okay. They sign up but some of our products, they need a verified email ID to use it. Okay. They don't work only with a simple sign up. You have to verify your email ID also for to be able to use it. Okay. But at this point, their flow breaks because they now have to open their inbox, check the verify link, open that very filing. Okay. So this is the place where a lot of systems I've used even popular ones like Kora and all I've seen. This is where flow breaks from a lot of times you click on the verify link. You don't end up at the exact page where you started your entire cycle from. Okay. So you should ideally like make a redirect where I part of the verify link itself or I think that's not an information you'd probably want to share over emails. That's fine. You attach the redirect part in database to your verify email link so that if somebody like signs up and then they have to check their inbox. So at that point, a lot of drop happens. Sometimes people just leave using that and maybe next day they come and click on the verify email link. Okay. So when the next they click on the verify email link, okay. Capture the user back at the same point in your product where he left. So he was probably added something in his cart. We'll go and buy it. Okay. If he ends up at my profile page, you will not provide it. Okay. This is very important in the broken flow model also. You should end up at the same place where he started from. And now about the part where when we have a SSO server and a lot of client apps. So we need to separate our concerns also. We need to make sure that first thing there's the data API. So the client apps use the user API to get the details of the user. So whenever data fetching is happening, that should always happen over the version API. So that if you change the API of the SSO, you don't need to rewrite the code in all your client apps. Okay. If like different apps need different sets of data, you can create scopes for them. The authentication flow, like how we are logging in via Facebook or how we are logging in by Twitter or how we are giving our challenge. That part of the flow is not related to the client apps. That is purely in the SSO level. So that part, if we change, we don't need to version that. That part we can change on our own, that's fine. But whenever the client apps are accessing data from the SSO app, make it version. This, I think we have done a lot of to and fro on this and we have ended up with a thumb rule on what kind of data should we save on the SSO server, what kind of data we should not save. Is if some data needs to be there on at least more than two of our client apps, then only we think of centralizing it. And keep in mind that if it is not related to user data, and this is like a lazy developer thing, you think that some information, like information of all, like the demographics, like country, state information, et cetera, we need it in a lot of apps. Okay, let's just put it in the SSO server because everybody is using SSO server.  Okay, if you need like global information across to 10 of your clients, just create a separate microservice of that. Don't dump things into the SSO server just because it's globally used everywhere, only as long as it pertains to the user data. If it is about the user data, then. And this you should always maintain this thing is that if we need in one of our client apps, we need information about the GitHub user profile or like Facebook user profile we need. Those queries should happen via the SSO server so that your trust chain always remains on the SSO side. Okay, like that way it can happen is like we can get a Facebook authentication token, pass it on to a client app, but then in the client app, you will have to implement the Facebook refresh token mechanism also. You just end up rewriting that all the time. So if the user has done a third party authentication in the SSO server, accessing data office third party authentication should have happened through the same flow itself. Then this is challenging keeping data in sync across these things. Some of the data will obviously become redundant. Maybe name of the user profile photo. You might keep a copy in the client apps also in the SSO app. So when it is really important to keep the data in sync, then every authentication just refresh the data from the SSO server. Otherwise, like if it's not all that critical then you can maybe run some crons, et cetera for updating that data. And if you have like data updates on the SSO server, then do not like create any generic like special APIs. Just do it using the proper STPI using the user's auth token scope. So every client app should be treated equally. Nobody should have like a special hook to like change an entire table on the database. That's where security flaws start happening. We've also found out that whenever you want to implement things, if you just take a little bit of time out to find out if some specifications exist for that, some standards exist that has had better results. One example specifically was all countries, states, cities in the world, they have ISO 3611 code which uniquely identifies every like region. If you use that, you can use that as primary keys because the ISO standard ensures that it is unique. We have migrated that a lot of times finally and ended up using the spec. Okay, so this analytics and monitoring, I'll show you something. Anybody remembers getting emails from Twitter or GitHub? How your passwords are probably logged? I think a lot of people got these, okay? And it was widely speculated, though none of them actually verified. They both use a similar logging, Ruby-based logging framework and it was speculated that they were actually using a log all framework which was logging the entire request bodies and that's why your passwords were getting logged. So whenever you're using log all kind of frameworks, make sure you're sanitizing the log values. Lot of libraries, they remove specific keys like if you have a key name, password, they will probably delete that but still you should manually do that. In addition to that, if you have compliance and legal issues, keep in mind that when you're using third party monitoring services, then the user's data does not stay with you, it goes to somebody else.   Okay, use like standard HTTP error codes also. They like your analytics monitoring software, they have some default behavior if you're using proper error codes. This famous Akanun article about this or if you put your username and password on Stripe or GitHub, they say that username or password is incorrect. They don't tell which one is incorrect but then you can go to the sign up form and check if the username is correct or not. Okay, so not telling whether the username is correct or not can have a benefit only if there is no easy way to find out if the username is correct or not. Okay, most of the web-based applications you try to sign up, people can get to know if the username was correct or not. Okay, so you're not reducing the attack vector just by not telling the user whether the username was correct or not. Rather if you exactly tell if the username or the password was not correct, the user will rectify only that part. Okay, so you're just confusing the user. I mean, we did this, we ended up with the situation. People are not able to log in, just why can't you log in? We call up the user, I can log in. I just can't, he can't describe anything beyond that. Okay, so now we make it a point that, I mean, as long as the user, the error can make sense to a layman, we pass that error on, like the message is more specific. You don't like the server failed or something like that, not that kind of errors, more specific. So it helps us debug production errors better. This thing, when we are doing a third party authentication with services like Google, Facebook and all, after Cambridge Analytica, they have been cleaning house a lot. A lot of times this happens, an example from discuss, like this is current example. If you try to log in with Google and discuss, it will not work because Google Plus, they have disabled certain profiles, go up on that. So if you just want to do login, for that part, don't take an extra scope, other than just the profile scope. When you need extra information, do a loop back across that provider once again. That the user sign up cycle does not break. A lot of times say, if you want to do Google sign in with Google, it is very seamless, but if you ask extra permissions, then you get a page like this. Okay, and this page out of our data, I mean we have like 20, 30,000 users, don't have a lot of data, but we have seen a lot of dropout from this place. Like if you ask for extra profile scopes, people don't give these permissions. It's very common. So if you just need to log in, just log in and most of these service providers, they don't ask anything extra during the login part. Later on, if you need other things, do it later.  So don't try to create like specific use cases kind of things. Then, I mean, this is one thing we have been trying to figure in a lot of ways, how to handle the duplication part, deduplication. I think you need to segregate between two things in mind is, somebody deliberately creating a new email account and trying to log in is different from somebody mistakenly having created two accounts, one with the Facebook login, one with Twitter login. So when sometimes you need to allow people to merge their accounts and if you think that your business case depends on identifying a user so that he cannot use two accounts to use some coupons or some benefits, it's India, forget that, okay? That's not going to work out. People are going to create multiple accounts and they're going to use that. So if your business model depends on that, I don't think that's going to work out. And finally, secure even from yourself. This is very, very, very important is that when you're like having slowly your development team will grow. Start with one person, there's a founder, there's a CTO, then the team grows, there's 10 people, 20 people. Right from day one, make sure that you keep a copy of your database run a cron job that anonymizes all the data and then you check across the anonymized database. It's a good practice to have from day one. Later on, it will be hard to implement, okay? Second point, I mean, I don't know how many people would agree, but our system is completely open source and that has helped made it secure a lot because every time we make a git commit and push, we know that the world is going to see this code. So we just make sure that, you know, there is no security flaw in that code. It's like two times we're thinking about that. All of our products which are closed source, there are only two, three of them. They are much more insecure than the open source one. That I can say for sure, okay? So to summarize, security is pretty simple. I think these two things are things you can keep in mind. A lot of people say that making things secure reduces the experience. I think it does not reduce the experience of the user, but it definitely does reduce the experience of the developer, okay? You are going to create a lot of barriers for yourself when you make your system secure, but that's a cost on you, not the cost on your users. You can keep things with very nice UX plus security. That's easy to do. And yeah, just follow the security tips that you have known from the beginning. And I will just end my presentation with a nice joke here. I don't know how many of you might have seen this in Twitter. This is one guy who complained to T-Mobile Austria that the call center person was verifying their password over call. So he said that means the call center person has access to my password, which means that it is probably saved in plain text, okay? Also not case sensitive. Wait, it's not end here. T-Mobile says the customer service doesn't see the first four characters only, not the other ones, okay? So we store the whole password because we needed to log in? Of course. So they go on saying that you have so many passwords for every app, for every email account, so on we secure all data very carefully, so there is nothing to fear, okay? And then somebody comes up and says, what if your infrastructure gets breached and everyone's password is published to plain text to the whole wide world? What if this does not happen because our security is amazingly good, okay? It does not end here. The guy says he has to come back. This is that nobody's security is that good, not even yours. T-Mobile Austria has to always come back to that. You're saying that do you have any idea of how telecommunication companies work? Do you know anything about our systems? Apparently that guy has to work at Dodge Telecom. So that guy has experience working with telecommunication systems. So don't act like T-Mobile Austria. Think security is something we should always just keep learning and advice wherever it comes from. Hear it, research on your own. I don't think anybody knows everything about security. We are all learning every day. So building the system, my inspirations were Stack Exchange Network. It has a very nice dual layer SSO system log in with a lot of things into Stack Exchange. They have a lot of sites and has Geek's own last user system. So that's something I looked upon a lot but I'm not so comfortable with Python. Otherwise I would have used that. I wrote my own one. And two people I would like to thank, Jared Hansen, our chief architect at Auth0. He, without his libraries making a lot of these things would not have been possible. Aaron Hammer, author of Oath 1.0 and he has written a very big blog article criticizing Oath 2.0. I read that. I figured out which parts of Oath 2.0 are useful and which parts are not. So thank you. If you want to see the source code of this system when I'm describing, it's at github.com slash coding block slash one Oath. If you want to see it in action, it's account.codingblows.com. You want to follow me on Twitter.


Columbia National Guard, Brigadier General Leland D. Blanchard II, Commanding General Land Component Command, Colonel Cody J. Strong. The company provides critical special skills that serve as force multipliers to commanders. You are right at the tip of the spear when it comes to putting that, collecting that intelligence and providing it to commanders who make real-world decisions. You could make the argument that linguists are very hard to find in some places in our country, but not in D.C. We are one of the most diverse cities in the United States, if not the world. And it's that diversity that will allow us to find the individuals to serve in this unit, to serve our nation, and provide the Army with the capability it needs for its wartime mission. I have no doubt in my mind events like this don't happen every day in the Army. It is a rare occasion when a state, a territory, or a district activates a unit, so this really is an auspicious day. I would say this is an historic activation that's coming in an historic month, year really, for the brigade. So we are celebrating this year our 35th anniversary as a brigade. Really, we are the oldest brigade in the Army National Guard and you are now part of that heritage. Massachusetts to the District of Columbia. Attention to orders. Symbolic gesture of the formal assignment of command, Brigadier General Blanchard passes the colors to Colonel Deaton, commander, 74th troop command, and senior commander to Delta Company. Colonel Deaton passes the colors to the subordinate commander, First Lieutenant John Ibrahim. The passing of the unit colors from the senior commander to the subordinate commander signifies the passing of his trust and also the responsibility for the unit and its soldiers. Lieutenant Ibrahim will now activate the unit. The colors are now passed from the incoming commander to the detachment First Sergeant signifying the confidence that the commander places in the non-commissioned officer corps and represents the First Sergeant's allegiance to his commander. Ladies and gentlemen, I now present to you the newest unit in the District of Columbia National Guard, Delta Company 223rd Military Intelligence Battalion. What that really means is that the organization now is truly on a glide path to whatever happens in the future. To the soldiers of Delta Company, you are the next generation of a long, long line of excellence. There is no greater honor than to lead soldiers of your character. I'm proud of every single one of you, but I charge you all with maintaining our most valuable resource, our people. So the activation of Delta Company within the DC National Guard creates a wealth of opportunities for recruiting.  Officers can join as all-source intelligence officers as 35 alphas. So we can sort of cast a wider net on prospective recruits that align with our mission and values. So our federal mission is to conduct interrogation, source operation, screening, and liaison and provide linguistic support for all Army echelons. The threat landscape is changing. It's evolving. The need for intelligence support grows as the threat grows. So our need to stay ahead of that and more importantly for the DC National Guard to stay ahead of that involves employing intelligence capabilities.


Hello everyone, I am E. Subashini. I have secured all India rank 229 in the civil services examination 2018. My optional is history and this is my third attempt. I have started my preparation with Shankaraya's academy and they have been a great support throughout my preparation. The constant support and motivation from my sister, my parents and relatives and a whole lot of friends have given me the confidence and determination to pursue this long journey. To all the aspirants out there, I would say have confidence in yourself and have perseverance. You will definitely achieve your goal all the best.


Countdown for Blastoff. X minus five. Four. Three. Two. X minus one. Fire. From the far horizons of the unknown come transcribed tales of new dimensions in time and space. These are stories of the future. Adventures in which you'll live in a million could be years on a thousand maybe worlds. The national broadcasting company in cooperation with Street and Smith publishers of astounding science fiction presents X minus one. Tonight's story, the castaways by Ernest Kenoy. In the South Pacific night comes on rapidly. The sun dips below the flat horizon. The sea is crimson for a moment and then night falls. But on to Honey Atoll, giant arc lights turn night into day. Across the waters of the lagoon within the barrier reef launches and tugs skitter back and forth. While on the curving half moon of the island, army trucks and jeeps scuttle down the rough roads bulldozed by the sea bees just six weeks ago. A low quonset hut stands near the beach surrounded by tangled wire. This is the preliminary command post. And inside is General Frank Gadosh, field director of the test. Operation destruction. Everything's on schedule, General. Radiological surveys complete. Instruments placement checked. Well, get me Navy and tell them H-Hours is ordered. Send a periodic time check to Air Force on 90-week talk and observation control on the Missouri. Yes, sir. I want a complete roster check on all personnel before H-Hours. Yes, sir. Oh, Nate Cohen wants to see you. Who the devil is he? AP man. He's been selected by the press radio pool to interview. I haven't got any time. Tell him to speak to Major Dwight Breedenburg. He's the P-R-O. I think perhaps you'd better see him, sir. The directive on public relations from Washington was very clear. Well, how on blazes am I supposed to run a bomb test and play Mother Hand to a bunch of reporters? Washington said... All right, all right. Bring him in. Barelli? Yes, sir. Give me some black coffee. Yes, sir. This is Mr. Cohen, General Gadosh. How do you do, General? Lousy, as a matter of fact. Is that an official statement? No. You can run some of that. The world is at the crossroads, Baloney. I wrote that yesterday. General, what effect do you think the new bomb will have on the world's situation? I can't tell you that, even if I knew. My job is to set the blasted thing off and see that nobody gets hurt and collect the data. Can I speak to you a moment, sir? Later, Allen. Go ahead, Cohen. Can you release anything on the scientific principles involved? I don't even understand them myself. Wait a minute. Dr. Mueller? Yes? Come over here a minute, will you? Cohen, this is Dr. Fred Mueller, civilian scientific director. He's the only one who knows what's inside that warhead. How do you do, Mr. Cohen? How about a statement, doctor? Oh, I'm afraid all I'm allowed to say is that the bomb is new. It's extremely powerful and off the record. It's very tricky and dangerous. What'll happen if it goes off prematurely? I don't think we have to worry about that. In fact, we wouldn't even know about it, if you'll excuse me now. How about the natives? Well, what about them? Aren't they going to be evacuated from the island? They already have been. General Gadoch? I saw that the honey chief outside when I came in. The whole tribe squatting down at the motor pool, having a conference. What? Allen! I've been trying to tell you, sir, that honey are still on the island. Well, why? The LCTs are ready, aren't they? Yes, sir, but they won't go. They refuse. The schedule called for their evacuation to Bailani three hours ago. I realize that, sir, but I hoped we could still get them off without vials. Look, Allen, they're either on the island or off. Wait a minute. Cohen, that's all. What are you going to do about the natives, general? Never mind. I'll issue a statement later. Go on. Get out. I haven't got time. All right, general. Thanks. Thanks a lot. All right, Allen. Let's have it. Well, sir, the honey have been kicking up all along. They won't leave. They won't. Do they know what's going to happen to the island? Do they know that we're going to blow it higher in the kites? I told the chief. He just said they won't go. They'll go all right if I had to... Yeah. Hey, get him in here. The chief? Yeah. And that lieutenant who interprets. Yes, sir. How do you like that, Dr. Mother? I haven't got enough trouble. You know, I feel rather sorry for the tani. Can't make much sense to them. We arrive and tell them they've got to get out. Look, I appreciate your finer feelings, Muller, but I can't let the Kanakas hold up the bomb test. They're not Kanakas, general. Captain Cook discovered the island in 1788. Well, what's the difference? Lieutenant Gilbert reporting, sir. Hey, look, I haven't got time for ceremony, Gilbert. Tell the chief he and his tribe have got to get off the island. We're providing homes for them on Maelani. Translate, Gilbert. The chief says you do not understand. Maelani is a bad island. My people have lived on tani from the time that our ancestors were cast away on the island. The spirits of our ancestors are buried in the earth. Our fathers are buried here. Our fathers' fathers. If he thinks I'm going to move his graveyard, he's crazy. In our ancestors' time, the tani came in a great bird canoe. We were cast away on this island. We have made it our home. What right have you now to carry us over the sea to a strange land where we would die weeping for our homes? We will not go. By the waters of Babylon, there we sat down and we wept when we remembered Zion. Well, thank you, Dr. Muller.  Hey, Gilbert. Yes, sir. Tell him I have no choice. He's got till midnight to get his tribe on board those LCTs peacefully or I'll have the marine detachment carry him aboard. Yes, sir. I'd rather harsh, General. After all, justice is on their side. We're preparing to blow up their island and we haven't asked them about it. Dr. Muller, will you kind of confine yourself to the scientific aspect to this operation? I'll take care of administrative matters. If you could explain to them what's at stake here. Any further explaining I've got to do, I'll do with the marine detachment. I'm not going to hold up my schedule. Well, Gilbert? I told him, sir. All right, get him out of here. I've had enough. No, no, no. Some kind of a curse, sir. I can catch some of it. The island will remember the tears of its children and punish the invaders. The great destroyers will not destroy. And the evil man who is the chief will travel far through the blackness of night, even as the children of the island and so will he. All right, Gilbert, take him away. You in here, sir. Colonel Allen. Get a detail from the marine detachment with tear gas and small arms down to the motor pool. And in one hour, have those natives on that transport. And I don't care how they do it. Is that my coffee, Virelli? Yes, sir. They must know about the bomb. The great destroyer will not destroy. You worried about that curse? I should think you might be. He threatened you personally.  The chief looked as if he'd cheerfully strangle you with his bare hands. I'm supposed to end the way they do. What's that? Probably that the honey is saying goodbye to their island. I think I'll go down to the motor pool. Well, stay out of the way. And get back here in an hour. You've got to have this wrapped up and headquarters moved out to the Missouri by dawn. Instrument room checking in, sir. That's the last. Have the Missouri take over control and send for my jeep. Yes, sir. Are the LCTs standing by for those natives? Yes, sir. They're on the beach. The Navy unit is assembled in place, General. 2330, right on the nose. Robin, start evacuation procedure. But the honey, you've stopped. Allen's probably moving them out to the beach. Check in with Navy and Air Force, Barelli. Yes, sir. What's that? Coming to the beach. But the honey making trouble. Come on. General! Hey, yo! What is it? Colonel Allen ordered the Marines. Well, what happened? The natives just got up and started marching. Did they embark? You don't understand, sir. They marched up the cliff and right off into the lagoon. All of them, the women and the kids, too. They didn't even try to swim. What were you doing all this time?  There was a marine detachment. We couldn't stop them, sir. They just walked over the cliff. They didn't even scream, not even the kids. We sent the crash boats out, but we couldn't get them any of them.  Were there any reporters there? Well, Cohen and a life photographer. Well, get his film and hold it till I release it. What are you going to do, General? Prespawn, H-hour? It's too late for that now. Calling H-hour off isn't going to bring the natives back. One hundred men, women and children just walking into the water. It's horrible. I know. I'm not happy about it either. There's nothing we can do now. I gave him a chance to get off. I was just thinking about the curse the chief put on you. Even as the children of the island end, so will he. That's what he said to you, General. I know. I heard him. Here, jeeps waiting, General. The great destroyer will not destroy. That must mean the bomb. Don't worry, Dr. Mueller. It'll take more than a mumbo-jumbo curse from a native witch doctor to stop this operation. At H-hour, that bomb goes off. H-hour minus one minute thirty seconds. H minus one thirty. Video screens hooked in, sir. Alright, check control stations. Observation station one. Observation station one, check. Radiation station. Radiation control check. Test the firing circuit, Dr. Mueller. Right, General. Damage control station. Damage control check. All set. Communication. All checked in, sir. It is H minus one minute. H minus one. Take a good look at that island on that screen, Dr. Mueller. When you throw that key, it just won't be there anymore. Nothing but an atom mushroom over the lagoon. Quite a funeral fire for the two honeys.  They can't get in the way of progress. Progress? I wonder if it is, General. It is H minus thirty seconds. H-hour minus twenty-nine. Twenty-eight. Twenty-seven. Twenty-six. A great destroyer. That's what he called the bomb. Hold it, Mueller. Island report. All checked in, sir. Cameras running. Sound fire warning. Stand by for firing. Ready, Mueller? Ready. Ten, nine, eight, seven, six, five, four, three, two, one. Fire. General, it didn't go off. The bomb didn't go off. Raleigh. Signals stand by. Condition read. Yes, sir. Allen, check readings. Mueller, what's wrong? What happened? I don't know. The bomb didn't go off. What do you mean? Why didn't it? I don't know except for one thing. The Tahani chief said the great destroyer would not destroy. It didn't, General. The bomb didn't go off. What about it, General? What happened? Have you got a statement? Nothing you can use, Cohen. Not till we find out what went wrong. Hey, who let you come aboard this ship? I walked on. You don't know why the bomb failed? It didn't fail. It just didn't go off. What's that tank thing on the deck, General? Undersea salvage unit, Mach 4. They call it a bottom crawler. Somebody going down? Well, that bomb is down there in the lagoon somewhere. Could go off at any second. Somebody's got to go down and find it and disarm it. That's a lovely job. Who's elected? I am. Wow. And Dr. Muller. He's the only one who knows how to dismantle it. All those ready, General. All right. Come on, Muller. I'm ready. Allen, as soon as we hit shallow water, get those gates open. We'll pull the crawler out. And then you get away in a hurry. If that bomb goes while we're working on it, I don't want any casualties. Yes, sir. Inside, Muller. All right. I'm in. Now, remember, get this LST out of the lagoon in a hurry. All right, Allen. You take your orders from Admiral Yancey. Yes, sir. Good luck. Closing the hatch. The radar and Geiger counter warmed up, Muller. I was just thinking of something, General. That curse, part of it came true. The bomb didn't go off. Well, the second part of that curse was that you would end where they ended. That was at the bottom of the lagoon. What are you trying to do, Muller? Nothing. I was just thinking this crawler is going to take us right down there where the Dahoney died. I'm not worried about a handful of dead natives, Muller. I'm worried about that bomb. Okay, they're opening the gate. Let's go. USU-4 to control. Depth 50 feet, bottom sandy, dropping off sharp. Anything on sonar, Muller? School of fish. You ever been down in a crawler before? Only in the tank at New London. I think I've got a Geiger reading dead ahead. Hang on, getting something on sonar now. Left to point. USU-4 to control, over. USU-4 to control, over. Find out the radio's out. Dead ahead. Looks too large to be the bomb. Can't see much on the forward vision plate. Hey, wait a minute. That's part of the reef ahead. That's where the Geiger reading indicated. The bomb must have settled in the hole in the reef. We'll have to go after it in diving suits. The suits are in the locker. Let's get this over with. The less time I spend down here waiting for that bomb to blow, the better I like it. Is your helmet clamp tight? You're getting me all right on your headset? I'm gonna fill the lock. Here goes the outer door. Let's go. Look out for that coral. It can cut you to ribbons. There's a hole. Where do I get the light up? See if you can get a Geiger reading out of that hole. Careful. I'll drop down first. Muller, get down here fast. Nothing. The bottom of this hole, it's metal and the sides. But it's the coral reef. Look, welded joints. These are hull plates of some kind. Look out above us. It's closing. Grab it. A metal hatch. It just slid over the top. This is impossible. What's going on? It's like an airlock. Realize what this means. I'm not sure. There's an inner door opening. Careful. There isn't much we can do. We can take off our helmets, though. The dial shows good air. All right. Come on. What is this? An undersea fort? What's it doing here? What does it mean? Whatever it is, our bomb must be down here. Wait. There's someone there. I can't see. There's a shadow. Who is it? Who's there? Welcome, Dr. Muller. Welcome to our ship. We've been waiting for you. General, it can't be. Do you see it? It's the T'Honey chief. How long has the bottom crawler been down, Birelli? Four hours, sir. Two since we lost contact. Now, keep trying. Yes, sir. I've given him enough time. I'm going to send another crawler down. What do you figure happened to him, Colonel? Well, there are a lot of things. Hey, how did you get in here? I walked in. When are you going to release this, Colonel? I'm going to tell you a story since the election. Bomb had been dead and Dr. Muller and General Gaydash had been dead. They're not dead. At least we don't know they are. As long as that bomb doesn't go off, there's still a chance that... Gilbert, radiation control interaction. Get the hot squad into T'Honey Lagoon as soon as it's cleared. And get me a PT boat with radiation screens. What is it, Colonel? What happened? Bomb must have blown. How about Muller and the general? If they were down there in that lagoon, you guess. Now get out of my way. I'm busy. Reading 75 and steady. Take her in as close to the beach as you can. Once she goes. Is there any danger of any more explosions? No. Once she goes, she goes. Radiation 82. That's still safe. Cohen, is that something on the beach? Yeah. Looks like a body. Maybe you blew one of the T'Honey back out of the lagoon. No, no. It's moving. Gilbert, glasses. Yes, sir. It's a man, all right. Head into the beach. Who is it, Colonel? I can't tell. He's in a diving suit. It's either Muller or General Gaydash.  Easy enough. Twist to the right. It's Muller. Gilbert, help me get him out of this diving suit. We've got to get him no medics. No radiation burns, superficial bruises, mild shock. He'll be all right, Colonel. Can he talk? For a while.  It didn't. He's still out of his head. Quiet, Cohen. Go on, Dr. Muller. What did you find? A ship. A giant metal ship there under the lagoon. Submarine? No, no. It was a spaceship. A spaceship? Camouflaged right next to the reef. When we went inside, we found that the honey chief and all the tribe are alive. What? They drowned in the lagoon. I saw them. No, they didn't commit suicide as we thought. They just dived underwater into the rocket airlock. Rocket airlocks? Now, look, Muller, I know you've suffered a shock, but... But it's true. It can't be. A spaceship built by Polynesian savages. They're not savages. They're the castaways. They're from another planet.  Their spaceship was wrecked here 400 years ago. They've been waiting ever since for a chance to go home. He's out of his mind. Better give him a sedative, doctor. No, no, no. Wait a minute, Colonel. Remember their story about the great bird canoe? Maybe there's something to the legend. Not the legend. It's true. They'd exhausted their fuel, came down out of space, couldn't find anything here on Earth to replace their fuel source until we developed atomic power. Atomic power? You mean they stole our bomb? That's right. Fished it out of the lagoon, hauled it aboard. Yes, but how could they convert it to atomic dry? They made me dismantle it for them at the point of a gun. Then just before they blasted off, they let me go. But what about the general? Remember the honey curse? I see. You mean they killed him? You don't understand. I said I dismantled that bomb at the point of a gun. It was General Gadas who was holding the gun. What? He was one of them, one of their spies sent out to bring back the rocket fuel they needed. And the honey curse wasn't a curse at all. It said that when they left the island, so would he. I mean, he's with them now? Yes. And after 400 years, the castaways are going home. You have just heard X-1 presented by the national broadcasting company in cooperation with Street and Smith, publishers of astounding science fiction. Your announcer Fred Collins. X-1 was an NBC radio network production.


Okay, so the continuation of that problem when molybdenum crystallizes, it forms body centered cubic cells. The unit cell edge is 314.1 picometers. Calculate the density of molybdenum. Okay, so now, remember in these density problems, we're going to have to find the number of lattice points per unit set. Okay, so that in this case is Z. Okay, number of lattice points for a body centered is just very similar to the simple cubic, right? Where you have one atom on each of the points there. So it's going to be eight times one divided by eight. But you have to add that one, the full atom that's inside the unit cell. When you do that, you get one plus one. So that's the first step of doing this. It also, well, let's write the formula down. So density equals Z times molar mass divided by side cubed times avogadro's number. Okay, so we know Z is two molar mass. What did I say it was? 95.994 grams per one. The side, remember, we want these densities in units of, it didn't say, but grams per cubic centimeter, okay? So it gives us the side in picometers 314.1 picometers. So how many centimeters is that going to be? Times 10 to the negative eight, seven. So it's a good one to remember because you're going to have to do this calculation a lot. Now, how did I do that, right? It was one times 10 to the 10 picometers per one, seven. And then avogadro's number, of course, that'll probably be given to you. But 6.022 times 10 to the 23rd, anything, in this case, atoms per mole. So now we'll chug, right? So Z, vanish units is two, all our mass, 95.94 grams per one mole divided by 3.141. It's got to be something in everybody, you know? Times 10 to the negative eight, 5.022 times 10 to the 23rd, divided by one mole, like that. Cancel, cancel, grams per cubic centimeter, all right? Okay, so 466, so I get 10.28 as the density of, what are we doing, we'll look to know. Is everybody okay with that one? Same answer, hopefully. Questions, questions? We could probably do these all day, all right? Okay, good.