> Just because PHP or Dovecot does it or supports it is not an argument > however.
One other point to bolster my argument… I really want to store only one password hash per user and be able to have all my software authenticate using that single (strong and compute intensive) hash. For my site, PHP creates the user accounts and PHP, Dovecot, and DBMail all need to be able to authenticate. PHP supports both mhash that DBMail uses and (imho better) crypt style salted passwords that Dovecot and PHP can use. So, it looks like I’m okay with being able to mkpasswords in PHP and store these separate hashes in two places (and update them in two places when the user changes their password). >From a security point of view, the DBMail db is probably a good place to store >a single hash that all my apps could authenticate against. So, I’m arguing >for a single password type that all my apps can retrieve from the DBMail db >for user authentication. Kevin On Jan 30, 2014, at 3:40 AM, Paul J Stevens <p...@nfg.nl> wrote: > 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/i...@nfg.nl/+31.85.877.99.97 > ________________________________________________________________ > _______________________________________________ > DBmail mailing list > DBmail@dbmail.org > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
