PhD / CTO TailorDev

Graduated from IUT, ISIMA, Blaise Pascal University. Worked at:

• Michelin (Clermont-Fd, France);
• Nelmio (Zürich, Switzerland);
• e-TF1 (Paris, France);
• Prizee.com (Clermont-Fd, France).

Open-Source evangelist:

• Lead developer of Geocoder, and several other projects;
• (Inactive?) Contributor on Symfony.

twitter.com/couac  |  github.com/willdurand  |  williamdurand.fr

Computer security is information security as applied to computers and networks.

Information security is the practice of defending information from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction.

Agenda

• Securing The Web
• Authentication
• Authentication Mechanisms
• Authorization
• Web Security 101
• IP tracking

• Secure Sockets Layer (SSL)
• Transport Layer Security (TLS)
• HTTPS

Asymmetric encryption or public-key cryptography uses a separate key for encryption and decryption.

Anyone can use the encryption key (public key) to encrypt a message.

However, decryption keys (private keys) are secret.

The most common asymmetric encryption algorithm is RSA.

Symmetric encryption or pre-shared key encryption uses a single key to both encrypt and decrypt data.

Both the sender and the receiver need the same key to communicate.

The larger the key size, the harder the key is to crack.

Popular symmetric algorithms: Blowfish, AES, Twofish.

Protocol developed by Netscape Communications Corporation.

Provide security and privacy over the Internet.

Maintains the security and integrity of the transmission channel by using encryption, authentication and message authentication codes.

Use asymmetric encryption techniques to generate a shared secret key, which avoids the key distribution problem.

It's all about authentication, privacy, and integrity.

Versions

• 1.0 developed by Netscape, never publicly released;
• 2.0 released in February 1995, but contained some security flaws;
• 3.0 released in 1996, RFC 6101.

During both client and server authentication there is a step that requires data to be encrypted with one of the keys in an asymmetric key pair and decrypted with the other key of the pair.

In a nutshell

1. Generate a key pair (public and private key)
2. Use a X.509 certificate to wrap public key
3. Exchange CA-signed public keys

An entity that issues digital certificates.

It's a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.

When server presents certificate to client during SSL handshake, client will attempt to verify signature against a list of known good signers.

Web browsers normally come with lists of CAs that they will implicitly trust to identify hosts.

If the authority is not in the list, as with some sites that sign their own certificates, the browser will alert the user that the certificate is not signed by a recognized authority and ask the user if they wish to continue communications with unverified site.

Well-known Certificate Authorities: Comodo, GeoTrust, or VeriSign.

The SSL client and SSL server agree an encryption algorithm and a shared secret key to be used for one session only.

All messages transmitted between the SSL client and SSL server are encrypted using that algorithm and key, ensuring that the message remains private even if it is intercepted.

Symmetric algorithms supported in SSL are: DES, 3DES, ARCFOUR, AES, Camellia, RC2, IDEA, SEED, NULL (no encryption).

SSL provides data integrity by calculating a message digest (fingerprinting).

Message integrity refers to maintaining and assuring the accuracy and consistency of the message.

Cryptographic protocol that provides communication security over the Internet.

Internet Engineering Task Force (IETF) standard, described in RFC 5246, and based on SSL.

Implemented on top of the Transport Layer.

Composed of two layers:

• the TLS Record Protocol;
• the TLS Handshake Protocol.

Versions

• 1.0 released in January 1999, RFC 2246;
• 1.1 released in April 2006, RFC 4346;
• 1.2 released in August 2008, RFC 5246.

TLS Record Protocol

Negotiate a private, reliable connection between the client and the server.

Use symmetric cryptography keys to ensure a private connection. This connection is secured through the use of hash functions generated by Message Authentication Code.

TLS Handshake Protocol

Allow the server and the client to speak the same language, with a determined encryption algorithm and determined encryption keys.

Use the same handshake protocol procedure as SSL.

SSL vs TLS

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0.

TLS 1.0 is "SSL 3.1".

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library.

This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

More information at: http://heartbleed.com/

The main idea of HTTPS is to create a secure channel over an insecure network.

HTTPS URLs begin with https:// and use port 443 by default, whereas HTTP URLs begin with http:// and use port 80 by default.

HTTPS encrypts and decrypts user page requests as well as the pages that are returned by the web server. The use of HTTPS protects against eavesdropping and man-in-the-middle attacks:

