IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Introducció

L'autenticació basada en token és un tipus d'autenticació utilitzada en Criptografia on el repte que han de superar les entitats (usuaris/aplicacions) per tal de ser autenticades és proporcionar un token. El token és un secret compartit només entre l'entitat autenticada i el servei d'autenticació i per tant s'ha de mantenir de confidencial.

Els tokens també són coneguts com (aka):

Un Token ha de complir amb les següents condicions:

  • Ha de ser únic, és a dir, no poden haver col·lisions ni repeticions de claus.
  • No ha de ser predictible i no ha de tenir cap relació amb l'entitat associada (usuari, servei, etc). Per tant s'han de generar de forma el més aleatòria possible i han de tenir una bona entropia.

Avantatges e inconvenients

Avantatges

  • Les avantatges se solen comparar respecte a la alternativa típica: usuari/paraula de pas
  • Millor Entropia: Utilitzar Username/Password és menys segur des de la perspectiva de la entropia ja que se solen reutilitzar entre múltiples serveis/llocs web i solen ser mols més simples els passwords que no pas les API keys (sistemes típics de API key utilitzant com a mínim sistemes de 40 caràcters o més, difícilment les paraules de pas utilitzen tants caràcters)
  • Millor resistència a atacs: El augment de la entropia les fa menys vulnerables a atacs. Per exemple per força bruta la quantitat de combinacions a provar augmenta exponencialment, els atacs de diccionaris i per Rainbow tables no tenen sentit, etc). De fet les API keys no són susceptibles a ser atacades utilitzant els típics atacs a Paraules de pas
  • Les paraules de pas són més fàcils d'interceptar?
  • No es veuen afectades per canvis en la paraula de pas de la entitat associada ni per Password Resets. Si l'usuari es canvia la paraula de pas s'hauria de canviar la paraula de pas a totes les aplicacions client. De fet la pràctica habitual es crear una API client per a cada client/aplicació possible.
  • Independència: al ser les API keys independents de les credencials principals de l'usuari es poden revocar i crear a desig de l'usuari o del sistema. Això facilita per exemple el canvi de API keys cada sis mesos o la revocació d'una clau si es creu que ha sigut compromesa.
  • Facilita la compartició: es pot compartir una API key amb col·laborador sense necessitat de compartir les vostres credencials personals.
  • Velocitat: Els sistemes basats en usuari i paraula de pas se sol provocar que durin un cert temps (per exemple aprox un segon ). Este temps és inapreciable per als usauris finals i permet però que els atacs per força bruta siguin impossibles de realitzar. Com les API keys utilitzar mecanismes d'autenticació segurs o sistemes digest-based authentication no tenim perque crear ua restricció artificial de temps mínims i per tant podem millorar la velocitat de les comunicacions entre sistemes (system-to-system communication).

Inconvenients:

  • No estan (expressament) pensades per ser recordades a diferència precisament de les paraules de pas. Per tant s'han d'emmagatzemar en un lloc segur. Per tant són molt vulnerables a tots aquells tipus d'atacs que permetin l'accés al sistema d'emmagatzemament de la clau.

Recursos:


Creació de tokens

PHP

Se solen utilitzar funcions criptogràfiques de hash, valors aleatoris i funcions com uniqid per a crear API keys. Exemple amb PHP:

Exemple 1. Hash md5/sha1:

 private function generateApiKey() {
        return md5(uniqid(rand(), true));
    }

Exemple 2: Mida variable:


 private function _generate_key()
 	{
 		//$this->load->helper('security');
 		
 		do
 		{
 			$salt = do_hash(time().mt_rand());
 			$new_key = substr($salt, 0, config_item('rest_key_length'));
 		}
 
 		// Already in the DB? Fail. Try again
 		while (self::_key_exists($new_key));
 
 		return $new_key;
 	}

Recursos:

Laravel

Laravel passport proporciona un mètode anomenat createToken a la classe User que permet crear Personal access Tokens https://laravel.com/docs/5.3/passport#managing-personal-access-tokens

Tenim el helper str_random per crear cadenes de text aleatories:

$code = str_random(10); //would produce a secret code of 10 chars.

I a més podem utilitzar les funcionalitats de hash de Laravel per crear un hash a partir d'aquestes dades aleatòries:

Vegeu Laravel Hash https://laravel.com/docs/5.3/hashing

Code Igniter

Cal tenir en compte que hi ha dos Helpers que poden ser utils a Code Igniter:

random_string('sha1')

La funció per a crear random strings és:

