Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-24 Thread Aki Tuomi


> On 15/11/2022 14:55 EET Aki Tuomi  wrote:
> 
>  
> > On 15/11/2022 14:45 EET Krisztián Szegi  wrote:
> > 
> >  
> > Good day to all,
> >  
> > this is my first post to the mailing list!
> >  
> > I'd like to report that non-binding auth to (Open)LDAP doesn't work if the 
> > latter hashes passwords with ARGON2.
> >  
> > Although dovecot (I am using http://2.3.19.1) does support ARGON2 with 
> > libsodium, but it doesn't recoginize hashes beginning "{ARGON2}$argon2id$" 
> > stored (and hashed, using ppolicy module's hashCleartext) by OpenLDAP.
> >  
> > Now, I understand that ARGON2I, -D, and -ID are not compatible, but the 
> > ACTUAL algorithm is there between the two $.
> > Furthermore, I think dovecot is in the minority here, I haven't met any 
> > software that specifies the ARGON2 subtype between {}.
> > BTW, I haven't met any software that hashes passwords with ARGON2, but not 
> > with the ARGON2ID subtype (where libsodium is available, which also seems 
> > to be the standard here), as THAT is the recommended one anyway.
> > 
> > I patched the rpm in OpenSUSE repo to alias {ARGON2} to {ARGON2ID}:
> > https://build.opensuse.org/package/view_file/home:Samonitari:branches:openSUSE:Factory/dovecot23/dovecot-2.3.0-alias_ARGON2_to_ARGON2ID.patch
> >  
> > Could we get something like this (but maybe more correct) into the official 
> > source?
> > Maybe a config switch to alias it runtime?
> >  
> > Thanks for the attention:
> > Krisztián
> 
> Hi!
> 
> Thanks for your report. I think it makes sense, we'll see what we can do 
> about this.
> 
> Aki

This has been fixed in 
https://github.com/dovecot/core/commit/6e3239d8fbe33f96352d24a563a0c7595d29dca9

Regards,
Aki Tuomi


Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-16 Thread Krisztián Szegi
"Krisztián Szegi" k@mszk.eu – 15 November 2022 20:18
> "Michael Ströder" mich...@stroeder.com – 15 November 2022 15:00
> > On 11/15/22 13:45, Krisztián Szegi wrote:
> >> I'd like to report that non-binding auth to (Open)LDAP doesn't work
> >> if the latter hashes passwords with ARGON2.
> > Could you please elaborate why using LDAP bind is a problem for you?
> >  
> > Ciao, Michael.
> >  
> > 
>  
> Fair enough question!
>  
> I cannot specify bind_dn template due to mismatched mail addresses and user 
> DNs, and I thought that that would be suboptimal due to re-binding.
> I am a bit confused about how to optimize LDAP lookups now (static files not 
> option :), re-reading the docs it just made me question more things
> - auth_bind_dn cannot be given in my case, as a fixed starting point
> - auth_bind adds a temporary binding (using pass_filter)
> - can I use userdb prefetch? Docs say I cannot if I use bind with template, 
> but I am not using the latter. So the search for the user's dn during auth IS 
> the passdb lookup?
> - assuming I am correct, I should give back stuff with passdb lookup: or do I?
>   - Must I give back userid an guid? 10-mail.conf has "vmail" for both, as 
> mail accounts don't have UNIX ones linked to them...
>   - same for home? There is no default I've given until userdb lookup. Just 
> specify a global mail_home with variables, and get on with life?
>   -if I should give back one, should I pass it with default_fields = 
> userdb_home (currently I specify it under default_fields:home in userdb 
> lookup as LDAP doesn't override home).
> 
> The docs are confusing around userdb. The main thing what is not clear that 
> they CAN override fields on a per-user basis, but must they provide them for 
> non-extra fields, when there are global settings for those?
> 
> Thanks!
> 
> BTW, thanks for the great software all of you.
> Michael, I've come across some of your work, you have my respect!
> 

On second though:
I switched to auth_bind = yes, (I'll start a new thread on optimizing passdb 
and userdb, because the scattered documentation has some holes in it I think) 
but my patch is still needed - if I understand correctly - because I use 
postfix with dovecot as LMTP and auth backend.
 


Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-16 Thread Aki Tuomi


> On 15/11/2022 21:17 EET Krisztián Szegi  wrote:
> 
>  
> "Michael Ströder" mich...@stroeder.com – 15 November 2022 15:00
> > On 11/15/22 13:45, Krisztián Szegi wrote:
> >> I'd like to report that non-binding auth to (Open)LDAP doesn't work
> >> if the latter hashes passwords with ARGON2.
> > Could you please elaborate why using LDAP bind is a problem for you?
> >  
> > Ciao, Michael.
> >  
> > 
>  
> Fair enough question!
>  
> I cannot specify bind_dn template due to mismatched mail addresses and user 
> DNs, and I thought that that would be suboptimal due to re-binding.
> I am a bit confused about how to optimize LDAP lookups now (static files not 
> option :), re-reading the docs it just made me question more things
> - auth_bind_dn cannot be given in my case, as a fixed starting point
> - auth_bind adds a temporary binding (using pass_filter)
> - can I use userdb prefetch? Docs say I cannot if I use bind with template, 
> but I am not using the latter. So the search for the user's dn during auth IS 
> the passdb lookup?

prefetch userdb does not in fact fetch anything. It mainly looks if passdb 
result contains userdb_* field(s) and shortcuts the lookup there.

> - assuming I am correct, I should give back stuff with passdb lookup: or do I?
>   - Must I give back userid an guid? 10-mail.conf has "vmail" for both, as 
> mail accounts don't have UNIX ones linked to them...
>   - same for home? There is no default I've given until userdb lookup. Just 
> specify a global mail_home with variables, and get on with life?
>   -if I should give back one, should I pass it with default_fields = 
> userdb_home (currently I specify it under default_fields:home in userdb 
> lookup as LDAP doesn't override home).
> 
> The docs are confusing around userdb. The main thing what is not clear that 
> they CAN override fields on a per-user basis, but must they provide them for 
> non-extra fields, when there are global settings for those?

mail_home, mail_gid, mail_uid etc. can be just templated out in config file, 
providing them in userdb reply is optional. 

If you don't need anything special for the userdb, it might already be enough 
to just have ldap passdb.

> 
> Thanks!
> 
> BTW, thanks for the great software all of you.
> Michael, I've come across some of your work, you have my respect!

Aki


Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-15 Thread Krisztián Szegi
"Michael Ströder" mich...@stroeder.com – 15 November 2022 15:00
> On 11/15/22 13:45, Krisztián Szegi wrote:
>> I'd like to report that non-binding auth to (Open)LDAP doesn't work
>> if the latter hashes passwords with ARGON2.
> Could you please elaborate why using LDAP bind is a problem for you?
>  
> Ciao, Michael.
>  
> 
 
Fair enough question!
 
I cannot specify bind_dn template due to mismatched mail addresses and user 
DNs, and I thought that that would be suboptimal due to re-binding.
I am a bit confused about how to optimize LDAP lookups now (static files not 
option :), re-reading the docs it just made me question more things
- auth_bind_dn cannot be given in my case, as a fixed starting point
- auth_bind adds a temporary binding (using pass_filter)
- can I use userdb prefetch? Docs say I cannot if I use bind with template, but 
I am not using the latter. So the search for the user's dn during auth IS the 
passdb lookup?
- assuming I am correct, I should give back stuff with passdb lookup: or do I?
  - Must I give back userid an guid? 10-mail.conf has "vmail" for both, as mail 
accounts don't have UNIX ones linked to them...
  - same for home? There is no default I've given until userdb lookup. Just 
specify a global mail_home with variables, and get on with life?
  -if I should give back one, should I pass it with default_fields = 
userdb_home (currently I specify it under default_fields:home in userdb lookup 
as LDAP doesn't override home).

The docs are confusing around userdb. The main thing what is not clear that 
they CAN override fields on a per-user basis, but must they provide them for 
non-extra fields, when there are global settings for those?

Thanks!

BTW, thanks for the great software all of you.
Michael, I've come across some of your work, you have my respect!

 

 


Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-15 Thread Michael Ströder

On 11/15/22 13:45, Krisztián Szegi wrote:

I'd like to report that non-binding auth to (Open)LDAP doesn't work
if the latter hashes passwords with ARGON2.

Could you please elaborate why using LDAP bind is a problem for you?

Ciao, Michael.



Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-15 Thread Krisztián Szegi
Sorry, I wanted to post from this alias, but From-Address isn't saved with my 
drafts :)
 
I failed to recognize during my patchwork that the verification function is the 
same for ARGON2I and -ID:
both call `verify_argon2`, which in turn calls `libsodium's 
crypto_pwhash_str_verify`.

In the new light this, there is no "harm" in my patch:
- If backend gives back "{ARGON2}...", dovecot verifies with the same call 
anyway, regardless of what subtype it actually is, i.e.: {ARGON2I} will work 
too.
- If dovecot generates the hash, the prefix will be the one set by the config's 
default hash, so for backwards comp., "{ARGON2ID}" could be used if someone 
wants that. Dovecot will succeed in verifying {ARGON2} generated by itself as 
well.
 
"Aki Tuomi" aki.tu...@open-xchange.com – 15 November 2022 13:55
> > On 15/11/2022 14:45 EET Krisztián Szegi  wrote:
> > 
> > 
> > Good day to all,
> >  
> > this is my first post to the mailing list!
> >  
> > I'd like to report that non-binding auth to (Open)LDAP doesn't work if the 
> > latter hashes passwords with ARGON2.
> >  
> > Although dovecot (I am using http://2.3.19.1) does support ARGON2 with 
> > libsodium, but it doesn't recoginize hashes beginning "{ARGON2}$argon2id$" 
> > stored (and hashed, using ppolicy module's hashCleartext) by OpenLDAP.
> >  
> > Now, I understand that ARGON2I, -D, and -ID are not compatible, but the 
> > ACTUAL algorithm is there between the two $.
> > Furthermore, I think dovecot is in the minority here, I haven't met any 
> > software that specifies the ARGON2 subtype between {}.
> > BTW, I haven't met any software that hashes passwords with ARGON2, but not 
> > with the ARGON2ID subtype (where libsodium is available, which also seems 
> > to be the standard here), as THAT is the recommended one anyway.
> > 
> > I patched the rpm in OpenSUSE repo to alias {ARGON2} to {ARGON2ID}:
> > https://build.opensuse.org/package/view_file/home:Samonitari:branches:openSUSE:Factory/dovecot23/dovecot-2.3.0-alias_ARGON2_to_ARGON2ID.patch
> >  
> > Could we get something like this (but maybe more correct) into the official 
> > source?
> > Maybe a config switch to alias it runtime?
> >  
> > Thanks for the attention:
> > Krisztián
> 
> Hi!
> 
> Thanks for your report. I think it makes sense, we'll see what we can do 
> about this.
> 
> Aki
> 
>

 


Re: bug: ARGON2 hash selection incompatible with LDAP

2022-11-15 Thread Aki Tuomi


> On 15/11/2022 14:45 EET Krisztián Szegi  wrote:
> 
>  
> Good day to all,
>  
> this is my first post to the mailing list!
>  
> I'd like to report that non-binding auth to (Open)LDAP doesn't work if the 
> latter hashes passwords with ARGON2.
>  
> Although dovecot (I am using http://2.3.19.1) does support ARGON2 with 
> libsodium, but it doesn't recoginize hashes beginning "{ARGON2}$argon2id$" 
> stored (and hashed, using ppolicy module's hashCleartext) by OpenLDAP.
>  
> Now, I understand that ARGON2I, -D, and -ID are not compatible, but the 
> ACTUAL algorithm is there between the two $.
> Furthermore, I think dovecot is in the minority here, I haven't met any 
> software that specifies the ARGON2 subtype between {}.
> BTW, I haven't met any software that hashes passwords with ARGON2, but not 
> with the ARGON2ID subtype (where libsodium is available, which also seems to 
> be the standard here), as THAT is the recommended one anyway.
> 
> I patched the rpm in OpenSUSE repo to alias {ARGON2} to {ARGON2ID}:
> https://build.opensuse.org/package/view_file/home:Samonitari:branches:openSUSE:Factory/dovecot23/dovecot-2.3.0-alias_ARGON2_to_ARGON2ID.patch
>  
> Could we get something like this (but maybe more correct) into the official 
> source?
> Maybe a config switch to alias it runtime?
>  
> Thanks for the attention:
> Krisztián

Hi!

Thanks for your report. I think it makes sense, we'll see what we can do about 
this.

Aki


bug: ARGON2 hash selection incompatible with LDAP

2022-11-15 Thread Krisztián Szegi
Good day to all,
 
this is my first post to the mailing list!
 
I'd like to report that non-binding auth to (Open)LDAP doesn't work if the 
latter hashes passwords with ARGON2.
 
Although dovecot (I am using http://2.3.19.1) does support ARGON2 with 
libsodium, but it doesn't recoginize hashes beginning "{ARGON2}$argon2id$" 
stored (and hashed, using ppolicy module's hashCleartext) by OpenLDAP.
 
Now, I understand that ARGON2I, -D, and -ID are not compatible, but the ACTUAL 
algorithm is there between the two $.
Furthermore, I think dovecot is in the minority here, I haven't met any 
software that specifies the ARGON2 subtype between {}.
BTW, I haven't met any software that hashes passwords with ARGON2, but not with 
the ARGON2ID subtype (where libsodium is available, which also seems to be the 
standard here), as THAT is the recommended one anyway.

I patched the rpm in OpenSUSE repo to alias {ARGON2} to {ARGON2ID}:
https://build.opensuse.org/package/view_file/home:Samonitari:branches:openSUSE:Factory/dovecot23/dovecot-2.3.0-alias_ARGON2_to_ARGON2ID.patch
 
Could we get something like this (but maybe more correct) into the official 
source?
Maybe a config switch to alias it runtime?
 
Thanks for the attention:
Krisztián