Web Authentication APIs

HTTP Auth & Password Security

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web Authentication APIs

Check out a free preview of the full Web Authentication APIs course

The "HTTP Auth & Password Security" Lesson is part of the full, Web Authentication APIs course featured in this preview video. Here's what you'd learn in this lesson:

Max begins outlining some security risks facing web applications. Web authentication strategies like HTTP Auth and password security are also introduced in this lesson.


Transcript from the "HTTP Auth & Password Security" Lesson

>> So today, we will be focusing on creating our own custom authentication system, and we will be using an identity provider as well. So we will connecting our system from an identity provider, okay? So we will see how that works also. So authentication on the web, let's start talking about the current state before actually writing some code.

So security risk, this is not a security workshop, okay? There are a lot of things to talk about security, but let's go over the basics just to understand why we need to do some things. So we have man-in-the-middle attacks. That's actually an attack that someone that is not the client or the server can attack typically through the network, or it can be something else, but typically through a network.

So it's not the server, no one is hacking the server, no one is hacking the user, someone is hacking the middle, okay? That's kind of the idea of this attack. Keyloggers, meaning the user is typing a password in a keyboard, it can be a physical keyboard or it can be a keyboard that you install on your phone.

So when you install a custom keyboard, if you install a keyboard that's kind of a phishing keyboard, you download it from an untrusted source because someone told you it's the best keyboard in the world that is only for special people, okay? And you go on download by an APK, an Android package, not from the Play Store, from somewhere.

Well, that keyboard will actually be listening to your passwords, for example. So another security risk is easy to guess password, okay? So, 80% of the data breaches right now are happening because of easy to guess passwords, 1, 2, 3, 4, 5, okay, and the name of my dog, the name of my mom, and so on.

That's why, okay, there are a lot of websites asking us with many rules to increase the security of our passwords, and that typically annoys us a lot as users, okay? So web servers and databases attacks, okay, every day, we are seeing news in the media about this happens.

This is happening actually in many companies, small companies, large companies, governments, where their servers are attacked somehow, it doesn't matter how, and they get the data. And that data may involve your credentials. Phishing, social engineering attacks, in this case, they're attacking the user and not the server. Phishing is a website that is trying to mimic the real website, but it's not a real website.

I mean, it feels like paypal.com, but it's not paypal.com. We have a typo in the URL and the user think it's PayPal, and the user is entering credentials there and they're stalling your data. They're stalling your credential typically to steal your money, okay? And social engineering attacks is that when they send you an email, or you receive a phone call, okay, and you pick up the phone call and they somehow trick you into giving them your credentials, giving them your password, okay?

So these are security risks that are out there, and we as full stack developers, we need to try to do whatever we can to reduce these risks. We cannot remove the risks, that's impossible actually, but we need to do everything we can to reduce the risks. Make sense?

So originally on the web, I mean I haven't started doing websites in 1995, and originally we were talking about HTTP authentication and login forms, okay? So we are going to analyze what happens or where are the risks here in a second. Originally, I say originally, I mean from the 90s, but still today, 50% of the websites are using this technique.

So you were in the browser, so you are the user, okay? You have a secret, that's your password. You type your secret in a form. It can be an HTML form, or I mean, it's not something that you see these days, but HTTP supports basic authentication, I'm not sure if you have seen that, okay?

I'm talking about the the era of Internet Explorer and Netscape, but it is still working these days. So instead of you designing a form in HTML, the browser will provide you a form ,a native form, okay, and you type a username and password there. And the username and password goes in HTTP headers.

They travel through HTTP headers to the server. Anyways, at the end, it's just the same thing. It's the web designer designing a form, or the browser deciding a form, but the data actually, that password is coming from the user to the browser through a keyboard, maybe, again, beautiful keyboard on a phone or a tablet or a physical keyboard.

From the browser, it goes to the server of our HTTP, and typically the server will store that in a database. So that's simple to follow, okay, I think you know that. And typically, it's using HTTP as a protocol originally, okay? Well, what was the original problem of the web during the 90s?

Well, in this diagram, we have at least two panes of failure, the keyboard and HTTP, why? Because on HTTP, everything goes in plain text. So the man in the middle were a pretty common attack, okay, there. I mean, just to give you a quick sample, you go to Starbucks to a public Wi Fi, with some Linux knowledge, you could get into the router, into the Wi Fi router from Starbucks.

