Thanks for the info. I’m not in a position to sponsor a feature but maybe in the future, if my site becomes popular enough.
I tried to hack in Blowfish last night, but wasn’t successful yet. The problem I have is that the current code doesn’t seem to be set up to deal with salted passwords. I think I need two functions: one to hash to a salted password (mkpassword), and one to check the password against the salted hash (chkpassword). I couldn’t find the chkpassword function, so it appears to me that the code must call mkpassword for creating the hash and for comparing. Anyway, I’ll probably spend another hour or so to see what it takes to shoehorn in support for Blowfish before I give up. The appeal of Blowfish to me is that you can specify how many iterations the hash takes to compute. So, if I’m really paranoid about some SQL injection hack copying passwords out of the DB, I can set Blowfish to take a full second to compute the hash (this would be overkill, I know). This seems to really be able to deter any hacker guessing the passwords with a password cracker and “future-proofs” the hashes since I can bump up the iteration count as processors get faster. Also, many people use the same passwords and if the hashes aren’t salted, it makes it easy for a hacker to spot the most used passwords and concentrate the password cracker to crack those first. I’ll probably live with unsalted hashes in DBMail authentication and hope that in a future version, this area is reworked for salted hashes (and Blowfish, in particular). I currently haven’t been able to get sha512 working in DBMail (maybe a bug?). I can change the password using password type sha512, but dbmail-imapd doesn’t authenticate (sha256 does work, so I’m using that now in my testbed set up). Kevin On Jan 30, 2014, at 3:40 AM, Paul J Stevens <[email protected]> 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/[email protected]/+31.85.877.99.97 > ________________________________________________________________ > _______________________________________________ > DBmail mailing list > [email protected] > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
