The plain text password manager never claims to implement the scheme,
because this would open a security hole, where a hash from a different
scheme could be used as-is as a plain-text password. Authentication code
that needs to support plain-text passwords need to explicitly check for
plain-text password matches after all other options have been tested for:

SSHA is basically SHA1-encoding which also incorporates a salt
into the encoded string. This way, stored passwords are more
robust against dictionary attacks of attackers that could get
access to lists of encoded passwords.

SSHA is regularly used in LDAP databases and we should be
compatible with passwords used there.

SMD5 is basically SMD5-encoding which also incorporates a salt
into the encoded string. This way, stored passwords are more
robust against dictionary attacks of attackers that could get
access to lists of encoded passwords:

This password manager is compatible with other RFC 2307 MD5
implementations. For example the output of the slappasswd command for
a MD5 hashing of secret is {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==,
and our implementation returns the same hash:

A previous version of this manager also created a cosmetic salt, added
to the start of the hash, but otherwise not used in creating the hash
itself. Moreover, it generated the MD5 hash as a hex digest, not a base64
encoded value and did not include the {MD5} prefix. Such hashed values are
still supported too:

This password manager is compatible with other RFC 2307 SHA
implementations. For example the output of the slappasswd command for
a SHA hashing of secret is {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=,
and our implementation returns the same hash:

A previous version of this manager also created a cosmetic salt, added
to the start of the hash, but otherwise not used in creating the hash
itself. Moreover, it generated the SHA hash as a hex digest, not a base64
encoded value and did not include the {SHA} prefix. Such hashed values are
still supported too:

This manager converts a plain text password into a byte array.
The password and salt values (randomly generated when the password
is encoded) are combined and repeatedly hashed rounds times. The
repeated hashing is designed to thwart discovery of the key via
password guessing attacks. The higher the number of rounds, the
slower each attempt will be.

Compared to the BCRYPTPasswordManager, this has the
advantage of allowing tunable rounds, so as computing devices get
more powerful making brute force attacks faster, the difficulty
level can be raised (for newly encoded passwords).

The following password managers are deprecated, because they produce
unacceptably-weak password hashes. They are only included to allow
apps which previously used them to migrate smoothly to a supported
implementation.

Note that this object fails to return bytes from the encodePassword
function on Python 3:

>>> isinstance(encoded,str)True

Unfortunately, crypt only looks at the first 8 characters, so matching
against an 8 character password plus suffix always matches. Our test
password (including utf-8 encoding) is exactly 8 characters long, and
thus affixing ‘wrong’ to it tests as a correct password:

>>> manager.checkPassword(encoded,password+u"wrong")True

Using a completely different password is rejected as expected:

>>> manager.checkPassword(encoded,'completely wrong')False

Using the openssl passwd command-line utility to encode secret,
we get erz50QD3gv4Dw as seeded hash.

Our password manager generates the same value when seeded with the
same salt, so we can be sure, our output is compatible with
standard LDAP tools that also use crypt: