Forgot your password?
New user?
The Ticket-Granting Ticket
Document Actions
Shared secrets mechanisms
Shared secrets mechanisms
Next: Kerberos mechanisms Up: SASL Previous: write your own
Shared secrets mechanisms
The Cyrus SASL library also supports some "shared secret" authentication methods: CRAM-MD5 and it's successor DIGEST-MD5. These methods rely on the client and the server sharing a "secret", usually a password. The server generates a challenge and the client a response proving that it knows the shared secret. This is much more secure than simply sending the secret over the wire proving that the client knows it.
There's a downside: in order to verify such responses, the server must keep password equivalents in a database; if this database is compromised, it is the same as if every user's password for that realm is compromised.
The Cyrus SASL library stores these secrets in the /etc/sasldb database. Depending on the exact database method used (gdbm, ndbm, or db) the file may have different suffixes or may even have two different files ("sasldb.dir" and "sasldb.pag"). It is also possible for a server to define it's own way of storing authentication secrets. Currently, no application is known to do this.
The principle problem for a system administrator is to make sure that sasldb is properly protected; only the servers that need to read it to verify passwords should be able to. If there are any normal shell users on the system, they must not be able to read it.
Managing password changes is outside the scope of the library. However, system administrators should probably make a way of letting user's change their passwords available to users. The "saslpasswd" utility is provided to change the secrets in sasldb. It does not affect PAM, /etc/passwd, or any other standard system library; it only affects secrets stored in sasldb.
Finally, system administrators should think if they want to enable "auto_transition". If set, the library will automatically create secrets in sasldb when a user uses PLAIN to successfully authenticate. However, this means that the individual servers, such as imapd, need read/write access to sasldb, not just read access. By default, "auto_transition" is set to false; set it to true to enable. (There's no point in enabling this option if "pwcheck_method" is "sasldb".)
Next: Kerberos mechanisms Up: SASL Previous: write your own
2005-05-04