Syntax\n------\n\nALTER USER [IF EXISTS] \n user_specification [,user_specification] ...\n  [REQUIRE {NONE | tls_option [[AND] tls_option] ...}]\n  [WITH resource_option [resource_option] ...]\n  [lock_option] [password_option] \n\nuser_specification:\n  username [authentication_option]\n\nauthentication_option:\n  IDENTIFIED BY 'password' \n  | IDENTIFIED BY PASSWORD 'password_hash'\n  | IDENTIFIED {VIA|WITH} authentication_rule [OR authentication_rule] ... \n \nauthentication_rule:\n  authentication_plugin\n  | authentication_plugin {USING|AS} 'authentication_string'\n  | authentication_plugin {USING|AS} PASSWORD('password')\n\ntls_option\n  SSL \n  | X509\n  | CIPHER 'cipher'\n  | ISSUER 'issuer'\n  | SUBJECT 'subject'\n\nresource_option\n  MAX_QUERIES_PER_HOUR COUNT\n  | MAX_UPDATES_PER_HOUR COUNT\n  | MAX_CONNECTIONS_PER_HOUR COUNT\n  | MAX_USER_CONNECTIONS COUNT\n  | MAX_STATEMENT_TIME TIME\n\npassword_option:\n  PASSWORD EXPIRE\n  | PASSWORD EXPIRE DEFAULT\n  | PASSWORD EXPIRE NEVER\n  | PASSWORD EXPIRE INTERVAL N DAY\n\nlock_option:\n    ACCOUNT LOCK\n  | ACCOUNT UNLOCK\n}\n\nDescription\n-----------\n\nThe ALTER USER statement modifies existing MariaDB accounts. To use it, you must have the global CREATE USER privilege or the UPDATE privilege for the mysql database. The global READ_ONLY ADMIN privilege is also required if the read_only system variable is enabled.\n\nIf any of the specified user accounts do not yet exist, an error results. If an error occurs, ALTER USER will still modify the accounts that do not result in an error. Only one error is produced for all users which have not been modified.\n\nFor renaming an existing account (user name and/or host), see RENAME USER.\n\nIF EXISTS\n\nWhen the IF EXISTS clause is used, MariaDB will return a warning instead of an error for each specified user that does not exist.\n\nAccount Names\n\nFor ALTER USER statements, account names are specified as the username argument in the same way as they are for CREATE USER statements. See account names from the CREATE USER page for details on how account names are specified.\n\nCURRENT_USER or CURRENT_USER() can also be used to alter the account logged into the current session. For example, to change the current user's password to mariadb:\n\n``sql\nALTER USER CURRENT_USER() IDENTIFIED BY 'mariadb';\n`\n\nAuthentication Options\n\nFrom MariaDB 10.4, it is possible to use more than one authentication plugin for each user account. For example, this can be useful to slowly migrate users to the more secure ed25519 authentication plugin over time, while allowing the old mysql_native_password authentication plugin as an alternative for the transitional period. See Authentication from MariaDB 10.4 for more.\n\nWhen running ALTER USER, not specifying an authentication option in the IDENTIFIED VIA clause will remove that authentication method. (However this was not the case before MariaDB 10.4.13, see MDEV-21928)\n\nFor example, a user is created with the ability to authenticate via both a password and unix_socket:\n\n`sql\nCREATE USER 'bob'@'localhost' \n  IDENTIFIED VIA mysql_native_password USING PASSWORD('pwd') \n  OR unix_socket;\n\nSHOW CREATE USER 'bob'@'localhost'\\G\n`\n\n`\n************************ 1. row ***********************\nCREATE USER for bob@localhost: CREATE USER bob@localhost \n  IDENTIFIED VIA mysql_native_password \n  USING '975B2CD4FF9AE554FE8AD33168FBFC326D2021DD' \n  OR unix_socket\n`\n\nIf the user's password is updated, but unix_socket authentication is not specified in the IDENTIFIED VIA clause, unix_socket authentication will no longer be permitted.\n\n`sql\nALTER USER 'bob'@'localhost' IDENTIFIED VIA mysql_native_password \n  USING PASSWORD('pwd2');\n\nSHOW CREATE USER 'bob'@'localhost'\\G\n`\n\n`\n************************ 1. row ***********************\nCREATE USER for bob@localhost: CREATE USER bob@localhost \n  IDENTIFIED BY PASSWORD '38366FDA01695B6A5A9DD4E428D9FB8F7EB75512'\n`\n\nIDENTIFIED BY 'password'\n\nThe optional IDENTIFIED BY clause can be used to provide an account with a password. The password should be specified in plain text. It will be hashed by the PASSWORD function prior to being stored in the mysql.user view.\n\nFor example, if our password is mariadb, then we can set the account's password with:\n\n`sql\nALTER USER foo2@test IDENTIFIED BY 'mariadb';\n`\n\nIf you do not specify a password with the IDENTIFIED BY clause, the user\\\nwill be able to connect without a password. A blank password is not a wildcard\\\nto match any password. The user must connect without providing a password if no\\\npassword is set.\n\nThe only authentication plugins that this clause supports are mysql_native_password and mysql_old_password.\n\nIDENTIFIED BY PASSWORD 'password_hash'\n\nThe optional IDENTIFIED BY PASSWORD clause can be used to provide an account with a password that has already been hashed. The password should be specified as a hash that was provided by the PASSWORD#function. It will be stored in the mysql.user view as-is.\n\nFor example, if our password is mariadb, then we can find the hash with:\n\n`sql\nSELECT PASSWORD('mariadb');\n`\n\n`\n+-------------------------------------------+\n| PASSWORD('mariadb')                       |\n+-------------------------------------------+\n| 54958E764CE10E50764C2EECBB71D01F08549980 |\n+-------------------------------------------+\n`\n\nAnd then we can set an account's password with the hash:\n\n`sql\nALTER USER foo2@test \n  IDENTIFIED BY PASSWORD '54958E764CE10E50764C2EECBB71D01F08549980';\n`\n\nIf you do not specify a password with the IDENTIFIED BY clause, the user\\\nwill be able to connect without a password. A blank password is not a wildcard\\\nto match any password. The user must connect without providing a password if no password is set.\n\nThe only authentication plugins that this clause supports are mysql_native_password and mysql_old_password.\n\nIDENTIFIED {VIA|WITH} authentication_plugin\n\nThe optional IDENTIFIED VIA authentication_plugin allows you to specify that the account should be authenticated by a specific authentication plugin. The plugin name must be an active authentication plugin as per SHOW PLUGINS. If it doesn't show up in that output, then you will need to install it with INSTALL PLUGIN or INSTALL SONAME.\n\nFor example, this could be used with the PAM authentication plugin:\n\n`sql\nALTER USER foo2@test IDENTIFIED VIA pam;\n`\n\nSome authentication plugins allow additional arguments to be specified after a USING or AS keyword. For example, the PAM authentication plugin accepts a service name:\n\n`sql\nALTER USER foo2@test IDENTIFIED VIA pam USING 'mariadb';\n`\n\nThe exact meaning of the additional argument would depend on the specific authentication plugin.\n\nThe USING or AS keyword can also be used to provide a plain-text password to a plugin if it's provided as an argument to the PASSWORD() function. This is only valid for authentication plugins that have implemented a hook for the PASSWORD() function. For example, the ed25519 authentication plugin supports this:\n\n`sql\nALTER USER safe@'%' IDENTIFIED VIA ed25519 USING PASSWORD('secret');\n`\n\nThe USING or AS keyword cannot be used to provide a plain-text password to a plugin if it's provided as an argument to the PASSWORD() function.\n\nTLS Options\n\nBy default, MariaDB transmits data between the server and clients without encrypting it. This is generally acceptable when the server and client run on the same host or in networks where security is guaranteed through other means. However, in cases where the server and client exist on separate networks or they are in a high-risk network, the lack of encryption does introduce security concerns as a malicious actor could potentially eavesdrop on the traffic as it is sent over the network between them.\n\nTo mitigate this concern, MariaDB allows you to encrypt data in transit between the server and clients using the Transport Layer Security (TLS) protocol. TLS was formerly known as Secure Socket Layer (SSL), but strictly speaking the SSL protocol is a predecessor to TLS and, that version of the protocol is now considered insecure. The documentation still uses the term SSL often and for compatibility reasons TLS-related server system and status variables still use the prefix ssl_, but internally, MariaDB only supports its secure successors.\n\nSee Secure Connections Overview for more information about how to determine whether your MariaDB server has TLS support.\n\nYou can set certain TLS-related restrictions for specific user accounts. For instance, you might use this with user accounts that require access to sensitive data while sending it across networks that you do not control. These restrictions can be enabled for a user account with the CREATE USER, ALTER USER, or GRANT statements. The following options are available:\n\n| Option                    | Description                                                                                                                                                                                                                                                                                         |\n| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| REQUIRE NONE              | TLS is not required for this account, but can still be used.                                                                                                                                                                                                                                        |\n| REQUIRE SSL               | The account must use TLS, but no valid X509 certificate is required. This option cannot be combined with other TLS options.                                                                                                                                                                         |\n| REQUIRE X509              | The account must use TLS and must have a valid X509 certificate. This option implies REQUIRE SSL. This option cannot be combined with other TLS options.                                                                                                                                            |\n| REQUIRE ISSUER 'issuer'   | The account must use TLS and must have a valid X509 certificate. Also, the Certificate Authority must be the one specified via the string issuer. This option implies REQUIRE X509. This option can be combined with the SUBJECT, and CIPHER options in any order.                                  |\n| REQUIRE SUBJECT 'subject' | The account must use TLS and must have a valid X509 certificate. Also, the certificate's Subject must be the one specified via the string subject. This option implies REQUIRE X509. This option can be combined with the ISSUER, and CIPHER options in any order.                                  |\n| REQUIRE CIPHER 'cipher'   | The account must use TLS, but no valid X509 certificate is required. Also, the encryption used for the connection must use a specific cipher method specified in the string cipher. This option implies REQUIRE SSL. This option can be combined with the ISSUER, and SUBJECT options in any order. |\n\nThe REQUIRE keyword must be used only once for all specified options, and the AND keyword can be used to separate individual options, but it is not required.\n\nFor example, you can alter a user account to require these TLS options with the following:\n\n`sql\nALTER USER 'alice'@'%'\n REQUIRE SUBJECT '/CN=alice/O=My Dom, Inc./C=US/ST=Oregon/L=Portland' AND\n ISSUER '/C=FI/ST=Somewhere/L=City/ O=Some Company/CN=Peter Parker/emailAddress=p.parker@marvel.com'\n AND CIPHER 'SHA-DES-CBC3-EDH-RSA';\n`\n\nIf any of these options are set for a specific user account, then any client who tries to connect with that user account will have to be configured to connect with TLS.\n\nSee Securing Connections for Client and Server for information on how to enable TLS on the client and server.\n\nResource Limit Options\n\nIt is possible to set per-account limits for certain server resources. The following table shows the values that can be set per account:\n\n| Limit Type                  | Description                                                                                                                                                                                                                     |\n| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| MAX_QUERIES_PER_HOUR     | Number of statements that the account can issue per hour (including updates)                                                                                                                                                    |\n| MAX_UPDATES_PER_HOUR     | Number of updates (not queries) that the account can issue per hour                                                                                                                                                             |\n| MAX_CONNECTIONS_PER_HOUR | Number of connections that the account can start per hour                                                                                                                                                                       |\n| MAX_USER_CONNECTIONS      | Number of simultaneous connections that can be accepted from the same account; if it is 0, max_connections will be used instead; if max_connections is 0, there is no limit for this account's simultaneous connections.      |\n| MAX_STATEMENT_TIME        | Timeout, in seconds, for statements executed by the user. See also Aborting Statements that Exceed a Certain Time to Execute. |\n\nIf any of these limits are set to 0, then there is no limit for that resource for that user.\n\nHere is an example showing how to set an account's resource limits:\n\n`sql\nALTER USER 'someone'@'localhost' WITH\n    MAX_USER_CONNECTIONS 10\n    MAX_QUERIES_PER_HOUR 200;\n`\n\nThe resources are tracked per account, which means 'user'@'server'; not per user name or per connection.\n\nThe count can be reset for all users using FLUSH USER_RESOURCES, FLUSH PRIVILEGES or mysqladmin reload.\n\nPer account resource limits are stored in the user table, in the mysql database. Columns used for resources limits are named max_questions, max_updates, max_connections (for MAX_CONNECTIONS_PER_HOUR), and max_user_connections (for MAX_USER_CONNECTIONS).\n\nPassword Expiry\n\nBesides automatic password expiry, as determined by default_password_lifetime, password expiry times can be set on an individual user basis, overriding the global setting, for example:\n\n`sql\nALTER USER 'monty'@'localhost' PASSWORD EXPIRE INTERVAL 120 DAY;\nALTER USER 'monty'@'localhost' PASSWORD EXPIRE NEVER;\nALTER USER 'monty'\n\n[Truncated — full content at mariadb.com/docs]