On Thu, 20 Dec 2018 at 15:54, Aki Tuomi <aki.tuomi at open-xchange.com> wrote:> > On 20 December 2018 at 14:33 Odhiambo Washington < odhiambo at gmail.com> > wrote: > > > On Thu, 20 Dec 2018 at 15:23, Aki Tuomi < aki.tuomi at open-xchange.com> > wrote: > > > > > On 20 December 2018 at 14:10 Odhiambo Washington < odhiambo at gmail.com> > wrote: > > > > > You've made this more difficult to understand, even :-) > > So the answer is: > Set the following in 10-auth.conf > > 1. disable_plaintext_auth = no > 2. auth_mechanisms = plain > > And yes, the encrypted passwords are stored in MySQL. > > > > > You cannot use hashed passwords with digest-md5 mechanism. > > Aki > > > So, for the record, whenever passwords are hashed, digest-md5 should be > disabled/removed from auth_mechanisms. > > My question though - for purposes of understanding - how does dovecot take > the sent password from a client and match it against the hashed one stored > in the DB (in my case)? What happens in between the process? > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > "Oh, the cruft.", grep ^[^#] :-) > > > Dovecot hashes the client sent password using the same salt and compares > the result. > --- > Aki Tuomi >At the expense of sounding stupid, could you please expound on the sequence? :) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20181220/037a8749/attachment-0001.html>
On Thu, 20 Dec 2018, Odhiambo Washington wrote:> At the expense of sounding stupid, could you please expound on the > sequence? :)In a nutshell, during protocol handshake, the server gives the client a random string (nonce). Both the server and client performs a cryptographic hash of nonce+password, and the client tells the server the result of the hash, and the server compares the client's result with its own. If the results match, it proves the client has knowledge of the password. The strength relies upon cryptographics hashes not being invertible. It's one way of protecting password from sniffing when you can't use SSL. However, there's many weaknesses: the password must be kept on the server in plaintext, offline brute forcing, etc. Joseph Tam <jtam.home at gmail.com>
Nice to get to hear this. However, the password is not stored in clear text here. How then does it work? On Fri, Dec 21, 2018, 00:58 Joseph Tam <jtam.home at gmail.com wrote:> On Thu, 20 Dec 2018, Odhiambo Washington wrote: > > > At the expense of sounding stupid, could you please expound on the > > sequence? :) > > In a nutshell, during protocol handshake, the server gives the client > a random string (nonce). Both the server and client performs a > cryptographic hash of nonce+password, and the client tells the server > the result of the hash, and the server compares the client's result with > its own. If the results match, it proves the client has knowledge of > the password. > > The strength relies upon cryptographics hashes not being invertible. > It's one way of protecting password from sniffing when you can't use SSL. > However, there's many weaknesses: the password must be kept on the server > in plaintext, offline brute forcing, etc. > > Joseph Tam <jtam.home at gmail.com> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20181221/49fad9e8/attachment.html>
On Thu, 20 Dec 2018, Joseph Tam wrote:>> At the expense of sounding stupid, could you please expound on the >> sequence? :)If you want the nitty details (Starting at bottom of page 18) https://tools.ietf.org/html/rfc2831 Joseph Tam <jtam.home at gmail.com>