On 30-01-14 01:38, KT Walrus wrote:
> Okay. I search the PHP source and it uses crypt_blowfish.c from
> http://www.openwall.com/crypt/.
>
> This software is in the public domain and provides re-entrant functions and
> could easily be linked into DBMail (I think).
>
> Seems to me this is the best password hash available and should be used for
> DBMail passwords (as the default).
I'm not against adding additional cyphers/hashes for password
encryption. Blowfish looks nice, Skein also looks very good.
Just because PHP or Dovecot does it or supports it is not an argument
however.
In general, security is a multi-layered subject. Providing a good
encryption on passwords however, can *never* be the starting point. It
is a last line of defense.
No hash will protect against brute-force attacks if the attackers have
access to the hashed passwords. Preventing that should be the first
order of business.
Using unencrypted passwords in the database can be a valid design
decision (support for CRAM-MD5 for example). In that case, preventing
unwarranted access is even more important.
If you run third-party PHP code on the same server hosting DBMail, you
have bigger problems. The horror of hosting older joomla installations,
buggy wordpress add-ons, crap legacy php4 code... Buy me a beer and I
could spin you some yarn to light up those cold winter nights.
If your dbmail.conf is world-readable, you have bigger problems.
If the dbmail.dbmail_users table is readable for any mysql user other
than the dbmail user specified in dbmail.conf, think again.
If you allow users to select a trivial password vulnerable to dictionary
attacks, you're wide open.
If you do not run automated counter-measures for repeated failed login
attempts (like fail2ban), you have work to do.
If you allow unencrypted authentication you are vulnerable to
interception. So use and enforce STARTTLS.
Only if all these are in place, and you still feel that your
installation really needs better encryption of passwords, you must be
running a highly critical, and highly visible service. That would
suggest to me you have the man-power and budget to tackle this, or hire
someone to do it for you.
Patches are most welcome.
Rather than patching up the current code, I would very much prefer to
drop mhash - which is unmaintained - and either switch over to another
library that supports more hashes and cyphers, or do our own
implementations using code from elsewhere.
Since most people are probably already linking with OpenSSL, we could
use the API calls from that one instead. It doesn't provide the TIGER
hash, but other than that is looks complete. This is probably the route
of least resistance: only use/require mhash if openssl is not available.
In the longer term I'd prefer to replace non-GPL OpenSSL with the GPL-ed
PolarSSL to do away with the license encumbrance. Same restrictions
apply: no TIGER, but otherwise very complete. But like I said, that's
long term.
So fork dbmail on github, hack away, and when you are satisfied your
code is clean, stable and secure, send me a merge request.
If hacking C is not within reach, drop me a DM if you might consider
sponsoring this.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/[email protected]/+31.85.877.99.97
________________________________________________________________
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
