similar to: Password encription

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

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?

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

Hi, which authentication mechanism should I use for SHA-256 password schama ? Regards, Jack

> 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

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 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. >

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 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.

> On 15 Jun 2019, at 21:09, Aki Tuomi <aki.tuomi at open-xchange.com> wrote: > > >> On 15 June 2019 10:56 Daniel Lange via dovecot <dovecot at dovecot.org> wrote: >> >> >> Am 15.06.19 um 00:36 schrieb Michal Krzysztofowicz via dovecot: >>> Would you know if Dovecot project uses an issue tracker which is publicly available, and which I can

Hi! This change has now been committed, please find it at https://github.com/dovecot/core/compare/cd08262%5E...dd6323.patch Aki On 16.07.2018 09:53, Aki Tuomi wrote: > This is a known issue, but thanks for reporting it. > > > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Eric Toombs <ewtoombs at uwaterloo.ca> > Date:

I couldn't find anything relevant between all the debug log lines. Is that in /var/log/mail.log? Here's the lines I think are related to creating and deleting the folder: > May 21 10:36:14 mond2 dovecot: imap(yg@****.de): Debug: Namespace : /var/mail/virtual/****.de/yg/.Test doesn't exist yet, using default permissions > May 21 10:36:14 mond2 dovecot: imap(yg@****.de): Debug:

Here's the output of 'doveconf -n': # 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.13 (7b14904) doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -n > dovecot-new.conf doveconf: Warning: Obsolete setting in /etc/dovecot/local.conf:21: ssl_parameters_regenerate should have 'hours' suffix # OS: Linux 4.4.0-124-generic x86_64

Solved temporary by replacing X-Spam-Status to X-Spam-Flag. X-Spam-Flag in my system is added only to SPAM e-mail, anyway it looks like a bug. Regards, Jack 2017-07-07 12:41 GMT+02:00 j.emerlik <j.emerlik at gmail.com>: > Yes, I'am sure. > > I've only global as: > ============== > require "fileinto"; > > if header :contains

Op 7/7/2017 om 1:18 PM schreef j.emerlik: > Solved temporary by replacing X-Spam-Status to X-Spam-Flag. > > X-Spam-Flag in my system is added only to SPAM e-mail, anyway it looks like > a bug. Can you show your configuration (output from `dovecot -n`)? An example message may also be useful. Regards, Stephan. > Regards, > Jack > > > 2017-07-07 12:41 GMT+02:00

> 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

Sure ! # 2.2.24 (a82c823): /usr/local/etc/dovecot/dovecot.conf # Pigeonhole version 0.4.14 (099a97c) # OS: Linux 4.4.2-hardened x86_64 Gentoo Base System release 2.2 auth_mechanisms = plain login auth_verbose = yes default_client_limit = 4096 default_internal_user = mailer default_process_limit = 300 dict { sqlquota = pgsql:/usr/local/etc/dovecot/dovecot-dict-sql.conf.ext }

Hy everybody, I'm using rsync to backup/synchronize folders to/from USB connected external hard drives. But I can't find an answer to a doubt. Does rsync use encription also for local tranfers? For "local transfer" I mean a transfer that doesn't go through a network like folders synchronization with external hard drives. I'm asking because the speed of local transfers

I guess you have had different version(s) or setting(s) in the past, and you can probably fix this by setting perms to same as the new folders. Aki On 21.05.2018 11:46, Yves Goergen wrote: > I couldn't find anything relevant between all the debug log lines. Is > that in /var/log/mail.log? > > Here's the lines I think are related to creating and deleting the folder: >