[389-devel] Re: Close of 48241, let's not support bad crypto
On Mon, 2016-10-03 at 21:42 -0600, Rich Megginson wrote: > On 10/03/2016 09:34 PM, William Brown wrote: > > On Mon, 2016-10-03 at 21:26 -0600, Rich Megginson wrote: > >> On 10/03/2016 08:58 PM, William Brown wrote: > >>> Hi, > >>> > >>> I want to close #48241 [0] as "wontfix". I do not believe that it's > >>> appropriate to provide SHA3 as a password hashing algorithm. > >>> > >>> The SHA3 algorithm is designed to be fast, and cryptographically secure. > >>> It's target usage is for signatures and verification of these in a rapid > >>> manner. > >>> > >>> The fact that this algorithm is fast, and could be implemented in > >>> hardware is the reason it's not appropriate for password hashing. > >>> Passwords should be hashed with a slow algorithm, and in the future, an > >>> algorithm that is CPU and memory hard. This means that in the (hopefully > >>> unlikely) case of password hash leak or dump from ldap that the attacker > >>> must spend a huge amount of resources to brute force or attack any > >>> password that we are storing in the system. > >> If the crypto/security team is ok with not supporting SHA3 for > >> passwords, works for me. > > Who would be a point of contact to ask this? > > Nikos Mavrogiannopoulos The response I received was unanimous and against SHA3 for password storage. I have closed the issue as a result, and will not pursue an implementation of this. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Close of 48241, let's not support bad crypto
On 10/03/2016 09:34 PM, William Brown wrote: On Mon, 2016-10-03 at 21:26 -0600, Rich Megginson wrote: On 10/03/2016 08:58 PM, William Brown wrote: Hi, I want to close #48241 [0] as "wontfix". I do not believe that it's appropriate to provide SHA3 as a password hashing algorithm. The SHA3 algorithm is designed to be fast, and cryptographically secure. It's target usage is for signatures and verification of these in a rapid manner. The fact that this algorithm is fast, and could be implemented in hardware is the reason it's not appropriate for password hashing. Passwords should be hashed with a slow algorithm, and in the future, an algorithm that is CPU and memory hard. This means that in the (hopefully unlikely) case of password hash leak or dump from ldap that the attacker must spend a huge amount of resources to brute force or attack any password that we are storing in the system. If the crypto/security team is ok with not supporting SHA3 for passwords, works for me. Who would be a point of contact to ask this? Nikos Mavrogiannopoulos As a result, I would like to make this ticket "wontfix" with an explanation of why. I think it's better for us to pursue #397 [1]. PBKDF2 is a CPU hard algorithm, and scrypt is both CPU and Memory hard. These are the direction we should be going (asap). Thanks, [0] https://fedorahosted.org/389/ticket/48241 [1] https://fedorahosted.org/389/ticket/397 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Close of 48241, let's not support bad crypto
On Mon, 2016-10-03 at 21:26 -0600, Rich Megginson wrote: > On 10/03/2016 08:58 PM, William Brown wrote: > > Hi, > > > > I want to close #48241 [0] as "wontfix". I do not believe that it's > > appropriate to provide SHA3 as a password hashing algorithm. > > > > The SHA3 algorithm is designed to be fast, and cryptographically secure. > > It's target usage is for signatures and verification of these in a rapid > > manner. > > > > The fact that this algorithm is fast, and could be implemented in > > hardware is the reason it's not appropriate for password hashing. > > Passwords should be hashed with a slow algorithm, and in the future, an > > algorithm that is CPU and memory hard. This means that in the (hopefully > > unlikely) case of password hash leak or dump from ldap that the attacker > > must spend a huge amount of resources to brute force or attack any > > password that we are storing in the system. > > If the crypto/security team is ok with not supporting SHA3 for > passwords, works for me. Who would be a point of contact to ask this? > > > > > As a result, I would like to make this ticket "wontfix" with an > > explanation of why. I think it's better for us to pursue #397 [1]. > > PBKDF2 is a CPU hard algorithm, and scrypt is both CPU and Memory hard. > > These are the direction we should be going (asap). > > > > Thanks, > > > > > > [0] https://fedorahosted.org/389/ticket/48241 > > [1] https://fedorahosted.org/389/ticket/397 > > > > > > > > ___ > > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
[389-devel] Re: Close of 48241, let's not support bad crypto
On 10/03/2016 08:58 PM, William Brown wrote: Hi, I want to close #48241 [0] as "wontfix". I do not believe that it's appropriate to provide SHA3 as a password hashing algorithm. The SHA3 algorithm is designed to be fast, and cryptographically secure. It's target usage is for signatures and verification of these in a rapid manner. The fact that this algorithm is fast, and could be implemented in hardware is the reason it's not appropriate for password hashing. Passwords should be hashed with a slow algorithm, and in the future, an algorithm that is CPU and memory hard. This means that in the (hopefully unlikely) case of password hash leak or dump from ldap that the attacker must spend a huge amount of resources to brute force or attack any password that we are storing in the system. If the crypto/security team is ok with not supporting SHA3 for passwords, works for me. As a result, I would like to make this ticket "wontfix" with an explanation of why. I think it's better for us to pursue #397 [1]. PBKDF2 is a CPU hard algorithm, and scrypt is both CPU and Memory hard. These are the direction we should be going (asap). Thanks, [0] https://fedorahosted.org/389/ticket/48241 [1] https://fedorahosted.org/389/ticket/397 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
