This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.

Password Schemes

Password scheme means the format in which the password is stored in password databases. The main reason for choosing a scheme other than PLAIN is to prevent someone with access to the password database (such as a hacker) from stealing users' passwords and using them to access other services.

What scheme to use?

You should choose the strongest crypt scheme that's supported by your system. From strongest to weakest:

Note that the above schemes are implemented by the libc's crypt() function. Using them is especially useful when sharing the same passwords with other software, because most of them support using crypt() to verify the password. However, not all libcs (especially older ones) implement all of the above schemes. See below for other password schemes that are implemented by Dovecot internally (instead of libc).

A few articles about why choosing a good password scheme is important:

It's not possible to easily switch from one password scheme to another. The only practical way to do this is to wait until user logs in and change the password during the login. This HOWTO shows one way to do this.

Generating encrypted passwords

You can generate passwords for a particular scheme easily with "doveadm pw" utility. For example:

doveadm pw -s SHA512-CRYPT

Default password schemes

Password databases have a default password scheme:

The password scheme can be overridden for each password by prefixing it with {SCHEME}, for example: {PLAIN}pass.

Non-plaintext authentication mechanisms

See Authentication/Mechanisms for explanation of auth mechanisms. Most installations use only plaintext mechanisms, so you can skip this section unless you know you want to use them.

The problem with non-plaintext auth mechanisms is that the password must be stored either in plaintext, or using a mechanism-specific scheme that's incompatible with all other non-plaintext mechanisms. In addition, the mechanism-specific schemes often offer very little protection. This isn't a limitation of Dovecot, it's a requirement for the algorithms to even work.

For example if you're going to use CRAM-MD5 authentication, the password needs to be stored in either PLAIN or CRAM-MD5 scheme. If you want to allow both CRAM-MD5 and DIGEST-MD5, the password must be stored in plaintext.

In future it's possible that Dovecot could support multiple passwords in different schemes for a single user.

Other supported password schemes

Strong schemes and mechanism-specific schemes are listed above.

MD5 based schemes:

SHA based schemes (also see below for libc's SHA* support):

For some schemes (e.g. PLAIN-MD5, SHA) Dovecot is able to detect if the password hash is base64 or hex encoded, so both can be used. doveadm pw anyway generates the passwords using the encoding mentioned above.


The base64 vs. hex encoding that is mentioned above is simply the default encoding that is used. You can override it for any scheme by adding a ".hex", ".b64" or ".base64" suffix. For example:

This can be especially useful with plaintext passwords to encode characters that would otherwise be illegal. For example in passwd-file you couldn't use a ":" character in the password without encoding it to base64 or hex. For example: {PLAIN}{\}:!" is the same as {PLAIN.b64}e1x9OiEiCg==.

You can also specify the encoding with doveadm pw. For example: doveadm pw -s plain.b64


For the SHA512-CRYPT, SHA256-CRYPT and MD5-CRYPT schemes, the salt is stored before the hash, e.g.: $6$salt$hash. For the BLF-CRYPT scheme, bcrypt stores the salt as part of the hash.

For most of the other salted password schemes (SMD5, SSHA*) the salt is stored after the password hash and its length can vary. When hashing the password, append the salt after the plaintext password, e.g.: SSHA256(pass, salt) = SHA256(pass + salt) + salt.

For example with SSHA256 you know that the hash itself is 32 bytes (256 bits/8 bits per byte). Everything after that 32 bytes is the salt. For example if you have a password:


After base64 decoding it you'll see that its length is 36 bytes, so the first 32 bytes are the hash and the following 4 bytes are the salt:

Other common hash sizes are:

The web management gui VBoxAdm has some code dealing with creation and verification of salted hashes in Perl. However not all password schemes provided by dovecotpw are supported. Have a look at the module VBoxAdm::DovecotPW for more details.

Authentication/PasswordSchemes (last edited 2015-07-01 08:02:12 by ip51cf5913)