Very useful presentation, it clarifies a few things that puzzled me regarding authentication. On a sidenote, do NOT use the "client-sessions" package he mentions. It's currently abandoned and not maintained. It hasn't been updated in five years and it seems there's nobody there to accept pull requests. You can check the NPM and Github pages for confirmation of this. I'm not sure what a good replacement for that package would be.
This was great, and interesting to learn, and going back to Colt Steele's course, now I have to do all authentication using a library (passport) where I don't even understand the underlying logic behind the lines of code (from how it is explained in the course). I guess I'll just have to go through passport docs in detail and try to draw parallels between those explanations and what was taught here by Randall, to connect the dots. Then there is the fact that the authentication used under the hood in passport is probably different from what Randall used. Sigh. PS: I know that I have to use a library and that not using one is dangerous, especially as a complete beginner.
Wonderful tutorial! I'm one of those people that has to understand the inner logic of something to learn it properly, and I can easily say I am overly satisfied with this lecture. Thanks a lot!
Wow ... Such an amazing lecture. All the discussed concept including node, express, servers and especially authentication were explained in a clear and simple manner. Thank you so much sir, now I have a clear picture of where I am headed as far as web authentication is concerned.
Quality teacher right here.. I couldn't find a good explanation like this elsewhere. I can log my req.session.userId, but the response header is not being set. I have sessions middleware configured the same and my login findOne method returns a valid user, but still no response header. I'll update if I find out why not. I can access the dashboard despite the check for req.session.userId, which means that I do have a session.But It's not showing any res header. My raw header from my POST to login looks like this: HTTP/1.1 302 Found X-Powered-By: Express Location: /dashboard Vary: Accept Content-Type: text/html; charset=utf-8 Content-Length: 64 Date: Tue, 19 Mar 2019 16:19:54 GMT Connection: keep-alive I dont see set cookie or anything like that. I'm wondering if something is hiding the information?
Yes. But you must always hash them again in the server, otherwise the hash becames the password and an attacker with database access can just use that.
Is there a reason why the Login form data is visible on the headers tab (see when Randall shows us the video of him copying and pasting the request headers -- at the bottom of that headers tab) when a login form is submitted as a post request?
Your login page could hash the users password in the browser then send that, In this way you not only offload that work to the users browser, but the users password never traverses the internet, nor is ever handled by your system.
Not sure I understand the last part on the video ( about hash computing ), the hash computing is happening on the server side so a brute force will slow down the server ? and not the client, pretty sure I'm missing something here.
Hi, so.. I'm 3 years late and you may have figured this out already, but you are correct if the code was executed as written. In order for this to be effective, the password hashing would have to take place on the client's computer, then the password hash would be sent in place of the password. However, most sites use something along the line of "you have been locked because you entered too many wrong passwords" so an attacker would do this. Instead, this is meant to slow down an attacker who has breached the database. This is assuming the attacker has the password hash (and email and etc.) and is trying to brute force that hash by generating his own hashes based on things like rainbow tables. Databases are much easier to breach than trying to login over and over, which is why it's important to make sure any sensitive data on the database is encrypted in this way.
I think you mean what hashing algo does passport use? I found this - "Passport-Local Mongoose use the pbkdf2 algorithm of the node crypto library. Pbkdf2 was chosen because platform independent (in contrary to bcrypt). For every user a generated salt value is saved to make rainbow table attacks even harder."
whos here from colts udemy course......hit like
trying to finish the course while in the quarantine
@@dddanielsr same bro...where are you from?
@@dddanielsr same :) and it turned out I've learnt a lot with this video. What about you guys?
@@chirag3409 I'm from Ecuador bro!
@@rozneg this video is gold
I wish this guy had a lecture series!
Hands down one of the best tutorials and breakdown of Secure Authentication on the Internet.
Very useful presentation, it clarifies a few things that puzzled me regarding authentication.
On a sidenote, do NOT use the "client-sessions" package he mentions. It's currently abandoned and not maintained. It hasn't been updated in five years and it seems there's nobody there to accept pull requests. You can check the NPM and Github pages for confirmation of this.
I'm not sure what a good replacement for that package would be.
why aren't there more talks like this. Incredibly good and clear
this man is legend..he helped me a lot to understand website authentication very easily without using so many libraries
This was great, and interesting to learn, and going back to Colt Steele's course, now I have to do all authentication using a library (passport) where I don't even understand the underlying logic behind the lines of code (from how it is explained in the course). I guess I'll just have to go through passport docs in detail and try to draw parallels between those explanations and what was taught here by Randall, to connect the dots. Then there is the fact that the authentication used under the hood in passport is probably different from what Randall used. Sigh.
PS: I know that I have to use a library and that not using one is dangerous, especially as a complete beginner.
It was really like a fantasy movie...i feel sorry for any newbie who didn't watch it...its gold video in layman terms
Wonderful tutorial!
I'm one of those people that has to understand the inner logic of something to learn it properly, and I can easily say I am overly satisfied with this lecture.
Thanks a lot!
Wow ... Such an amazing lecture. All the discussed concept including node, express, servers and especially authentication were explained in a clear and simple manner.
Thank you so much sir, now I have a clear picture of where I am headed as far as web authentication is concerned.
Came from Colt's Udemy course - great video. Really great at explaining the concept in a relaxed easy to follow manner. Thank you!
Me too
This guy is the best. The way he explained. MY GOD!!!
23:36 I love this guy he speaks the way I used to when I was younger. If I did not get a corporate job I would still have sounded like him tbh.
Amazing talk. great presentation skill and going through very casually on a topic that is considerd 'hard' for many. Thank you!
Quality teacher right here.. I couldn't find a good explanation like this elsewhere. I can log my req.session.userId, but the response header is not being set. I have sessions middleware configured the same and my login findOne method returns a valid user, but still no response header. I'll update if I find out why not. I can access the dashboard despite the check for req.session.userId, which means that I do have a session.But It's not showing any res header. My raw header from my POST to login looks like this:
HTTP/1.1 302 Found
X-Powered-By: Express
Location: /dashboard
Vary: Accept
Content-Type: text/html; charset=utf-8
Content-Length: 64
Date: Tue, 19 Mar 2019 16:19:54 GMT
Connection: keep-alive
I dont see set cookie or anything like that. I'm wondering if something is hiding the information?
EXCELLENT EXPLANATION!
Thanks Randall, you are inspiration to many like me.
Should I hash passwords from frontend before sending to server?
Yes. But you must always hash them again in the server, otherwise the hash becames the password and an attacker with database access can just use that.
Hello guys, I have this ERROR after I wrote the app structure: Unexpected block vars. Any idea?
Is there a reason why the Login form data is visible on the headers tab (see when Randall shows us the video of him copying and pasting the request headers -- at the bottom of that headers tab) when a login form is submitted as a post request?
Great discussion on Authentication.
Superb content & a great delivery - props to the speaker!
Your login page could hash the users password in the browser then send that, In this way you not only offload that work to the users browser, but the users password never traverses the internet, nor is ever handled by your system.
Surprised he didn't challenge anyone to a arm-wrestling competition after his presentation :)
Thanks for this Randall, I thoroughly enjoyed it!
You are amazing!
Learned a lot thanks
Cool! Glad you enjoyed it
@Rendall watching it in 2018 - great talk and amazing examples 👍 keep up the good work man
Absolutely awesome!
Thanks for the tutorial. I really like the simple examples ^^
Great explanation 👍😀
Not sure I understand the last part on the video ( about hash computing ), the hash computing is happening on the server side so a brute force will slow down the server ? and not the client, pretty sure I'm missing something here.
Hi, so.. I'm 3 years late and you may have figured this out already, but you are correct if the code was executed as written. In order for this to be effective, the password hashing would have to take place on the client's computer, then the password hash would be sent in place of the password. However, most sites use something along the line of "you have been locked because you entered too many wrong passwords" so an attacker would do this. Instead, this is meant to slow down an attacker who has breached the database. This is assuming the attacker has the password hash (and email and etc.) and is trying to brute force that hash by generating his own hashes based on things like rainbow tables. Databases are much easier to breach than trying to login over and over, which is why it's important to make sure any sensitive data on the database is encrypted in this way.
i fucks with this guy
What an excelent video, learned a lot
extremely valuable, thank you
Awesome. Dude
Glad you liked it! =D
thank you, i learned a lot
express has body-parser built-in new versions
Awesome!!!!
43:25 I laughed at that hahaha
Thank you sir
Gold
Master
What a chad
What hashing alg uses passport?
I think you mean what hashing algo does passport use? I found this - "Passport-Local Mongoose use the pbkdf2 algorithm of the node crypto library. Pbkdf2 was chosen because platform independent (in contrary to bcrypt). For every user a generated salt value is saved to make rainbow table attacks even harder."
22:28 explainse why jwt is bad and where to use it. using wjt in cookie is bad practice. use jwt for api and token authhentication
Could you please add an English subtitle? It's very hard to understand what he's saying. He speaks so fast :)
It was really like a fantasy movie...i feel sorry for any newbie who didn't watch it...its gold video in layman terms