ed 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/mysql.global_priv_table table as-is.

For example, if our password is mariadb, then we can find the hash with:

SELECT PASSWORD('mariadb');
+-------------------------------------------+
| PASSWORD('mariadb')                       |
+-------------------------------------------+
| *54958E764CE10E50764C2EECBB71D01F08549980 |
+-------------------------------------------+
1 row in set (0.00 sec)

And then we can create a user with the hash:

CREATE USER foo2@test IDENTIFIED BY PASSWORD
'*54958E764CE10E50764C2EECBB71D01F08549980';

If you do not specify a password with the IDENTIFIED BY clause, the user will
be able to connect without a password. A blank password is not a wildcard to
match any password. The user must connect without providing a password if no
password is set.

The only authentication plugins that this clause supports are
mysql_native_password and mysql_old_password.

IDENTIFIED {VIA|WITH} authentication_plugin
-------------------------------------------

The 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.

VIA and WITH are synonyms.

For example, this could be used with the PAM authentication plugin:

CREATE USER foo2@test IDENTIFIED VIA pam;

Some authentication plugins allow additional arguments to be specified after a
USING or AS keyword. For example, the PAM authentication plugin accepts a
service name:

CREATE USER foo2@test IDENTIFIED VIA pam USING 'mariadb';

The exact meaning of the additional argument would depend on the specific
authentication plugin.

MariaDB starting with 10.4.0
----------------------------
The 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:

CREATE USER safe@'%' IDENTIFIED VIA ed25519 USING PASSWORD('secret');

MariaDB starting with 10.4.3
----------------------------
One can specify many authentication plugins, they all work as alternatives
ways of authenticating a user:

CREATE USER safe@'%' IDENTIFIED VIA ed25519 USING PASSWORD('secret') OR
unix_socket;

By default, when you create a user without specifying an authentication
plugin, MariaDB uses the mysql_native_password plugin.

TLS Options
-----------

By 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.

To 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.

See Secure Connections Overview for more information about how to determine
whether your MariaDB server has TLS support.

You can set certain TLS-related restrictions for specific user accounts. For
instance, you mighɦœP