INVITATION TO CYBERSECURITY 200 hacker would have access to all their accounts that rely on SSO. This is the keys to the kingdom dilemma. It is convenient for users to have fewer keys, but if those keys open more doors, then they become bigger targets and do more damage if compromised. 8.1.6 Authentication on the Web Local authentication does not need cryptography, but authentication over the network clearly does. Since the Internet has an open infrastructure and all messages are assumed to pass though many “untrusted hands” between endpoints, passwords cannot be sent in plaintext. This problem cannot be fixed with password hashes. If a password is hashed locally and then the hash is sent over the network to the server, then this just makes the hash the authentication token instead of the password. The hash can just as easily be observed by a hacker and used in a credential stealing attack. Therefore, every time a person logs into a website by typing in a username and password, this information must flow over an already-established cryptographic channel to prevent eavesdropping attacks. These cryptographic channels are established between web browsers and web servers over HTTPS connections. The S stands for secure and it means that an end-to-end encrypted channel is created. Multiple messages are passed between the web browser and web server as part of the connection handshake, and the handshake typically establishes web server authentication, message integrity, and message confidentiality for the data to follow. Authentication is common when browsing the web. Social media sites, email accounts, work and school-related accounts, and ecommerce websites all require repeated authentication while browsing. Because the HTTP protocol is stateless, every page visit is a brand new request from the web server’s perspective. Stateless means that the web server does not retain any information about previous interactions. It is as if the web server has amnesia—every time a web server answers a request for a new webpage, it treats it as a firsttime encounter with a never-before-seen user. For example, on amazon.com, every page visited while searching for products, adding items to the shopping cart, and then during checkout requires the user to be authenticated to Amazon—a quick and simple shopping session could generate dozens of unique webpage requests. However, the user is typically only asked to login once at the beginning of the browsing session, and sometimes not even then if the website is set to “remember” the user. How do web servers authenticate users on pages where no login information is provided? Web browsing authentication is handled transparently in the background by web browsers using authentication cookies. An authentication cookie is a text string assigned to a web browser by a web server for the purposes of authenticating a user. When a user successfully logs into a website by providing his authentication token (e.g., username and password), the web server creates an authentication cookie in its database and sends a copy to the web browser (see Figure 8.4). The web browser stores the cookie and sends it back to the web server with every new page request for that website. Web servers inspect
RkJQdWJsaXNoZXIy MTM4ODY=