This is bugging me, because it occurred to me that even if we had SSL in the clients and LDAP support in the sever, I still wouldn't be able to have people use LDAP passwords for LiveJournal. The LiveJournal server doesn't know the LDAP passwords, it can only verify credentials by attempting to bind to LDAP as the user, so the client has to send it an unhashed password. But if the client stores an unhashed sensitive password in the filesystem, that's bad; if that filesystem is a network-mounted home directory, that's really bad.
I can envision this working: On first connect, the client sends an unhashed password (over SSL of course). The server verifies it against LDAP, hashes it, stores the hash, and sends back the hash. The client stores the hash in a file, and subsequently uses that hash for auto-login. For better security, the hash should be salted with a LiveJournal-specific string, so that if anyone compromises it they can only use it to get into LiveJournal and not anything else that might use a hashed LDAP password.
On the client, this requires only two changes, aside from SSL support. First, if the server uses SSL, then send an unhashed password. Second, if the server returns a new password, store that instead of the password the user typed in.
The only weakness I see is that the hash will continue to work for authentication even if the LDAP password is changed, which is probably undesirable. (Or maybe there's a way to query LDAP to find out the last modified date for a specific field?)
Does this seem reasonable? Is there a better way?