[Dovecot] auth failure
well, with some help I've made a fair amount of progress on my box. It's working out much easier than I had anticipated and perhaps my notes will be useful some day.
I have two questions...
Here is where I am:
cling:~# egrep -v "^($|\#)" /etc/dovecot.conf protocols = imap imaps login = imap login_max_processes_count = 16 login = pop3 max_mail_processes = 512 verbose_proctitle = yes default_mail_env = maildir:~/Maildir mailbox_check_interval = 1 auth = default auth_mechanisms = plain auth_passdb = pgsql /etc/dovecot-pgsql.conf auth_user = root auth_verbose = yes
cling:~# egrep -v "^($|\#)" /etc/dovecot-pgsql.conf connect = dbname=dbmail user=dbmail_reader password=SECRET default_pass_scheme = PLAIN-MD5 password_query = SELECT passwd AS password FROM users WHERE userid = '%u'
I've created working passwords using 'mkpasswd --hash=md5' and plugged the results into my database.
I can login and everything looks pretty cool.
Except, as near as I can tell, I'm sending plaintext authentication over the wire. My best guess is that my password gets munged into digest-md5 format before it goes over the wire.
At this point I'm of the opinion that I'm reasonably secure. True so far?
My guess is that the next step in security is to go for imaps and ssl configuration. But my debian installation doesn't appear to have the dovecot-openssl.cnf file referenced in the configuration.txt file.
Is this missing from dovecot or am I looking at a debian problem?
My guess is that the next step in security is to go for imaps and ssl configuration. But my debian installation doesn't appear to have the dovecot-openssl.cnf file referenced in the configuration.txt file.
Is this missing from dovecot or am I looking at a debian problem? No debian neither dovecot problem.
protocols = imap imaps Be sure to have certificate for dovecot (Debian should create a default one) ssl_cert_file = /etc/ssl/certs/dovecot.pem ssl_key_file = /etc/ssl/private/dovecot.pem
I prefer to split up the pem file into crt and key and to use one of my own certificates created with my CA, but you can also buy one... if you like (verisign, thawte) ssl_cert_file = /etc/ssl/certs/my_own_cert.crt ssl_key_file = /etc/ssl/private/my_own_private.key Check if the port does accept connection and if you can see the certificate: openssl s_client -connect localhost:993 (imaps port) That should do it. (you bitch! ;-))
On Thu, Jun 10, 2004 at 09:36:48PM -0400, Tom Allison wrote:
I've created working passwords using 'mkpasswd --hash=md5' ... I can login and everything looks pretty cool.
Except, as near as I can tell, I'm sending plaintext authentication over the wire. My best guess is that my password gets munged into digest-md5 format before it goes over the wire.
Those two sentences contradict.
I think you mean you're sending plaintext passwords over the wire; when received at the server they are MD5-hashed, and compared with the hashed passwords in your database.
You can check this with tcpdump, dsniff etc.
At this point I'm of the opinion that I'm reasonably secure. True so far?
Depends on your definition of "secure".
Unless running over SSL, you are not secure against sniffers, who can easily see and re-use your passwords. However someone who breaks into your server will not have a full table of cleartext passwords, only the hashes. That means they have to do some work (a dictionary attack) to recover the passwords. Mind you, given most people's password habits, they'll probably recover 80% of the passwords within seconds anyway.
Brian.
Brian Candler wrote:
On Thu, Jun 10, 2004 at 09:36:48PM -0400, Tom Allison wrote:
I've created working passwords using 'mkpasswd --hash=md5'
...
I can login and everything looks pretty cool.
Except, as near as I can tell, I'm sending plaintext authentication over the wire. My best guess is that my password gets munged into digest-md5 format before it goes over the wire.
Those two sentences contradict.
I think you mean you're sending plaintext passwords over the wire; when received at the server they are MD5-hashed, and compared with the hashed passwords in your database.
You can check this with tcpdump, dsniff etc.
You're right, I think. But I'm not sure exactly where.
I can use telnet 143 to authenticate using plaintext ". login username secret" but sniffit shows my password as garbled up stuff when I send a password through mozilla. Is this a feature of sniffit, mozilla, or what?
I guess I know a lot less about authentication than I thought I did.
At this point I'm of the opinion that I'm reasonably secure. True so far?
Probably not, eh?
Depends on your definition of "secure".
Unless running over SSL, you are not secure against sniffers, who can easily see and re-use your passwords. However someone who breaks into your server will not have a full table of cleartext passwords, only the hashes. That means they have to do some work (a dictionary attack) to recover the passwords. Mind you, given most people's password habits, they'll probably recover 80% of the passwords within seconds anyway.
I'm trying to set up SSL, but I'm not sure it will behave well. Last time I tried this, I had a consistent feature of my SSL connection warning me that my certificate was crap because it wasn't signed properly (I didn't pay Thawte/Verisign to let me read my email).
I'll work on SSL over the weekend, but I know I can connect now with plaintext. It's only allowing connections from my subnet A to subnet B and localhost so it's not as bad as 99.9% of the pop servers out there (or am I wrong on that too?).
I much prefer the md5 storage for passwords since it makes it much harder. As for the choice of passwords... I assign the email passwords and I love pwgen!
On Fri, Jun 11, 2004 at 07:11:01AM -0400, Tom Allison wrote:
I can use telnet 143 to authenticate using plaintext ". login username secret" but sniffit shows my password as garbled up stuff when I send a password through mozilla. Is this a feature of sniffit, mozilla, or what?
I don't know sniffit. What exactly does it show? If it shows
xxx login username yyy then yyy *is* the cleartext password. If it shows
xxx authenticate foo yyyyyyy
then yyyyyyy is base64-encoded authentication data (but trivially decoded in the case where foo is 'PLAIN' or 'LOGIN')
I'd just try "tcpdump -i eth0 -n -s1500 -X tcp port 143" and look at the raw packets.
I'm trying to set up SSL, but I'm not sure it will behave well. Last time I tried this, I had a consistent feature of my SSL connection warning me that my certificate was crap because it wasn't signed properly (I didn't pay Thawte/Verisign to let me read my email).
Well, that's correct, because the whole SSL security model depends on the presence of a trusted third-party to vouch for encryption keys. There's a presentation with a brief overview here: http://www.ws.afnog.org/afnog2004/t1/security/crypto-slides.pdf
But you can always set up your own Certificate Authority and manually install your CA root certificate into your client. That will silence the messages and maintain security.
I'll work on SSL over the weekend, but I know I can connect now with plaintext. It's only allowing connections from my subnet A to subnet B and localhost so it's not as bad as 99.9% of the pop servers out there (or am I wrong on that too?).
IMAP and POP are essentially the same as regards authentication. They both have plain logins (LOGIN or USER/PASS), they both have SASL logins (AUTHENTICATE or AUTH), SASL logins could also be plaintext (PLAIN or LOGIN), and they can optionally run over SSL (either on a different port, or using STARTTLS or STLS)
Regards,
Brian.
participants (3)
-
Brian Candler
-
jb＠weitan.org
-
Tom Allison