• Authentication Factors
• Two-Factor Authentication
• Weak Authentication
• Strong Authentication

Authentication is the mechanism whereby systems may securely identify their users.

Authentication systems provide an answers to the questions:

• Who is the user?
• Is the user really who he/she represents himself to be?

Authentication systems depend on some unique bit of information known only to the individual being authenticated and the authentication system: a shared secret.

In order to verify the identity of a user, the authenticating system typically challenges the user to provide his unique information.

If the authenticating system can verify that the shared secret was presented correctly, the user is considered authenticated.

The ways in which someone may be authenticated fall into three categories, based on what are known as the factors of authentication: something the user knows, something the user has, and something the user is.

Each authentication factor covers a range of elements used to authenticate or verify a person's identity.

The three classes are:

• the ownership/possession factors: something the user has;
• the knowledge factors: something the user knows;
• the inherence factors: something the user is or does.

Something the user has.

Security Tokens

Dallas iButton

Non exhaustive list:

• Cell Phones
• Connected tokens
• Magnetic stripe cards
• Software tokens
• USB tokens
• Wireless

Something the user knows.

Knowledge factors is the most common form of authentication used. In this form user is required to prove the knowledge of a secret in order to authenticate.

• Challenge Question
• Password
• Pass Phrase
• Pattern (on Android devices for instance)
• Personal Identification Number (PIN)

Something the user is.

• Fingerprint
• Retinal Pattern
• DNA sequence
• Signature
• Face
• Voice

Definition

Multi-factor authentication is an approach to authentication which requires the presentation of two or more of the three authentication factors: a knowledge factor ("something the user knows"), a possession factor ("something the user has"), and an inherence factor ("something the user is"). (Wikipedia)

Two-factor authentication is not a new concept, having been used throughout history. When a bank customer visits a local automated teller machine (ATM), one authentication factor is the physical ATM card the customer slides into the machine ("something the user has"). The second factor is the PIN the customer enters through the keypad ("something the user knows").

Amazon Web Services: AWS Multi-Factor Authentication

Dropbox: Two-Factor Verification

Facebook: Login approvals

Google Accounts: 2-step verification/Google Authenticator

Microsoft/Hotmail: Microsoft account Security Code

Paypal/eBay: Security Key

Weak authentication offers authentication without relying on trusted third parties.

Authentication with passwords is weak.

Examples

• Passwords
• Challenge Questions
• PIN

And generally speaking, everything that uses one authentication factor.

Techniques that permit entities to provide evidence that they know a particular secret without revealing the secret.

It is a system of verifying user and network server identities on an unprotected network in which the parties must demonstrate knowledge of a "secret" rather than transmit a password.

Typically the verification is done via a trusted third-party authentication service using conventional cryptography.

Strong authentication is not necessarily multifactor authentication. For instance, soliciting multiple answers to challenge questions may be considered strong authentication but, unless the process also retrieves something you have or something you are, it would not be considered multi-factor authentication.

• HTTP Basic
• HTTP Token
• HTTP Digest
• Form Based
• Web Services Security
• OpenID
• OpenID Connect
• Other Authentication Mechanisms

HTTP Digest authentication (RFC 2069, and RFC 2617) encrypts the password using a one-way hash so it's impossible to reverse-engineer even if SSL is not used.

It is an application of MD5 cryptographic hashing with usage of nonce values to prevent replay attacks.

However, it still must be implemented by the browser and can't be designed into a nice UI.

The response value is calculated in three steps:

• The MD5 hash of the combined username, realm and password is calculated. The result is referred to as HA1;
• The MD5 hash of the combined method and URI is calculated, e.g. of GET and /skynet.html. The result is referred to as HA2;
• The MD5 hash of the combined HA1 result, server nonce (nonce), request counter (nc), client nonce (cnonce), quality of protection code (qop) and HA2 result is calculated. The result is the response value provided by the client.

Since the server has the same information as the client, the response can be checked by performing the same calculation.

It refers to the notion of a user being presented with an editable form to fill in and submit in order to log in to some system or service.

As a user, you visit a web page that prompts you for a username and password. If authentication is successful, then under the covers you are granted a unique cookie, which your web browser sends with each subsequent request.

It just looks like you logged in and now the site works, but under the covers it is quite different from Basic.