if ( ! function_exists('random_string'))
{
	function = 'alnum', $len = 8)
	{
		switch($type)
		{
			case 'basic'	: return mt_rand();
				break;
			case 'alnum'	:
			case 'numeric'	:
			case 'nozero'	:
			case 'alpha'	:

					switch ($type)
					{
						case 'alpha'	:	$pool = ' abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
							break;
						case 'alnum'	:	$pool = ' 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
							break;
						case 'numeric'	:	$pool = '0123456789';
							break;
						case 'nozero'	:	$pool = '123456789';
							break;
					}

					$str = ;
					for ($i=0; $i < $len; $i++)
					{
						$str .= substr($pool, mt_rand(0, strlen($pool) -1), 1);
					}
					return $str;
				break;
			case 'unique'	:
			case 'md5'		:

						return md5(uniqid(mt_rand()));
				break;
			case 'encrypt'	:
			case 'sha1'	:

						$CI =& get_instance();
						$CI->load->helper('security');

						return do_hash(uniqid(mt_rand(), TRUE), 'sha1');
				break;
		}
	}
}

Utilització. Request header Authorization

Les API key es recomanable posar-les a la capçalera HTTP utilitzant el Request Header Authorization en comptes de passar-la per la URL ja sigui per mètode GET o POST

Authorization: bf45c093e542f057caee68c47787e7d6

També s'utilitza X-API-KEY en algunes API. Vegeu Code Igniter REST WEB API

$ curl -X POST -H "X-API-KEY: some_key_here" http://example.com/books

Un altre possiblitat (per exemple utilitzada a Laravel passport/Oauth) és utilitzar Bearer:

Authorization: Bearer ACCES_TOKEN_HERE

Amb apps PHP també s'utilitza (per exemple Laravel):

PHP_AUTH_PW: token

HTTP Response

S'utilitza el codi de resposta 401 per indicar un accés no autoritzat o per reclamar que cal autoritzar-se abans d'accedir al recurs.

Emmagatzemament de tokens

Se sol guardar la API key de l'usuari a la base de dades del servidor. El mode més simple (si hi ha una sola clau) és afegir un camp més a la taula users. Si hi ha múltiples claus per usuari cal crear una taula nova per a fer una relació 1 a n

En els clients hi ha múltiples opcions:

  • Hardcoded: no és l'opció més recomanable. La API key es guarda al codi font de l'aplicació client
  • Fitxers de configuració: Millor opció. Permet reconfigurar/canviar la API key sense necessitat de recompilar. També permet compartir el codi font sense necessitat de compartir la API Key. També facilita la seguretat al poder determinar els permisos del fitxer de configuració
  • Base de dades client
  • Altres: variables de sessió, Android Shared Preferences
  • HTML 5 Local Storage o Session Storage
  • Encrypted Cookies: opció recomanada

Authentication Tools

Recursos:

Authentication protocols

This means it is a strict set of instructions for the issuing and validating of signed access tokens. The tokens contain claims that are used by an app to limit access to a user.

JWT Json Web Tokens

Vegeu Json Web Tokens

Altres. EAP, CHAP, Ldap

Vegeu Protocols_d'autenticació#Esquemes_d.27autenticaci.C3.B3 i Ldap

Authentication frameworks

OAuth2 és un exemple de framework d'autenticació (aka Authentication framework) és a dir un guia detallada de com permetre a usuaris i aplicacions l'accés a recursos protegits


Oauth

Vegeu Oauth

Tipus de Tokens

Authorization tokens

Són tokens utilitzats per proporcionar a una aplicació client de permís (autorització) per demanar un access token en nom d'un usuari el qual ha autoritzat aquesta acció. S'utilitzen en protocols com Oauth en la fase d'autorització.

Amb Oauth només s'utilitzen al grant:

Access token

Són els més comuns i són tokens que proporcionen accés a un recurs privat. Els access tokens se solen obtenir prèvia autorització del propietari del recurs/resource-owner. Tots els tipus de grants de OAuth acaben retornant un access token en canvi no tots utilitzen authorization tokens

Per seguretat és recomanable utilitzar JWT/Json Web Tokens o similar per a proporcionar els tokens ja que els tokens JWT estan xifrats i a més són stateless. Molts sistemes com Laravel Passport combinen l'ús de Oauth i JWT

Refresh Token

Vegeu Refresh Token

Json web tokens

Vegeu JWT

Comparision

Llenguatges de programació

PHP

Laravel

Vegeu Laravel Token-Based Authentication

Laravel 5.3. Laravel Passport]]

Vegeu Laravel Passport


Vegeu també

Enllaços externs