Access Control, Stage 1: Connection Verification •Whether your account is locked or unlocked. The server checks credentials first, then account locking state. A failure at either step causes the server to deny access to you completely. Otherwise, the server accepts the connection, and then enters Stage 2 and waits for requests. The server performs identity and credentials checking using columns in the  user  table, accepting the connection only if these conditions are satisfied: •The client host name and user name match the  Host  and  User  columns in some  user  table row. For the rules governing permissible  Host  and  User  values, see Section 6.2.4, “Specifying Account Names” . •The client supplies the credentials specified in the row (for example, a password), as indicated by the authentication_string  column. Credentials are interpreted using the authentication plugin named in the  plugin  column. •The row indicates that the account is unlocked. Locking state is recorded in the  account_locked column, which must have a value of  ’N’ . Account locking can be set or changed with the  CREATE USER or  ALTER USER  statement. Your identity is based on two pieces of information: •Your MySQL user name. •The client host from which you connect. If the  User  column value is nonblank, the user name in an incoming connection must match exactly. If the User  value is blank, it matches any user name. If the  user  table row that matches an incoming connection has a blank user name, the user is considered to be an anonymous user with no name, not a user with the name that the client actually specified. This means that a blank user name is used for all further access checking for the duration of the connection (that is, during Stage 2). The  authentication_string  column can be blank. This is not a wildcard and does not mean that any password matches. It means that the user must connect without specifying a password. The authentication method implemented by the plugin that authenticates the client may or may not use the password in the authentication_string  column. In this case, it is possible that an external password is also used to authenticate to the MySQL server. Nonblank password values stored in the  authentication_string  column of the  user  table are encrypted. MySQL does not store passwords as cleartext for anyone to see. Rather, the password supplied by a user who is attempting to connect is encrypted (using the password hashing method implemented by the account authentication plugin). The encrypted password then is used during the connection process when checking whether the password is correct. This is done without the encrypted password ever traveling over the connection. See Section 6.2.1, “Account User Names and Passwords” . From MySQL’s point of view, the encrypted password is the  real  password, so you should never give anyone access to it. In particular,  do not give nonadministrative users read access to tables in the  mysql system database . The following table shows how various combinations of  User  and  Host  values in the  user  table apply to incoming connections. User  Value Host  Value Permissible Connections ’fred’ ’h1.example.net’ fred , connecting from h1.example.net 1217