https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=WebFund_2024F_Lecture_17 2026-05-12T21:38:55Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2024F_Lecture_17&diff=24844&oldid=prev 2024-11-14T20:03:14Z

<p>Created page with &quot;==Video== Video from the lecture for November 14, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec17-20241114.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec17-20241114.cc.vtt auto-generated captions] ==Notes== &lt;pre&gt; Lecture 17 ---------- - Assignment 2 grades are mostly out - if you submitted late or there was a formatting issue, still need to clean tha...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture for November 14, 2024 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec17-20241114.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec17-20241114.cc.vtt auto-generated captions]<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 17<br /> ----------<br /> - Assignment 2 grades are mostly out<br /> - if you submitted late or there was a formatting issue, still need to clean that up<br /> - T5 and T6 were due yesterday, still time for T7<br /> - Assignment 3 is due on Nov 20th<br /> <br /> Agenda for today<br /> - questions about A3<br /> - T8 (code in progress)<br /> <br /> Why do validation on the server?<br /> - we can&#039;t trust that client code has run or run properly<br /> - server can receive arbitrary GETs and POSTs<br /> - so normally validation on the client is for the convenience of the user,<br /> real validation happens on the server<br /> - so A3Q5 means that the validation of the submission that is happening in the browser now should ALSO be done on the server<br /> <br /> Remember the point of education is to learn how to solve problems<br /> - I&#039;m here to help you learn this<br /> - but also this is a basic skill that is beyond the scope of this class<br /> <br /> import &amp; export<br /> - import - load an external javascript file<br /> - export - make functionality available when this file is imported by another<br /> <br /> import is like #include in C/C++, except there is no preprocessor<br /> - everything is just JavaScript code<br /> <br /> export is basically marking variables/functions as public, with the rest defaulting to private (only visible within the JS file, not outside of it)<br /> <br /> import/export are mechanisms for playing with JavaScript scope<br /> - combining the scopes of separate files which normally would be<br /> completely separate<br /> <br /> note that import/export has NOTHING to do with whether code is server or client side<br /> - same import/export works both on the client and server<br /> - however, you cannot import/export ACROSS this boundary<br /> - if code is server side, import/export code is also server side<br /> - if code is client side, import/export code is also client side<br /> <br /> Why shouldn&#039;t web servers store passwords directly?<br /> - then if the server was compromised, user passwords could be stolen easily<br /> - need to store password information &quot;securely&quot;<br /> - solution: password hashes<br /> <br /> Why do we hash passwords?<br /> - so that if the authentication database is compromised, attackers<br /> will have to work to figure out what the passwords are<br /> <br /> Secure hashes are designed to be one way functions<br /> - If you have X, it is easy to calculate hash(X)<br /> - if you have hash(X), it is NOT EASY to get X<br /> <br /> In general, the only way to go from hash(X) =&gt; X is to<br /> - guess G<br /> - calculate hash(G)<br /> - see if hash(G) = hash(X), if so, you&#039;ve figured out<br /> X = G<br /> <br /> it can require LOTS of guessing, and hash functions can be made hard<br /> to calculate so guessing is very expensive<br /> <br /> These attacks can be sped up because most people don&#039;t pick random passwords. So instead, you can guess using a &quot;dictionary&quot; of likely passwords.<br /> - the dictionary can have classic variants like @ for a, so it can guess p@ssword<br /> <br /> <br /> Note there are protocols for doing password authentication without sending the password in the clear to the server<br /> - not sure if it is used in practice in web applications,<br /> because of how they are structured<br /> - but they are used in other contexts where the server can trust client code<br /> <br /> IN GENERAL, as an application developer don&#039;t worry about these security issues<br /> - instead, use standard solutions which implement best practices<br /> - if you do this on your own, you&#039;ll mess it up, trust me<br /> - even security experts mess up, which is why they review each others&#039; work<br /> &lt;/pre&gt;</div>

Soma