Handling Authentication Secrets in the Browser Miguel Grinberg

About Me ● Software Dev @ Rackspace ● Author of O’Reilly’s book “Flask Web Development” ● APIs, Microservices, Socket.IO ● Python, JavaScript, C++ ● @miguelgrinberg ● blog.miguelgrinberg.com ● github.com/miguelgrinberg

The Basics

The Web is Stateless ● HTTP servers cannot “remember” clients from one request to the next ● Clients must provide some form of identification with every single request ● The concept of logging in and out is a high-level abstraction

Authentication with Username and Password ● The client gets credentials from the user and sends them with the request ● Most apps exchange username/password for a token or authentication cookie

Authentication with a Token ● The client obtains a token, then includes it in all requests as a header ● The token represents a user session ● Popular choice for rich-client web applications

Authentication Cookies ● The server sets a cookie with the client after successful authentication ● The browser sends the cookie back to the server in subsequent requests ● The cookie references a user session ● Traditional approach for thin-client web applications

Passwords vs Tokens ● Passwords ○ Are created by humans ○ Generally give full access to the user’s account ○ Generally do not expire or have a long expirations ● Tokens ○ Are generated by servers ○ Can have a scope associated with them ○ Generally have a relatively short expiration ● Cookies ○ A storage mechanism, so nothing like passwords or tokens ○ Convenient to use for authentication, because the browser sends them by itself ○ An authentication cookie normally stores a token

User Sessions ● Servers remember clients by creating “user sessions” for them ● A user session is a protected storage where the server stores user information ● Server-side user sessions are stored in databases or disk files ○ The server returns a reference to the session as a token, possibly in a cookie ● Client-side user sessions are returned to the client in a token or cookie ○ The contents of the session are cryptographically signed to prevent tampering ○ JSON Web Tokens is a popular standard for creating this type of session

Basic Protection Of Secrets

Use HTTPS (aka HTTP over TLS) ● This encrypts all traffic between the client and the server, with a key only known to these two parties ● User credentials cannot be intercepted while in transit, as long as all authentication cookies have the secure flag set ● Man in the middle attacks become much more difficult to pull off ● You can get free SSL certificates!

Harden the Server ● Strong passwords for all accounts, or disable password logins altogether ● No root logins ● Only expose necessary services on the public network ○ Your web and SSH servers will obviously need to be accessible ○ Databases, session stores, etc. can usually listen only on localhost or a private network ○ Add a firewall or set security group rules on your host(s) ● Application crashes should not expose internal information to the client ● Routinely install security updates

Browser Attacks

Cross-Site Scripting Attacks (XSS) ● An attacker injects random JavaScript code in posts or comments on your site ● When the victim views the affected page the attacker’s code executes ● The rogue script can upload cookies, local storage, DOM contents, etc. to an attacker controlled server

Mitigating XSS Attacks ● Treat all input received from clients as unsafe and needing sanitizing ● Use authentication cookies with the httpOnly flag set, so that they are not accessible to JavaScript ● Use tokens with short expiration time

XSS Attacks and Access Tokens ● With a compromised access token, an attacker can impersonate the user on the identity provider’s site ● Mitigation ○ Never expose shared secrets to a web browser application ○ Use a proxy endpoint in your server as intermediary ○ If you need to sign requests, let the server create “pre-signed” URLs

Cross-Site Request Forgery (CSRF) ● An attacker-controlled site issues requests to your server on behalf of the user ● When the user visits the malicious site, requests to your API go out with valid authentication cookies stored by the browser in a previous session

Mitigating CSRF Attacks ● Check that the Origin and/or Referer HTTP headers have the expected value ○ These headers cannot be set from JavaScript in modern browsers ● Add a “synchronizer” token to all web forms and XHR requests ● Use a JWT or similarly signed token for authentication ○ Do not store it in a cookie!

Dealing with Compromised Credentials

There Is No 100% Foolproof Security ● All systems are subject to attacks or leaks ● We developers are human and make mistakes ● Users are also human, and tend to be careless ○ They tweet out their passwords by mistake! ○ They use the same password on many sites, so they can be compromised elsewhere ○ They install dubious browser extensions that are spyware ○ They access your site from a compromised computer

Responding to a Leak or Attack ● You should have a plan in place, so that attacks are handled swiftly ● If a token is compromised, revoke it immediately ○ You should have an easy way to revoke tokens, don’t edit your database by hand! ● If a user reports suspicious activity on their account, reset the account ○ Revoke all active tokens for the user ○ Ensure that user information hasn’t been altered as part of the attack ○ Force the user to reset their password on the next login ● If you think your server was compromised, use the “nuclear option” ○ Revoke your current SSL certificate and request a new one ○ Force all users to set a new password on their next login ○ Change your token signing key (this will effectively revoke all active tokens for all users) ● Make sure you have automated tests in place for all the above measures!

Summary

Summary ● Use secure HTTP and harden your server ● Routinely audit your application to detect code injection vulnerabilities ● If XSS attacks are possible or if you are not sure ○ Store authentication credentials in a httpOnly and secure cookie (XSS protection) ○ Validate the Origin and Referer headers (base level CSRF protection) ○ Add a CSRF token to all web forms and ajax requests (strong CSRF protection) ● If XSS attacks are not possible (users cannot post content that others can see) ○ Do not store credentials in a cookie. Pass auth tokens in a header (CSRF protection) ● Do not use signing keys, access tokens or other secrets in the browser ● If you use JWTs, validate the signing algorithm ● Know that you are still vulnerable, and have a mitigation plan in place!

Thank You! @miguelgrinberg Slides: bit.ly/auth-secrets Blog post: bit.ly/auth-secrets-blog