Re: Moving to new password scheme

[@lbutlr]

On Jan 25, 2017, at 4:57 AM, Steffen Kaiser  
wrote:
> yes, userdb's are checked in the same order as they appear in the config 
> file(s).

Thanks for all the help, got everyone migrated over to SHA256-CRYPT now.


-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Moving to new password scheme

[KSB]

On 2017.01.25. 10:09, Alessio Cecchi wrote:

Il 24/01/2017 23:29, @lbutlr ha scritto:

dovecot is setup on a system with MD5-CRYPT password scheme for all
users, and I would like to update this to something that is secure,
probably SSHA256-CRYPT, but I want to do this seamlessly without the
users having to jump through any hoops.

The users are in mySQL (managed via postfixadmin) and the mailbox
record simply stores the hash in the password field. Users access
their accounts though IMAP MUAs or Roundcube.

How would I setup my system so that if a user logs in and still has a
$1$ password (MD5-CRYPT) their password will be encoded to the new
SHCEME and then the SQL row updated with the $5$ password instead?
Something where they are redirected after authentication to a page
that forces them to renter their password (or choose a new one) is
acceptable.

And, while I am here, is it worthwhile to set the -r flag to a large
number (like something over 100,000 which sets takes about 0.25
seconds to do on my machine)?


Hi,

you can convert password scheme during the login:

http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes

Ciao



I've done it with nice and short pg's stored procedure.

--
KSB

Re: Moving to new password scheme

[Joseph Tam]

Okn Mon, 30 Jan 2017, dovecot-requ...@dovecot.org wrote:


OK, I have the dovecot.conf stuff working so that it calls the external
script and I have that script spitting out the login and a SHA256-CRYPT
password with hash:

Thu Jan 26 06:45:54 MST 2017
USER: xan...@xanmax.com
{SHA512-CRYPT}$6$CfKc0NdiRkWOisjL$kHAx2oxB?


Did you truncate the results?  This hash looks far too short to be a real SHA512
hash.

Joseph Tam 

Re: Moving to new password scheme

[@lbutlr]

OK, I have the dovecot.conf stuff working so that it calls the external script 
and I have that script spitting out the login and a SHA256-CRYPT password with 
hash:

Thu Jan 26 06:45:54 MST 2017
USER: xan...@xanmax.com
{SHA512-CRYPT}$6$CfKc0NdiRkWOisjL$kHAx2oxB…

SO, feeling pretty good about that. However, i want to check one more thing, 
before I start issuing the commands to update the sql database, I will need to 
update postfixadmin (I think) to use dovecot:SHA256-CRYPT instead of its 
default $CONF['encrypt'] = 'md5crypt'; yes?

And this means that until someone logs in to their mail, they will not be able 
to login to postfixadmin, right?

(This is not a problem, I just want to be sure)


-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Moving to new password scheme

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 25 Jan 2017, @lbutlr wrote:

On Jan 25, 2017, at 2:46 AM, Steffen Kaiser  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 25 Jan 2017, @lbutlr wrote:

On Jan 25, 2017, at 1:09 AM, Alessio Cecchi  wrote:

Il 24/01/2017 23:29, @lbutlr ha scritto:

dovecot is setup on a system with MD5-CRYPT password scheme for all users, and 
I would like to update this to something that is secure, probably 
SSHA256-CRYPT, but I want to do this seamlessly without the users having to 
jump through any hoops.

The users are in mySQL (managed via postfixadmin) and the mailbox record simply 
stores the hash in the password field. Users access their accounts though IMAP 
MUAs or Roundcube.

How would I setup my system so that if a user logs in and still has a $1$ 
password (MD5-CRYPT) their password will be encoded to the new SHCEME and then 
the SQL row updated with the $5$ password instead? Something where they are 
redirected after authentication to a page that forces them to renter their 
password (or choose a new one) is acceptable.

And, while I am here, is it worthwhile to set the -r flag to a large number 
(like something over 100,000 which sets takes about 0.25 seconds to do on my 
machine)?


Hi,

you can convert password scheme during the login:

http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes


Thanks, I started to look into that and got stopped no the first step


userdb {
 driver = prefetch
}