Credentials are sent in plaintext if you don't rely on SSL to create an encrypted tunnel between the client and server.

Web Services SEcurity (WSSE) also known as WSS or WS-Security is a family of open security specifications for web services, specifically SOAP web services.

Authentication can be done using security tokens.

WS-Security allows you to use any security token you like to use. There are two different options:

• username/password authentication also known as WSSE Username Token;
• binary authentication tokens, also know as WSSE Binary Token in the form of Kerberos tickets or X.509 certificates;

In addition, custom binary security tokens can be applied.

The Username Token algorithm is not SOAP-specific.

The benefits of WSSE Username Token are:

• Username / Password encryption;
• Safe guarding against replay attacks;
• No web server configuration required.

OpenID is a safe, faster, and easier way to log in to web sites.

It is an open standard that allows users to be authenticated by certain co-operating sites (known as Relying Parties or RP) using a third party service.

OpenID was created in the summer of 2005 by an open source community trying to solve a problem that was not easily solved by other existing identity technologies.

Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication.

The OpenID protocol does not rely on a central authority to authenticate a user's identity. OpenID authentication is now used and provided by several large websites.

Providers include Google, Yahoo!, PayPal, BBC, MySpace, Steam, etc.

An end-user is the entity that wants to assert a particular identity.

A Relying Party (RP) is a web site or application that wants to verify the end-user's identifier.

An identity provider, or OpenID Provider (OP) is a service that specializes in registering OpenID URLs or eXtensible Resource Identifiers (XRIs).

OpenID enables an end-user to communicate with a relying party. This communication is done through the exchange of an identifier or OpenID, which is the URL or XRI chosen by the end-user to name the end-user's identity.

An Identity provider provides the OpenID authentication.

eXtensible Identifier Resources are a new form of Internet identifier designed specifically for cross-domain digital identity.

Assuming a user wants to access his account on example.com.

The application example.com (the Relying Party) asks the user for his OpenID.

User enters his OpenID.

Then, example.com redirects the user to his OpenID provider.

User authenticates himself to the OpenID provider.

OpenID provider redirects the user back to example.com.

Finally, example.com allows the user to access his account.

Faster And Easier To Sign Up

An OpenID is a way of identifying yourself no matter which web site you visit. It's like a driver's license for the Internet.

Faster And Easier To Sign In

You only have to remember one username and one password. You might already use one username and one password online, but OpenID lets you do this in a secure way. That's because you only give your password to your OpenID provider, and then your provider tells the websites you're visiting that you are who you say you are.

Closer To A Unified Web Identity

Once you establish yourself as the person who uses a particular OpenID, whenever someone sees your OpenID in use, anywhere on the Internet, they will know that it's you.

Built on-top of OAuth 2.0 protocol (April 2015).

More on this later!

https://openid.net/connect/

Kerberos is a secure method for authenticating a request for a service in a computer network.

Kerberos protocol messages are protected against eavesdropping and replay attacks. It builds on symmetric key cryptography and requires a trusted third party.

Kerberos lets a user request an encrypted ticket from an authentication process that can then be used to request a particular service from a server. The user's password does not have to pass through the network.

When the Kerberos server is down, no one can log in.

Suppose you want to access a server on another computer. You know that this server requires a Kerberos "ticket" before it will honor your request.

To get your ticket, you first request authentication from the Authentication Server (AS).

The Authentication Server creates a session key basing it on your password and a random value that represents the requested service. The session key is a ticket-granting ticket.

You next send your ticket-granting ticket to a Ticket Granting Server (TGS). The TGS returns the ticket that can be sent to the server for the requested service.

The service either rejects the ticket or accepts it and performs the service.

Because the ticket you received from the TGS is time-stamped, it allows you to make additional requests using the same ticket within a certain time period without having to be reauthenticated.

A networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for computers to connect and use a network service. RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. It is described in RFC 2865.

In RADIUS, authentication and authorization are coupled together. If the username is found and the password is correct, the RADIUS server returns an Access-Accept response, including a list of attribute-value pairs that describe the parameters to be used for this session.

If you have an open API, one that exposes data you’d make public on the Internet anyway, consider issuing non-sensitive API keys.

These are easy to manipulate and still give you a way to identify users.

Armed with an API key, you have the option of establishing a quota for your API, or at least monitoring usage by user.

Example

