similar to: Password encription

CRAM-MD5 should not be used. Its not terribly secure. ---Aki TuomiDovecot oy -------- Original message --------From: "j.emerlik" <j.emerlik at gmail.com> Date: 25/10/2017 11:58 (GMT+02:00) To: Aki Tuomi <aki.tuomi at dovecot.fi> Cc: Dovecot Mailing List <dovecot at dovecot.org> Subject: Re: Password encription Thx Aki, with CRAP-MD5 as scheme and mechanism?

SHA512-CRYPT and PLAIN/LOGIN with SSL. ---Aki TuomiDovecot oy -------- Original message --------From: "j.emerlik" <j.emerlik at gmail.com> Date: 25/10/2017 12:07 (GMT+02:00) To: Aki Tuomi <aki.tuomi at dovecot.fi> Cc: Dovecot Mailing List <dovecot at dovecot.org> Subject: Re: Password encription What scheme and mechanism do you recommend? 2017-10-25 11:01 GMT+02:00

Thx Aki, with CRAP-MD5 as scheme and mechanism it's works corretlly. 2017-10-25 10:52 GMT+02:00 Aki Tuomi <aki.tuomi at dovecot.fi>: > PLAIN and LOGIN. > > > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: "j.emerlik" <j.emerlik at gmail.com> > Date: 25/10/2017 11:41 (GMT+02:00) > To: Dovecot Mailing

PLAIN and LOGIN. ---Aki TuomiDovecot oy -------- Original message --------From: "j.emerlik" <j.emerlik at gmail.com> Date: 25/10/2017 11:41 (GMT+02:00) To: Dovecot Mailing List <dovecot at dovecot.org> Subject: Password encription Hi, which authentication mechanism should I use for SHA-256 password schama ? Regards, Jack

The use of salt, today, is to prevent the attacker from directly seeing who has same passwords. Of course it also will make a rainbow table attack less useful, but then again, no one uses rainbow tables anymore since it takes about few minutes to brute force a password in the cloud or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds on dovecot, to make it more computationally

On 27.10.2017 08:37, @lbutlr wrote: > On 25 Oct 2017, at 03:11, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >> SHA512-CRYPT and PLAIN/LOGIN with SSL. > I?m happy with SHA256-CRYPT and PLAIN/LOGIN. > Yes. SHA256-CRYPT is good too. It was just recommendation over using CRAM-MD5, use anything with salt. Aki

Aki, if I understand it well, salt is useful when database is/was stolen ? Then thief can use eg. rainbow tables to decrypt passwords. Regards, Jack 2017-10-27 7:42 GMT+02:00 Aki Tuomi <aki.tuomi at dovecot.fi>: > > > On 27.10.2017 08:37, @lbutlr wrote: > > On 25 Oct 2017, at 03:11, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > >> SHA512-CRYPT and PLAIN/LOGIN

> On October 27, 2017 at 11:27 PM Joseph Tam <jtam.home at gmail.com> wrote: > > > Aki Tuomi wrote: > > > The use of salt, today, is to prevent the attacker from directly seeing > > who has same passwords. Of course it also will make a rainbow table > > attack less useful, > > Not just less useful, but almost infeasible. Given the use of random

Aki Tuomi wrote: > The use of salt, today, is to prevent the attacker from directly seeing > who has same passwords. Of course it also will make a rainbow table > attack less useful, Not just less useful, but almost infeasible. Given the use of random salts, you would have to generate (number of possible salts) rainbow tables. This drastically changes the CPU/storage tradeoffs. >

Op 16/12/2018 om 10:06 schreef Tributh via dovecot: > > Am 16.12.18 um 09:42 schrieb Aki Tuomi: >>> On 16 December 2018 at 10:27 Tributh via dovecot <dovecot at dovecot.org> wrote: >>> >>> >>> Hi, >>> is that here the right place to make feature requests? >>> >>> dovecot supports as authentication mechanism >>>

Dear all, I send you a new email to know what is the progress of SCRAM-SHA-***(-PLUS) supports? Currently there is only SCRAM-SHA-1: https://doc.dovecot.org/configuration_manual/authentication/password_schemes/. - RFC6331: Moving DIGEST-MD5 to Historic: https://tools.ietf.org/html/rfc6331 - RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms:

> On 16 December 2018 at 11:06 Tributh <dovecot-user at tributh.net> wrote: > > > > > Am 16.12.18 um 09:42 schrieb Aki Tuomi: > > > >> On 16 December 2018 at 10:27 Tributh via dovecot <dovecot at dovecot.org> wrote: > >> > >> > >> Hi, > >> is that here the right place to make feature requests? > >> >

> On 16 December 2018 at 10:27 Tributh via dovecot <dovecot at dovecot.org> wrote: > > > Hi, > is that here the right place to make feature requests? > > dovecot supports as authentication mechanism > SCRAM-SHA-1 from RFC 5802 > which was updated to > SCRAM-SHA-256 in RFC 7677 > > Can SCRAM-SHA-256 be added to the authentication mechanisms? > >

Hi, is that here the right place to make feature requests? dovecot supports as authentication mechanism SCRAM-SHA-1 from RFC 5802 which was updated to SCRAM-SHA-256 in RFC 7677 Can SCRAM-SHA-256 be added to the authentication mechanisms? I would not like to request, that SCRAM-SHA-1 will be exchanged by SCRAM-SHA-256, since several applications only support SCRAM-SHA-1 Regards Torsten

> Aki, (Not speaking for Aki) > I understand that salted passwords saved in my database and stronger hash > algorithm course that it will require more processor time/power to crack my > passwords. > > But only when hackers have direct access to my database what means that > hackers have access to my passwords hashes (eg. hackers stolen my database). > > My Dovecot

> On 29/08/2020 23:49 Yves Goergen <nospam.list at unclassified.de> wrote: > > > Hello, > > I'm setting up a new server and, again, seek for a decently secure (from > a security specialist's POV) way to store and verify user passwords in a > database. Additionally now, GDPR requires me to use a solid > state-of-the-art solution. > > My OS is

On 25 Oct 2017, at 03:11, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > SHA512-CRYPT and PLAIN/LOGIN with SSL. I?m happy with SHA256-CRYPT and PLAIN/LOGIN. -- Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Hello I need to authenticate dovecot against openldap. OpenLdap's authentication method requires SHA. How must I set dovecot ? #### /etc/dovecot/dovecot-ldap.conf hosts = ldap-server dn = cn=administrator,o=admin,o=ldap-server dnpass = xxxxx # # # parametros de prueba default_pass_scheme = SHA # # # fin parametros de prueba auth_bind = yes auth_bind_userdn =

Hello, I'm setting up a new server and, again, seek for a decently secure (from a security specialist's POV) way to store and verify user passwords in a database. Additionally now, GDPR requires me to use a solid state-of-the-art solution. My OS is Ubuntu 20.04, Dovecot version 2.3.7, database backend with PostgreSQL 12. Obviously, storing the plaintext password is a terrible idea.

Hello Stephan, Thanks for the link about SCRAM-SHA-256, good news for this point, hope a merge soon :) I am from this page: https://wiki.dovecot.org/Authentication/PasswordSchemes ^^ The -PLUS variant for all SCRAM is not possible too for have (with other SCRAM): SCRAM-SHA-1(-PLUS), SCRAM-SHA-224(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-384(-PLUS), SCRAM-SHA-512(-PLUS) Some softwares use