Cuando intente conectar a un servidor MySQL, el servidor aceptará o rechazará la conexión basándose en su identidad y si usted puede identificar su identidad proporcionando la clave correcta. Si no es así, el servidor le denegará el acceso completamente. En caso contrario, el servidor acepta la conexión, y entra en el Estado 2, y espera peticiones.

Su identidad se basa en dos elementos de información:

La comprobación de la identidad se realiza utilizando las tres columnas de la tabla user (Host, User, y Password). El servidor sólo acepta la conexión si las columnas Host y User de alguna de las tablas user es coincidente con el nombre de máquina y usuario del cliente, y además el cliente proporciona la clave especificada en ese registro.

Los valores de Host en la tabla user pueden ser especificados de las siguientes maneras:

Debido a que puede usar comodines en los valores IP de la columna Host (por ejemplo, '144.155.166.%' para conseguir cualquier IP en una subred), alguien podría intentar explotar esta capacidad poniéndole a su cliente el nombre 144.155.166.cualquierhost.com. Para evitar estos intentos, MySQL no permite que los comodines sean utilizados para los nombres de cliente que empiezan con dígitos y un punto. Así que si tiene un cliente con nombre similar a 1.2.cualquierhost.com, su nombre nunca concordará con la columna Host de las tablas grant. Un comodín de IP solo puede concordar con números IP, no nombres de cliente.

En la columna User, los caracteres comodín no están permitidos, pero puede especificar un valor en blanco, que será válido para cualquier nombre. Si el registro de la tabla user que concuerda con una conexión entrante tiene un valor vacio, el usuario es considerado anónimo, sin nombre de usuario, no un usuario con el nombre que el cliente especificó realmente. Esto significa que el nombre de usuario vacío es utilizado para todas las comprobaciones de acceso posteriores durante la duración de la conexión (es decir, durante el Estado 2).

La columna Password puede estar vacía. Esto no es un comodín que permite que cualquier clave sea permitida. Significa que el usuario debe conectarse sin especificar una clave.

Los valores que no están vacíos de Password en la tabla user representan claves cifradas. MySQL no almacena las claves en forma de texto llano para que cualquiera pueda verlo. En vez de esto, la clave suministrada por un usuario que se está intentando conetar es cifrada (utilizando la función PASSWORD()). La clave cifrada se utiliza entonces durante el proceso de conexión en el momento de comprobar si es correcta. (Esto se realiza sin que la clave cifrada viaje nunca sobre la conexión.) Desde el punto de vista de MySQL, la clave cifrada es la clave REAL, así que no debería darse acceso a ella a nadie. En concreto, no de acceso de lectura a las tablas de la base de datos mysql a usuarios no-administrativos.

MySQL 5.0 utiliza el método de autenticación más fuerte (implementado primeramente en MySQL 4.1) y que tiene una mejor protección de la clave durante el proceso de conexión que versiones previas. Es seguro aún cuando los paquetes TCP/IP fuesen interceptados o la base de datos mysql capturada. El cifrado de claves es comentado en mayor profundida en Sección 5.6.9, “Hashing de contraseñas en MySQL 4.1”.

Los siguientes ejemplos nos enseñan como se aplicarían a las conexiones entrantes diferentes combinaciones de los valores de las columnas Host y User de la tabla user.

Es posible que el nobre del cliente y del usuario de una conexión entrante concuerde con más de un registro en la tabla user. El conjunto de ejemplos precedentes demuestra esto: Algunas de las entradas mostradas concuerdan con una conexión de fred desde thomas.loc.gov.

Cuando hay la posibilidad de múltiples concordancias, el servidor debe determinar cual de ellas utilizar. El problema se resuelve de la siguiente manera:

Para ver como esto ocurre, supongamos que la tabla user es como esta:

+-----------+----------+-
| Host      | User     | …
+-----------+----------+-
| %         | root     | …
| %         | jeffrey  | …
| localhost | root     | …
| localhost |          | …
+-----------+----------+-

Cuando el servidor lee la tabla, ordena las entradas con los valores de Host más específicos primero. Los nombres de cliente y números de IP son los más específicos. El comodín '%' significa ``cualquier cliente'' y es menos específico. Registros con el mismo valor de Host se ordenan con el valor de User más específico (un valor de User en blanco significa ``cualquier usuario'' y es menos específico). En la tabla user recién mostrada, el resultado después de ordenar sería el siguiente:

+-----------+----------+-
| Host      | User     | …
+-----------+----------+-
| localhost | root     | … ...
| localhost |          | … ...
| %         | jeffrey  | … ...
| %         | root     | … ...
+-----------+----------+-

Cuando un cliente intenta conectar, el servidor mira los registros ordenados y utiliza la primera concordancia. Para una conexión desde localhost por jeffrey, dos de las entradas de la tabla concuerdan: la primera con los valores 'localhost' y '' de Host y User respectivamente, y el registro con los valores '%' y 'jeffrey'. El registro con valor 'localhost' aparece primero en la tabla ordenada, así que es el que el servidor utiliza.

Aquí hay otro ejemplo. Supongamos que la tabla user tiene el siguiente aspecto:

+----------------+----------+-
| Host           | User     | …
+----------------+----------+-
| %              | jeffrey  | …
| thomas.loc.gov |          | …
+----------------+----------+-

La tabla ordenada sería:

+----------------+----------+-
| Host           | User     | …
+----------------+----------+-
| thomas.loc.gov |          | …
| %              | jeffrey  | …
+----------------+----------+-

Una conexión de jeffrey desde thomas.loc.gov concuerda con el primer registro, mientras que una conexión de jeffrey desde whitehouse.gov concuerda con el segundo.

Es una confusión común el pensar que, para un nombre de usuario dado, todos los registros que nombran explícitamente con a ese usuario son utilizadas primero cuando el servidor intenta encontrar una concordancia para una conexión. Esto es sencillamente falso. El ejemplo anterior ilustra esto, donde una conexión de jeffrey desde thomas.loc.gov no concuerda primero con el registro que contiene 'jeffrey' como valor en la columna User, sino que ha concordado con el registro que no contiene nombre de usuario. Como resultado, jeffrey es tratado como un usuario anónimo aunque ha especificado un nombre de usuario al conectarse.

Si puede conectar al servidor, pero sus privilegios no son los que espera, probablemente está siendo identificado como algún otro usuario. Para averiguar qué cuenta de usuario utilizó el servidor para identificarle, use la función CURRENT_USER(). Devuelve un valor en formato user_name@host_name que indica los valores de User y Host del registro concordante en la tabla user. Suponga que jeffrey conecta y ejecuta la siguiente sentencia:

mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost     |
+----------------+

El resultado mostrado indica que el registro que concuerda en la tabla user tiene un valor vacío en la columna User. En otras palabras, el servidor trata a jeffrey como a un usuario anónimo.

Otra cosa que puede hacer para localizar problemas de autentificación es imprimir por pantalla la tabla user y ordenarla a mano para ver donde está la primera concordancia. Consulte Sección 12.9.3, “Funciones de información”.