The Yahoo Maps Geocoding API issues API keys so it can track its users and establish a quota, but the data that it returns is not sensitive so it’s not critical to keep the key secret.

If your API is based on a web site, support username/password authentication. That way, users can access your site using the API the same way that they access it using their web browser.

However, if you do this, you may want to avoid session-based authentication, especially if you want people to be able to write API clients in lots of environments.

Example

It is very simple to use curl for instance, to grab some data from the Twitter API because it uses HTTP Basic authentication.

It is a lot more complex if I instead have to call login and extract a session ID from some cookie or header, and then pass that to the real API call I want to make.

Unless your API has only open and non-sensitive data, support SSL, and consider even enforcing it (that is, redirect any API traffic on the non-SSL port to the SSL port).

It makes other authentication schemes more secure, and keeps your user’s private API data from prying eyes.

1. Use nonce tokens (randomly-generated, single-use values) to avoid replay attacks;

2. Rely on request signing to ensure data integrity;

3. Use strong methods to generate random values.

Authorization is the process of giving someone permission to do or have something.

In multi-user computer systems, a system administrator defines for the system which users are allowed to access to the system and what privileges of use.

It is the function of specifying access rights to resources. It is related to access control in information security, and computer security.

Authorization is preceded by Authentication.

Authentication is the mechanism whereby systems may securely identify their users.

Authentication systems provide answers to the following questions:

• Who is the user?
• Is the user really who he/she represents himself to be?

Authorization is the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system.

Authorization systems provide answers to the following questions:

• Is user X authorized to access resource R?
• Is user X authorized to perform operation O?
• Is user X authorized to perform operation O on resource R?

OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. It is an authorization framework that enables a third-party application to obtain limited access to an HTTP service.

For Consumer Developers

OAuth is a simple way to publish and interact with protected data. It is also a safer and more secure way for people to give you access. We've kept it simple to save you time.

For Service Provider Developers

If you are storing protected data on your users' behalf, they should not be spreading their passwords around the web to get access to it. Use OAuth to give your users access to their data while protecting their account credentials.

The idea came from Twitter in November 2006.

A discussion group was created in April 2007, including some Google folks. The OAuth Core 1.0 specification was declared final in December 2007.

Version 1.0 revision A of the OAuth Core protocol was issued to address a session fixation security flaw in June 2009. In the meantime, Twitter released a delegated user authentication solution, called Sign-In With Twitter.

In April 2010, the OAuth 1.0 Protocol was published as an informational RFC 5849. It replaces the OAuth Core 1.0 Revision A specification.

Since August 31, 2010, all third party Twitter applications have been required to use OAuth.

OAuth 2.0, the next evolution of the OAuth protocol, which is not backward compatible with OAuth 1.0, was expected by the end of 2010. However, it was published as RFC 6749 in October 2012.

In comparing OAuth 2.0 with 1.0, Eran Hammer (lead author for the OAuth 2.0 project) points out that it has become "more complex, less interoperable, less useful, more incomplete, and most importantly, less secure".

In July 2012, he resigned his role of lead author, and removed his name from the specification. Some people did the same, and Dick Hardt took over the editor role to publish the RFC.

OAuth 2.0 doesn't support signature, encryption, channel binding, or client verification. It relies completely on SSL for some degree of confidentiality and server authentication. OAuth 2.0 has had numerous security flaws exposed in implementations. The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable.

Must Read: OAuth 2.0 and the Road to Hell.

OAuth lets you authorize one web application, the consumer, to access your data from another web application, the provider.

With OAuth, you still need to log into the provider. It could be a standard username/password login, or it could well be via OpenID.

OpenID gives you one login for multiple web applications. There is no suggestion of two web applications sharing your data.

But...

OpenID Connect has been released last year (April 2015)!
And it is a game-changer.

Server Flow

1. Create an anti-forgery state token
2. Send an authentication request to provider (e.g., Google)
3. Confirm the anti-forgery state token
4. Exchange code for access token and ID token (JSON Web Token)
5. Obtain user information from the ID token
6. Authenticate the user

User — a user who has an account on the Service Provider,and tries to use the Consumer.

Service Provider — service that provides an API that uses OAuth (api.example.org).

Consumer — an application or web service that wants to use functions of the Service Provider through OAuth (your.application.org). This application must be known by the Service Provider, and owns two keys: a Consumer Key and a Consumer Secret Key.

