WebFund 2024F Lecture 17

Video

Video from the lecture for November 14, 2024 is now available:
Notes

Lecture 17
----------
 - Assignment 2 grades are mostly out
    - if you submitted late or there was a formatting issue, still need to clean that up
 - T5 and T6 were due yesterday, still time for T7
 - Assignment 3 is due on Nov 20th

Agenda for today
 - questions about A3
 - T8 (code in progress)

Why do validation on the server?
 - we can't trust that client code has run or run properly
    - server can receive arbitrary GETs and POSTs
 - so normally validation on the client is for the convenience of the user,
   real validation happens on the server
 - so A3Q5 means that the validation of the submission that is happening in the browser now should ALSO be done on the server

Remember the point of education is to learn how to solve problems
 - I'm here to help you learn this
 - but also this is a basic skill that is beyond the scope of this class

import & export
 - import - load an external javascript file
 - export - make functionality available when this file is imported by another

import is like #include in C/C++, except there is no preprocessor
 - everything is just JavaScript code

export is basically marking variables/functions as public, with the rest defaulting to private (only visible within the JS file, not outside of it)

import/export are mechanisms for playing with JavaScript scope
 - combining the scopes of separate files which normally would be
   completely separate

note that import/export has NOTHING to do with whether code is server or client side
 - same import/export works both on the client and server
 - however, you cannot import/export ACROSS this boundary
   - if code is server side, import/export code is also server side
   - if code is client side, import/export code is also client side

Why shouldn't web servers store passwords directly?
 - then if the server was compromised, user passwords could be stolen easily
 - need to store password information "securely"
 - solution: password hashes

Why do we hash passwords?
 - so that if the authentication database is compromised, attackers
   will have to work to figure out what the passwords are

Secure hashes are designed to be one way functions
 - If you have X, it is easy to calculate hash(X)
 - if you have hash(X), it is NOT EASY to get X

In general, the only way to go from hash(X) => X is to
 - guess G
 - calculate hash(G)
 - see if hash(G) = hash(X), if so, you've figured out
   X = G

it can require LOTS of guessing, and hash functions can be made hard
to calculate so guessing is very expensive

These attacks can be sped up because most people don't pick random passwords. So instead, you can guess using a "dictionary" of likely passwords.
 - the dictionary can have classic variants like @ for a, so it can guess p@ssword


Note there are protocols for doing password authentication without sending the password in the clear to the server
 - not sure if it is used in practice in web applications,
   because of how they are structured
 - but they are used in other contexts where the server can trust client code

IN GENERAL, as an application developer don't worry about these security issues
 - instead, use standard solutions which implement best practices
 - if you do this on your own, you'll mess it up, trust me
    - even security experts mess up, which is why they review each others' work