If I set that and reload dovecot users cannot login.

dovecot: auth: Fatal: userdb prefetch: No args are supported: 
/etc/dovecot/dovecot-sql.conf.ext
dovecot: master: Error: service(auth): command startup failed, throttling for 8 
secs
dovecot: imap-login: Disconnected: Auth process broken (disconnected before auth was 
ready, waited 4 secs): user=<>,


I don't see no prefetch in your config.


No, when I changed userdb { driver = passwd } to prefetch everything failed, so 
I changed it back immediately so people could login. That was the firs step on 
the page and I couldn’t get past it.


The error may indicate that you replaced driver = sql by driver = prefetch, 
which is wrong.


driver = sql is in the imap/sql section. The one I tried changing was the bare 
userdb declaration the just said driver - passwd.

I guess I need to ADD another userdb declaration for the prefetch.

Does the other int he file matter? I have local users stuff first and then the 
sql stuff later, but I’m not sure if that matters.


yes, userdb's are checked in the same order as they appear in the config 
file(s).



http://wiki2.dovecot.org/UserDatabase/Prefetch

The idea described on the Wiki page is:

During login, most often the same data is collected from the passdb as later 
from the userdb, therefore you can collect *all* information you would retrieve 
from userdb { } within passdb queries (that's why the home as userdb_home, \
uid as userdb_uid, gid as userdb_gid, '%w' as userdb_plain_pass entries; the 
prefix userdb_ indicates that data) and store it for later use by the prefetch 
database.

That's why the prefetch userdb has to preceed the other ones, because if the 
passdb query filled in the values, the later userdb entries are ignored.


So Place it first (or at least before all the sql stuff)?


yep.


You've noticed the '%w' as userdb_plain_pass ? That stores the plain password 
(if any) to the virtual prefetch userdb entry as field plain_pass.


OK.


Now, you are using two passdb's. the PAM passdb won't support this method, I 
guess.


No, I’m not expecting it to. the local users are mostly my admin accounts and I 
can just change the passwords on those manually without an issue.

I’ll keep at it. Thanks.




- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWIiSrHz1H7kL/d9rAQJsZgf+MbLgAk7u3oUrFsVCwoU1yf013/PEUMs1
7bicH0GBotx5FNJt2KwHjjAizOzmHwdMrrIchdSVl6Fb62SOSdtwuykvmfnp2Rpu
EUHBXlsyOpIytgDkyZcxnjFb4HyxbHccwoR8OWcFuknPVt/jMbwSxgAS9qjAlEnj
wtvy01sn2L7ICevHRE6aaZfY3AeAEIkWPfWKoZLm5FQ6QL8ANnCj4QhKMW94It7Z
EFuHx3EjvkUbyZ55fMPTYqPds8SmvW1waYVNSQD8xqZunpGhIOKSd+qIFVoStynX
Nn5HG2mYnSKiBJf97UErIQJRkR4rY8DZMlS3RXncaSvl+Th9x5o0Ow==
=Gpt5
-END PGP SIGNATURE-

Re: Moving to new password scheme

[@lbutlr]

> On Jan 25, 2017, at 2:46 AM, Steffen Kaiser  
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Wed, 25 Jan 2017, @lbutlr wrote:
>>> On Jan 25, 2017, at 1:09 AM, Alessio Cecchi  wrote:
>>> 
>>> Il 24/01/2017 23:29, @lbutlr ha scritto:
 dovecot is setup on a system with MD5-CRYPT password scheme for all users, 
 and I would like to update this to something that is secure, probably 
 SSHA256-CRYPT, but I want to do this seamlessly without the users having 
 to jump through any hoops.
 
 The users are in mySQL (managed via postfixadmin) and the mailbox record 
 simply stores the hash in the password field. Users access their accounts 
 though IMAP MUAs or Roundcube.
 
 How would I setup my system so that if a user logs in and still has a $1$ 
 password (MD5-CRYPT) their password will be encoded to the new SHCEME and 
 then the SQL row updated with the $5$ password instead? Something where 
 they are redirected after authentication to a page that forces them to 
 renter their password (or choose a new one) is acceptable.
 
 And, while I am here, is it worthwhile to set the -r flag to a large 
 number (like something over 100,000 which sets takes about 0.25 seconds to 
 do on my machine)?
 
