I added an appendix for special user accounts that don’t follow the normal password rules to my paper describing the password hashing and storage.
Some users have no hash at all but are instead stored with fixed values.
ANONYMOUS – SYS.USER$.PASSWORD has a value of exactly 16 spaces. The SPARE4 column is NULL. Since the value is not the result of a hash, it is not possible to log in with user directly as no password will hash this value. If read from the DBA_USERS view, the PASSWORD_VERSIONS value is NULL. It is possible to create such a user of your own, using the IDENTIFIED BY VALUES clause of exactly 16 spaces; but it is not particularly useful to do so. Perhaps in a pre-18 db it could be used to create a schema-only account since it could not be used for log in.
XS$NULL – This account isn’t a real user. According to the Oracle documentation it is “An internal account that represents the absence of a user in a session.” The SYS.USER$.PASSWORD value is NULL. The SPARE4 value is an 11g placeholder of “S:” followed by 60 space characters.
18c introduced a new type of user called a “Schema Only” user. Meaning it has no direct login. The intent being these accounts will own objects. They may not be used for users or applications to log in, thus providing an extra layer of isolation and security. The SYS.USER$.PASSWORD value is NULL, the SPARE4 value contains 11g and 12c hash place holders consisting of only zeroes and a salt. Thus “S:” followed by 40 zeroes and 20 hex-characters for the salt. Then “T:” followed by 128 zeroes and a 32-character hex salt.
The Multi-Tenant option also introduces special password formats. Within the CDB$ROOT, Common Users will follow standard hashing rules and storage. When viewed from the Pluggable DBs though, the common users will have a NULL value for SYS.USER$.PASSWORD. The SPARE4 value will have “S:“ and “T:” placeholders but the values will consist entirely of space characters – 60 spaces for the 11g value and 160 spaces for the 12c value.