Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms000604020701070406090000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Howard Chu wrote:
> Michael Str=F6der wrote:
>> hyc(a)symas.com wrote:
>>> Michael Str=F6der wrote:
>>>> Howard Chu wrote:
>>>>> The text also states
>>>>> The practice of storing hashed passwords in userPassword viol=
ates
>>>>> Standard Track (RFC 4519) schema specifications and may hinde=
r
>>>>> interoperability.
>>>>
>>>> In practice we all live very well with this for years. That's least =
of a
>>>> problem today.
>>>>
>>>>> Anyone building operational procedures on something that violates t=
he specs
>>>>> was asking for trouble. Users should be using ldappasswd, that's wh=
at
>>>>> it's for.
>>>>
>>>> ???
>>>>
>>>> ldappasswd writes a hashed password to - tataa - attribute 'userPass=
word'.
>>>> I cannot see how this is different from using ldapadd/ldapmodify.
>>>
>>> Wrong, ldappasswd sends a PasswordModify exop to a server. The server=
may
>>> implement that exop in any implementation-specific manner, and there =
is no
>>> guarantee that the password a server uses is ever instantiated in any=
LDAP
>>> entry. There is no guarantee that setting a userPassword attribute us=
ing
>>> ldapadd/ldapmodify will ever do anything useful for any given LDAP us=
er.
>>
>> You're arguing based on what a LDAP server could do. I'm arguing based=
on what
>> OpenLDAP and other server implementations are doing for years.
>=20
> ActiveDirectory is an obvious example invalidating your argument.
Does MS AD support RFC 3062? AFAIK W2K3 doesn't.
I don't currently have the possibility to check with most recent W2K8R2 t=
hough.
Anyway that's not relevant here either. We're talking about how OpenLDAP
stores and checks the passwords since over a decade.
Violating Standard Track (RFC 4519) schema specifications could be avoide=
d by
implementing RFC 3112. But this also never happened.
> Don't fix what isn't broken.
With this argument you can immediately stop any progress.
Maybe also a valuable statement by the OpenLDAP chief architect.
Ciao, Michael.
--------------ms000604020701070406090000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC
BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx
MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy
IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl
cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB
BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov
L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq
hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj
/E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd
dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH
SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ
AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63
TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT
QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ
R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv
n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy
D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx
IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1
cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTIxMTU0N1owIwYJKoZIhvcNAQkEMRYE
FPftjo2JfwDdzUByvPPFBJpEMBd4MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n
IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG
CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE
ggEAqWLrqBEmQFwdUWzw3ZuQR0bnPzvAMZBb81cTmCzguvREDKdmO9vYvDVzoB/AhnnE6cE+
NYlO7uQBg7AiQSq++LoQ93tYsIjoZM44xiOxx8k+tAkhTUGEK4yJ9G86ptDRa/VSK25vC/Jg
dfza7znhUF2210scAyjiG46RSRG/otIAhuMRjRKtvbC5jD5luJeJxePFpWR/V7+qKWmVvyJU
mIGY90XdKmhY3b8XNWecfghap8V4NVNWzLuNxwH6vW8ym8+W4eZ/EsMsJ7+ht7HqgE71hjtj
QtDfdcEGGww1Ch0tGj7HbynRm7pf2airOQ3j8GxMwFkkq/If8+4jqrNC1gAAAAAAAA==
--------------ms000604020701070406090000--
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com
--On Tuesday, May 29, 2012 8:38 PM +0000 michael(a)stroeder.com wrote:
> Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you
> want. (But you shouldn't wonder why there's no active OpenLDAP community.)
Comments like this weaken any point you are trying to make, serve no
purpose, and are obnoxious. Your emails would be better served without
them.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> Michael Ströder wrote:
>>> Howard Chu wrote:
>>>> The text also states
>>>> The practice of storing hashed passwords in userPassword violates
>>>> Standard Track (RFC 4519) schema specifications and may hinder
>>>> interoperability.
>>>
>>> In practice we all live very well with this for years. That's least of a
>>> problem today.
>>>
>>>> Anyone building operational procedures on something that violates the specs
>>>> was asking for trouble. Users should be using ldappasswd, that's what it's for.
>>>
>>> ???
>>>
>>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'.
>>> I cannot see how this is different from using ldapadd/ldapmodify.
>>
>> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may
>> implement that exop in any implementation-specific manner, and there is no
>> guarantee that the password a server uses is ever instantiated in any LDAP
>> entry. There is no guarantee that setting a userPassword attribute using
>> ldapadd/ldapmodify will ever do anything useful for any given LDAP user.
>
> You're arguing based on what a LDAP server could do. I'm arguing based on what
> OpenLDAP and other server implementations are doing for years.
ActiveDirectory is an obvious example invalidating your argument.
> None of what you said in this thread is a real argument against adding SHA-2
> hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out.
At present there is no need to change anything in the core since SHA-2 support
can be dynamically loaded. Don't fix what isn't broken.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> The text also states
>>> The practice of storing hashed passwords in userPassword violates
>>> Standard Track (RFC 4519) schema specifications and may hinder
>>> interoperability.
>>
>> In practice we all live very well with this for years. That's least of a
>> problem today.
>>
>>> Anyone building operational procedures on something that violates the specs
>>> was asking for trouble. Users should be using ldappasswd, that's what it's for.
>>
>> ???
>>
>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'.
>> I cannot see how this is different from using ldapadd/ldapmodify.
>
> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may
> implement that exop in any implementation-specific manner, and there is no
> guarantee that the password a server uses is ever instantiated in any LDAP
> entry. There is no guarantee that setting a userPassword attribute using
> ldapadd/ldapmodify will ever do anything useful for any given LDAP user.
You're arguing based on what a LDAP server could do. I'm arguing based on what
OpenLDAP and other server implementations are doing for years.
None of what you said in this thread is a real argument against adding SHA-2
hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out.
Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you want.
(But you shouldn't wonder why there's no active OpenLDAP community.)
Ciao, Michael.
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com
Michael Ströder wrote:
> Howard Chu wrote:
>> The text also states
>> The practice of storing hashed passwords in userPassword violates
>> Standard Track (RFC 4519) schema specifications and may hinder
>> interoperability.
>
> In practice we all live very well with this for years. That's least of a
> problem today.
>
>> Anyone building operational procedures on something that violates the specs
>> was asking for trouble. Users should be using ldappasswd, that's what it's for.
>
> ???
>
> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'.
> I cannot see how this is different from using ldapadd/ldapmodify.
Wrong, ldappasswd sends a PasswordModify exop to a server. The server may
implement that exop in any implementation-specific manner, and there is no
guarantee that the password a server uses is ever instantiated in any LDAP
entry. There is no guarantee that setting a userPassword attribute using
ldapadd/ldapmodify will ever do anything useful for any given LDAP user.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms050402080405010103060108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Howard Chu wrote:
> The text also states
> The practice of storing hashed passwords in userPassword violates
> Standard Track (RFC 4519) schema specifications and may hinder
> interoperability.
In practice we all live very well with this for years. That's least of a
problem today.
> Anyone building operational procedures on something that violates the s=
pecs
> was asking for trouble. Users should be using ldappasswd, that's what i=
t's for.
???
ldappasswd writes a hashed password to - tataa - attribute 'userPassword'=
=2E
I cannot see how this is different from using ldapadd/ldapmodify.
So what are you really trying to say?
Ciao, Michael.
--------------ms050402080405010103060108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC
BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx
MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy
IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl
cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB
BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov
L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq
hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj
/E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd
dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH
SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ
AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63
TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT
QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ
R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv
n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy
D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx
IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1
cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTE4MTEyMVowIwYJKoZIhvcNAQkEMRYE
FMxpg47lo/Kju6s3IV/LCMAeyzViMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n
IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG
CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE
ggEAPDeuZINq0dhCIixcpzDn15b8usj8fAjOx/IOUdH3GEfMwNcC7Qi4lEDwuT1hvriqLT9x
RTO4CcPCm5GZ2A8MWqayf+oRZtfZmU6ueLNPS08D4fMIkdU5DScFGmSFajm/qVfP8V4iwWur
xn4xtYjEXY6SqD2vZK0rYGrr9KS72pNunNEXzUkI6SmGVDp5Q9463FkoBQj9DFYrLSe5iBPO
CVNZlHsnTfWvW3Cm4SP7x2VFoqpT6snisrYWv3hcJjSinsBCEnW+qwAcuCpuByMWA/hFr9vj
OBz3Y1W7obMI6DUxdBq4ECdDWTDoqLsCfEJGLeoq1oQ9n5r2UNDSPnPJ9QAAAAAAAA==
--------------ms050402080405010103060108--
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> Why should X user ever need to run this tool to generate a value?
>
>>From slappasswd(8):
>
> DESCRIPTION
> Slappasswd is used to generate an userPassword value suitable
> for use with ldapmodify(1), slapd.conf(5) rootpw configuration
> directive or the slapd-config(5) olcRootPW configuration directive.
>
> Do you want to restrict this text regarding ldapmodify(1) only for the cases
> that the slappasswd user has also write access to back-config?
We could probably delete that ldapmodify(1) reference. Technically it has
always been wrong, since there's never been any guarantee that an LDAP user's
password was ever stored in any user-accessible attribute.
> Of course your are the OpenLDAP boss. You can change everything to make it
> work for you. But it breaks existing operational procedures for other people.
The text also states
The practice of storing hashed passwords in userPassword violates
Standard Track (RFC 4519) schema specifications and may hinder
interoperability.
Anyone building operational procedures on something that violates the specs
was asking for trouble. Users should be using ldappasswd, that's what it's for.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com
--On Tuesday, May 29, 2012 5:49 PM +0000 michael(a)stroeder.com wrote:
> hyc(a)symas.com wrote:
>> Why should X user ever need to run this tool to generate a value?
>
> From slappasswd(8):
>
> DESCRIPTION
> Slappasswd is used to generate an userPassword value suitable
> for use with ldapmodify(1), slapd.conf(5) rootpw configuration
> directive or the slapd-config(5) olcRootPW configuration directive.
>
> Do you want to restrict this text regarding ldapmodify(1) only for the
> cases that the slappasswd user has also write access to back-config?
The tool has allowed the ability to generate password values for years. It
is not uncommon to use it to do just that. I've often used it to generate
base-64 encoded SSHA values to push into LDIF I will be writing to the
server via ldapmodify. That should not require access to
cn=config/slapd.conf.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Why should X user ever need to run this tool to generate a value?
>From slappasswd(8):
DESCRIPTION
Slappasswd is used to generate an userPassword value suitable
for use with ldapmodify(1), slapd.conf(5) rootpw configuration
directive or the slapd-config(5) olcRootPW configuration directive.
Do you want to restrict this text regarding ldapmodify(1) only for the cases
that the slappasswd user has also write access to back-config?
Of course your are the OpenLDAP boss. You can change everything to make it
work for you. But it breaks existing operational procedures for other people.
Ciao, Michael.
11 years, 4 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
Howard Chu wrote:
> michael(a)stroeder.com wrote:
>> Doesn't this ask for fully integrating SHA-2 password support into
>> libraries/liblutil/passwd.c?
>
> Clearly you haven't thought this through.
Maybe.
But one question:
Why is SHA-1 in the core and SHA-2 isn't?
IMO that's just an arbitrary choice.
> No, because that doesn't solve the problem of how to use other contrib passwd
> modules.
If you come up with another overall solution to avoid reading the config when
using slappasswd I'm of course fine with that too.
Ciao, Michael.
11 years, 4 months