>>> Hi,
>>> 
>>> you can convert password scheme during the login:
>>> 
>>> http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes
>> 
>> Thanks, I started to look into that and got stopped no the first step
>> 
>>> userdb {
>>>  driver = prefetch
>>> }
>> 
>> If I set that and reload dovecot users cannot login.
>> 
>> dovecot: auth: Fatal: userdb prefetch: No args are supported: 
>> /etc/dovecot/dovecot-sql.conf.ext
>> dovecot: master: Error: service(auth): command startup failed, throttling 
>> for 8 secs
>> dovecot: imap-login: Disconnected: Auth process broken (disconnected before 
>> auth was ready, waited 4 secs): user=<>,
> 
> I don't see no prefetch in your config.

No, when I changed userdb { driver = passwd } to prefetch everything failed, so 
I changed it back immediately so people could login. That was the firs step on 
the page and I couldn’t get past it.

> The error may indicate that you replaced driver = sql by driver = prefetch, 
> which is wrong.

driver = sql is in the imap/sql section. The one I tried changing was the bare 
userdb declaration the just said driver - passwd.

I guess I need to ADD another userdb declaration for the prefetch.

Does the other int he file matter? I have local users stuff first and then the 
sql stuff later, but I’m not sure if that matters.


> http://wiki2.dovecot.org/UserDatabase/Prefetch
> 
> The idea described on the Wiki page is:
> 
> During login, most often the same data is collected from the passdb as later 
> from the userdb, therefore you can collect *all* information you would 
> retrieve from userdb { } within passdb queries (that's why the home as 
> userdb_home, \
> uid as userdb_uid, gid as userdb_gid, '%w' as userdb_plain_pass entries; the 
> prefix userdb_ indicates that data) and store it for later use by the 
> prefetch database.
> 
> That's why the prefetch userdb has to preceed the other ones, because if the 
> passdb query filled in the values, the later userdb entries are ignored.

So Place it first (or at least before all the sql stuff)?

> You've noticed the '%w' as userdb_plain_pass ? That stores the plain password 
> (if any) to the virtual prefetch userdb entry as field plain_pass.

OK.

> Now, you are using two passdb's. the PAM passdb won't support this method, I 
> guess.

No, I’m not expecting it to. the local users are mostly my admin accounts and I 
can just change the passwords on those manually without an issue.

I’ll keep at it. Thanks.

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Re: Moving to new password scheme

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 25 Jan 2017, @lbutlr wrote:

On Jan 25, 2017, at 1:09 AM, Alessio Cecchi  wrote:

Il 24/01/2017 23:29, @lbutlr ha scritto:

dovecot is setup on a system with MD5-CRYPT password scheme for all users, and 
I would like to update this to something that is secure, probably 
SSHA256-CRYPT, but I want to do this seamlessly without the users having to 
jump through any hoops.

The users are in mySQL (managed via postfixadmin) and the mailbox record simply 
stores the hash in the password field. Users access their accounts though IMAP 
MUAs or Roundcube.

How would I setup my system so that if a user logs in and still has a $1$ 
password (MD5-CRYPT) their password will be encoded to the new SHCEME and then 
the SQL row updated with the $5$ password instead? Something where they are 
redirected after authentication to a page that forces them to renter their 
password (or choose a new one) is acceptable.

And, while I am here, is it worthwhile to set the -r flag to a large number 
(like something over 100,000 which sets takes about 0.25 seconds to do on my 
machine)?


Hi,

you can convert password scheme during the login:

http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes


Thanks, I started to look into that and got stopped no the first step


 userdb {
  driver = prefetch
}


If I set that and reload dovecot users cannot login.

dovecot: auth: Fatal: userdb prefetch: No args are supported: 
/etc/dovecot/dovecot-sql.conf.ext
dovecot: master: Error: service(auth): command startup failed, throttling for 8 
secs
dovecot: imap-login: Disconnected: Auth process broken (disconnected before auth was 
ready, waited 4 secs): user=<>,