And then you can see every HTTP request that everyone at Starbucks is doing right now, including all the credentials of the login credentials that users were typing on HTTP sites. But we know that these days, HTTP sites are not a good idea. We should upgrade to HTTPS, okay?

And with HTTPS, what happens is that there is encryption between the browser and the web server, so the man in the middle cannot actually see your credentials, okay? So we are solving that problem, but we still have other problems. For example, an attacker can get into the server.

All the data breaches out there from large companies, this is what happens, okay? So even with HTTPS, I mean, some people say, it's HTTPS, it's secure. No, actually, no, in fact, today, anyone can get an HTTPS server. And even if the browser says secure in the URL bar, yeah, we know, that's just from the browser to the server, okay?

In fact, today, I mean from 2020, I think, or 2019, on every browser, if you have a form, a login form or a registration form with a password on HTTP. The browser will give the user a red warning saying be careful, this site is not secure, and sending this data can lead to your credentials to appear somewhere else, okay?

So we still have that risk. And also, we have the risk of the user, that's the user typing the password in places where it's not the right place or that's phishing, okay? Or it can be social engineering attacks, you are giving an attacker the password, okay? And sometimes there are even weird situations, for example, sometimes you're on an app, for example, it can be a QR code reader.

I mean, you went to the Play Store on Android or on App Store on iOS, and you downloaded a QR code reader, because you don't know that today, you don't need to, you can use just the camera app. But let's say you go to the store and download a QR code reader.

So then you take a picture of a QR code with your phone and the website is being rendered in an inner browser using a WebView, not really your real browser, the QR code browser. And actually, that QR code app that is rendering your app on the website on top of that can read what you're typing in the website.

So maybe the website is the right website. Maybe you don't have a keylogger, but the browser is kind of a fake browser. It's actually pretty simple to develop that solution, okay? Of course, if someone finds that in the Play Store, they can report that and the Play Store will remove that from the store, but anyway, you don't know what happened.

So sometimes the stores, the QA team will not actually see that, okay? So that's why we need to be very careful on where are you typing your credentials, okay?. Sometimes if it's not the browser, be careful, because that's not the browser and that app can actually see what you're typing, okay?

So, Easy to guess passwords and also reusage of the same password, even if you have a very complex password, but you use the same password on every website, it's a risk, okay? It's a risk, why? Because, yeah, if that server is hacked and it has a data breach, they will get that complex password that you are using and then they try that password on other websites, and you're using the same one everywhere.

So password managers help with both problems, because they create really complex passwords and different passwords per website or per app, okay? But it's adding another problem, or another point of failure. First, we won't remember those passwords, so we always need the password manager. So then you say, okay, I'm in Japan on vacations.

I don't have Internet here, but my hotel has a computer and I can log in there, and then I don't have the password, then I don't have the password manager, okay? So you can login in the password manager, but then the password manager is an entry point of failure, because someone can get my password manager password with a keylogger, so yeah.

So, I mean, we are better than before, but it's still not ideal, okay? And what happens is the password manager is hacked. Well, some password manager, they have a vault and that's encrypted on my phone or with a key on my phone, but what happens then if I lost my phone?

So there is always a problem, okay? And by the way, there is no silver bullet here. There will be always problems, but we need to try to find the balance between security and user experience. And right now, yeah, we are adding more security, but we are lowering down user experience.

When we are doing that, okay, users will start doing weird things, such as taking a Post-it and writing down a password in a Post-it in the office. You've seen that, I guess. I have a couple of pictures from many places that I've seen where people were doing this, posting Post-it somewhere, a piece of paper, because, yeah, the password is really complicated.

I've seen people writing down all their passwords in a paper notebook. At home, they have a paper with all the passwords written down, okay? Because the user experience is so bad to actually because we were increasing security that at the end, it's not working, okay? So for example, I'm not sure if you have seen this website, so I encourage you to try it if you haven't.

It's open source, so it's from the community, so it's safe to use, let's say that. So actually, you can put here your email address or your phone, okay, and it will tell you if your email has appeared in any data breach, okay? There's a good chance, actually pretty high, that it's going to be a yes for you.

And the same happens with passwords. In fact, today, if you're using Google Chrome, or if you're using Safari for browsing the web, every time you log in in a website with a password that has been part of a leak, I'm not sure if you've seen that. You receive a message saying, hey, this password has been used in a leak, maybe it's time to change the password, Okay, because unless you have just created an email five minutes ago, there is a good chance that your email and maybe your credentials, because they were in plain text or they were hashed, I don't know, your credentials were also leaked.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now