Request Token — a value that a Consumer uses to be authorized by the Service Provider. After completing authorization, it is exchanged for an Access Token.

Access Token — a value that contains a key for the Consumer to access the resource of the Service Provider.

In A Nutshell

1. You ask for a Request Token and specify your callback;
2. You direct the user to the Authorization Screen;
3. You receive a token at the URL you have specified;
4. You ask for an Access Token;
5. You make API calls!

Easy, isn't it?

oauth_callback is the URL of the Consumer that will be redirected after the Service Provider has completed authentication. If the Consumer is not a web application and has no redirection URL, the lower-case Out Of Band (oob) is used as value.

oauth_consumer_key is the Consumer Key provided to you by the Service Provider when you registered your application with it.

oauth_nonce is a random string (Number Once).

oauth_signature is the signature value for the request.

oauth_signature_method is the signature method that you use to sign the request, such as PLAINTEXT, HMAC-SHA1 or RSA-SHA1.

oauth_timestamp is the current timestamp of the request.

oauth_version is always 1.0.

1. Collect all request parameters

All parameters related to OAuth which start with oauth_ except for oauth_signature should be collected.

If parameters are used in the POST body, they should also be collected.

2. Normalize the parameters

Sort all parameters in alphabetical order and apply URL encoding to each key and value (RFC 3986).

List the results of URL encoding as <key>=<value> format and insert & between each pair.

Apply URL encoding to the entire result again.

xAuth is still OAuth.

xAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the Access Token has been retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user.

xAuth access should be restricted to approved applications only.

It is all about requesting an Access Token directly, without using a Request Token. You have to submit x_auth_* parameters in addition to the conventional oauth_* parameters:

• x_auth_username the login credential of the user the client is obtaining a token on behalf of;
• x_auth_password the password credential of the user the client is obtaining a token on behalf of.

OAuth 2.0 defines the following roles of users and applications:

• Resource Owner: the user;
• Resource Server: the API;
• Client Application: the third-party application;
• Authorization Server: often the same as the API server;

Before you can begin the OAuth process, you must first register a new application. You usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile applications.

Redirect URIs

The authorization server will only redirect users to a registered URI, which helps prevent some attacks (in theory...). Any HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with https://. This prevents tokens from being intercepted during the authorization process.

Client ID and Secret

After registering your app, you will receive a client ID and a client secret. The client ID is considered public information, and is used to build login URLs, or included in JavaScript source code on a page. The client secret must be kept confidential. If a deployed application cannot keep the secret confidential, such as JavaScript or native apps, then the secret is not used.

The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.

The authorization grant is given to a client application by the resource owner, in cooperation with the authorization server associated with the resource server.

The OAuth 2.0 specification lists different types of authorization grants. Each type has different security characteristics. The most used authorization Grant Types are:

• Authorization Code
• Implicit
• Password
• Client Credentials

Client account hijacking by connecting attacker's provider account (CSRF attack)

Remediation

Before sending user to the provider generate a random nonce and save it in cookies or session. When user is back make sure state you received is equal one from cookies.

The Most Common OAuth2 Vulnerability

Account hijacking by leaking authorization code

OAuth documentation makes it clear that providers must check the first redirect_uri is equal redirect_uri the client uses to obtain an access_token.

Find a leaking page on the client's domain, insert cross domain image or a link to your website, then use this page as redirect_uri. When your victim will load crafted URL it will send him to leaking_page?code=CODE and victim's user-agent will expose the code in the Referrer header.

Remediation

Flexible redirect_uri is a bad practice. But if you need it, store redirect_uri for every code you issue and verify it on access_token creation.

How I hacked Github again.

Security

OAuth 2.0 replaces signatures with requiring HTTPS for all communications between browsers, clients and the API. It is easier for developers, but it is less secure in its essence. OAuth 1.0 is more secure than OAuth 2.0 as all requests are signed.

User Experience

OAuth 2.0 supports a better user experience for native applications, and supports extending the protocol to provide compatibility with future device requirements. OAuth 1.0 is not good at offering a nice user experience for mobile applications, that is why xAuth has been created.

Scalability

OAuth 2 supports the separation of the roles of obtaining user authorization and handling API calls. Larger providers needing this scalability are free to implement it as such, and smaller providers can use the same server for both roles if they wish.