I don't see no prefetch in your config. The error may indicate that you 
replaced driver = sql by driver = prefetch, which is wrong.


http://wiki2.dovecot.org/UserDatabase/Prefetch

The idea described on the Wiki page is:

During login, most often the same data is collected from the passdb as 
later from the userdb, therefore you can collect *all* information you 
would retrieve from userdb { } within passdb queries (that's why the home 
as userdb_home, \
uid as userdb_uid, gid as userdb_gid, '%w' as userdb_plain_pass entries; 
the prefix userdb_ indicates that data) and store it for later use by the 
prefetch database.


That's why the prefetch userdb has to preceed the other ones, because if 
the passdb query filled in the values, the later userdb entries are 
ignored.


You've noticed the '%w' as userdb_plain_pass ? That stores the plain 
password (if any) to the virtual prefetch userdb entry as field 
plain_pass.


Those fields are available later as environment variables, that's why 
/usr/local/etc/popafter.sh


may use:

   1 #!/bin/sh
   2 DOVECOTPW=$(doveadm pw -s SHA512-CRYPT -p $PLAIN_PASS)

to access it.

Now, you are using two passdb's. the PAM passdb won't support this method, 
I guess.



# 2.2.27 (c0f36b0): /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 10.3-RELEASE-p11 i386
auth_failure_delay = 5 secs
auth_mechanisms = PLAIN LOGIN
default_client_limit = 4096
default_process_limit = 1024
default_vsz_limit = 768 M
disable_plaintext_auth = no
first_valid_uid = 89
imap_id_log = *
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
login_log_format_elements = user=<%u> %r %m %c
mail_location = maildir:~/Maildir
mail_max_userip_connections = 90
namespace inbox {
 inbox = yes
 location =
 mailbox Drafts {
   special_use = \Drafts
 }
 mailbox Junk {
   auto = subscribe
   special_use = \Junk
 }
 mailbox NotJunk {
   auto = subscribe
 }
 mailbox Sent {
   special_use = \Sent
 }
 mailbox Trash {
   special_use = \Trash
 }
 prefix =
}
passdb {
 driver = pam
}
passdb {
 args = /etc/dovecot/dovecot-sql.conf.ext
 driver = sql
}
protocols = imap
service auth {
 unix_listener /var/spool/postfix/private/auth {
   mode = 0666
 }
}
service imap-login {
 inet_listener imaps {
   port = 993
   ssl = yes
 }
}
service imap-postlogin {
 executable = script-login /usr/local/etc/dovecot/afterlogin.sh
 user = $default_internal_user
}
ssl_cert = 

- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWIhz93z1H7kL/d9rAQJUuQf/UVdPDGn0zVdyTPEG/rfiQGXONpTUArWa
FI6h2amH7UwEXqfZ/Z3x3JmbFGgZ/bHavnqgsE+os19DtUIo4LYLBZvZDLA5FErt
vSKlzObXzDaofKktIkpu40j3RimRJTjpgilTvh0ne+wJnaCHZTF4pD6YeR7BRHN3
CBCefg6UALG6XLZ9nTOA07l7q/GFSvCaWvqApXpjQwA4DrwwH0ZoFq+peVfblrr7
8oqIVZiWPgiqR2BRxyNpPLU5mOJIcCrWqrSBtpRxPXmqcTjXMgA7TioTs8Jm/ooE
wWkKj8GBSlTZjbI1KycJlfPevSbsfxnLKdewpS7WI2Tcr4uEezWTrg==
=cUh0
-END PGP SIGNATURE-

Re: Moving to new password scheme

[@lbutlr]

