[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes

To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
From: michael@stroeder.com
Date: Tue, 29 May 2012 21:16:25 GMT
Auto-submitted: auto-generated (OpenLDAP-ITS)
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@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--
Prev by Date: Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
Next by Date: Re: (ITS#7282) Invalid Regex in Documentation
Index(es):
- Chronological
- Thread