> On Jan 25, 2017, at 1:09 AM, Alessio Cecchi  wrote:
> 
> Il 24/01/2017 23:29, @lbutlr ha scritto:
>> dovecot is setup on a system with MD5-CRYPT password scheme for all users, 
>> and I would like to update this to something that is secure, probably 
>> SSHA256-CRYPT, but I want to do this seamlessly without the users having to 
>> jump through any hoops.
>> 
>> The users are in mySQL (managed via postfixadmin) and the mailbox record 
>> simply stores the hash in the password field. Users access their accounts 
>> though IMAP MUAs or Roundcube.
>> 
>> How would I setup my system so that if a user logs in and still has a $1$ 
>> password (MD5-CRYPT) their password will be encoded to the new SHCEME and 
>> then the SQL row updated with the $5$ password instead? Something where they 
>> are redirected after authentication to a page that forces them to renter 
>> their password (or choose a new one) is acceptable.
>> 
>> And, while I am here, is it worthwhile to set the -r flag to a large number 
>> (like something over 100,000 which sets takes about 0.25 seconds to do on my 
>> machine)?
>> 
> Hi,
> 
> you can convert password scheme during the login:
> 
> http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes

Thanks, I started to look into that and got stopped no the first step

>  userdb {
>   driver = prefetch
> }

If I set that and reload dovecot users cannot login.

dovecot: auth: Fatal: userdb prefetch: No args are supported: 
/etc/dovecot/dovecot-sql.conf.ext
dovecot: master: Error: service(auth): command startup failed, throttling for 8 
secs
dovecot: imap-login: Disconnected: Auth process broken (disconnected before 
auth was ready, waited 4 secs): user=<>,

# 2.2.27 (c0f36b0): /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 10.3-RELEASE-p11 i386  
auth_failure_delay = 5 secs
auth_mechanisms = PLAIN LOGIN
default_client_limit = 4096
default_process_limit = 1024
default_vsz_limit = 768 M
disable_plaintext_auth = no
first_valid_uid = 89
imap_id_log = *
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
login_log_format_elements = user=<%u> %r %m %c
mail_location = maildir:~/Maildir
mail_max_userip_connections = 90
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox NotJunk {
auto = subscribe
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  driver = pam
}
passdb {
  args = /etc/dovecot/dovecot-sql.conf.ext
  driver = sql
}
protocols = imap
service auth {
  unix_listener /var/spool/postfix/private/auth {
mode = 0666
  }
}
service imap-login {
  inet_listener imaps {
port = 993
ssl = yes
  }
}
service imap-postlogin {
  executable = script-login /usr/local/etc/dovecot/afterlogin.sh
  user = $default_internal_user
}
ssl_cert = 

Re: Moving to new password scheme

[Alessio Cecchi]

Il 24/01/2017 23:29, @lbutlr ha scritto:

dovecot is setup on a system with MD5-CRYPT password scheme for all users, and 
I would like to update this to something that is secure, probably 
SSHA256-CRYPT, but I want to do this seamlessly without the users having to 
jump through any hoops.

The users are in mySQL (managed via postfixadmin) and the mailbox record simply 
stores the hash in the password field. Users access their accounts though IMAP 
MUAs or Roundcube.

How would I setup my system so that if a user logs in and still has a $1$ 
password (MD5-CRYPT) their password will be encoded to the new SHCEME and then 
the SQL row updated with the $5$ password instead? Something where they are 
redirected after authentication to a page that forces them to renter their 
password (or choose a new one) is acceptable.

And, while I am here, is it worthwhile to set the -r flag to a large number 
(like something over 100,000 which sets takes about 0.25 seconds to do on my 
machine)?


Hi,

you can convert password scheme during the login:

http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes

Ciao

--
Alessio Cecchi
Postmaster @ http://www.qboxmail.it
https://www.linkedin.com/in/alessice

Moving to new password scheme

[@lbutlr]

dovecot is setup on a system with MD5-CRYPT password scheme for all users, and 
I would like to update this to something that is secure, probably 
SSHA256-CRYPT, but I want to do this seamlessly without the users having to 
jump through any hoops.

The users are in mySQL (managed via postfixadmin) and the mailbox record simply 
stores the hash in the password field. Users access their accounts though IMAP 
MUAs or Roundcube.

How would I setup my system so that if a user logs in and still has a $1$ 
password (MD5-CRYPT) their password will be encoded to the new SHCEME and then 
the SQL row updated with the $5$ password instead? Something where they are 
redirected after authentication to a page that forces them to renter their 
password (or choose a new one) is acceptable.

And, while I am here, is it worthwhile to set the -r flag to a large number 
(like something over 100,000 which sets takes about 0.25 seconds to do on my 
machine)?

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.