vivekk9
asked on
How are passwords stored in Active Directory
I would like to know what hash algorithm and encryption is used to store passwords on Active Directory 2008. Also is "salt" used? If yes, then what is the salt's length?
-Vivek
-Vivek
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
the worst is MD4 which is used for NTLM.
anyway these are usually brute forced and modern computers have more than enough power to do that quite efficiently. try johntheripper, hashcat and the likes.
using hashes that are not reversible for passwords hardly brings extra security in most cases : either you cannot do challenge-response and have to move around the actual password on the network, or you decide to do challenge-response and the hash incidentally became the password. actually it is quite a misunderstanding to hash passwords in a networked environment for extra security and unfortunately most security professionals are too focused on how big their salts and keys are to understand that.
additionally the windows kerberos implementation is vulnerable to stolen tokens and other bugs and design flows make it seldom useful for an attacker to bother grabbing the password.
what is your actual concern ?
anyway these are usually brute forced and modern computers have more than enough power to do that quite efficiently. try johntheripper, hashcat and the likes.
using hashes that are not reversible for passwords hardly brings extra security in most cases : either you cannot do challenge-response and have to move around the actual password on the network, or you decide to do challenge-response and the hash incidentally became the password. actually it is quite a misunderstanding to hash passwords in a networked environment for extra security and unfortunately most security professionals are too focused on how big their salts and keys are to understand that.
additionally the windows kerberos implementation is vulnerable to stolen tokens and other bugs and design flows make it seldom useful for an attacker to bother grabbing the password.
what is your actual concern ?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
AD does NOT use a salt at all. However, for an OS (such as Linux, UNIX, and MacOS) that does use them, you can't just assume an it would just use a single salt for all of its passwords. That would defeat the purpose of them. The salt for each password differs, so unless you have access to a DB of hashed passwords, you're not going to know the salt for any password.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'd look at what John linked - it seems there is the best info. For example, you can find that it depends on what password hsah we are talking about (ntlm/ntlmv2/kerberos) and it also depends on what OS your DC uses. Salt is being used for kerberos hashes, when your DC is 2008 or newer.
I do security investigations. This is how the password is stored in AD (except for NTLM meantioned in another post which is event weaker)
It is not salted but the database is encrypted. We are not talking about transport, we are talking about stored values
It is not salted but the database is encrypted. We are not talking about transport, we are talking about stored values
So the info of the MS MVP is wrong?
From one of my password audits against AD 2012 R2 (removed sensitive passwords)
f56a8399599f1be040128b1dd9 623c29 P@$$w0rd
e5c00059679e6acc505b63acde 9901f7 P@$$w0rd!@#
40739aa18503c6fcf8c7e9d434 af2361 P@$$w0rd1
99d0f1cf2c2a3a46d7bc5db23c 9bfe54 P@$$w0rd123
aa3c4816f9090404304ce1b6d8 170426 P@$$w0rd1234
5b020e0276640055938e6e308d e351de P@$$w0rd12345
c50fb587f8b24de54a07879d50 344eee P@$$w0rd123456
891ad43f55fdabba0459329916 308214 P@$$w0rd1234567
dceeee34db21ea54de36c6a0b8 8c9843 P@$$w0rd2
b0850ab32b354b1db0eaa0845c 972c0e P@$$w0rd3
df40d5417de168428ea5c2052c 9faa81 P@$$word123
ef48e97f8e862f91bfd87d17a5 03d409 P@$$word123!@#
eaf6bdbb1134497bd8fdca4463 4cc817 P@$$word1234
1b7c1e2b99987d13f7f37f36a0 7e36ed P@$$word12345
72cafec0c6fd2a7b66d7092544 25c9c8 P@$$word123456
e77c7d490ca7e01ec033b6ebf8 7c6003 P@$$word1234567
7e4026687ad6be0a6d736f1fab c8bc16 P@55w0rd
29aa6786f9b94cfbe439934e54 2054ea P@55w0rd1
34d639471710eafd99bcc4438f fde6a4 P@55w0rd123
0d05cd9c8ded97e26a6b35ef8c 7fc08e P@55w0rd123!
eeaac7a9a4e548f2b5f5772c34 ad2463 P@55word1
e19ccf75ee54e06b06a5907af1 3cef42 P@ssw0rd
07c19e98f0ee02e10fce023c82 d43c4d P@ssw0rd12
264726470e85a666b4852a5fc9 91e27d P@ssw0rd12#
89551acff8895768e489bb3054 af94fd P@ssw0rd123
7dfa0531d73101ca080c7379a9 bff1c7 P@ssw0rd123!
16936944fa1c4964a8a6e7d2dd c3c432 P@ssw0rd1234
25cb75fb3f857de4bb08feddca 639d2d P@ssw0rd12345
ead0cc57ddaae50d876b7dd638 6fa9c7 P@ssword1
5a3251184709dfbedb9588b9ec 4e7693 p@ssword1
cb8a428385459087a76793010d 60f5dc P@ssword123
33e17aa21ccc6ab0e6ff30eecb 918dfb P@ssword1234
af112951ba8629d25a6a444175 79283d P@ssword12345
f7ae84a7918bd587cb13475507 124dc3 P@ssword123456
4aa173731c3cacfad8e3e42f19 b77d33 P@ssword2015
3b76ab014d58cf6085fff2ff52 7daad9 P@ssword456
e78cff556c1607dd3025c64ddd ededca PA$$w0rd
92937945b518814341de3f7265 00d4ff Pa$$w0rd
de4f0a21c551b899b9a68e26d3 5a25a3 Pa55w0rd1
407a54044d00cc79f9d8cfa7c4 ce2818 Pa55word1
8432ec4c4f9b9ce96b73a6451a 1d9dcc Pass123
6364271e1a2232e42ecb3406ee b8f823 Pass1234
5858d47a41e40b40f294b3100b ea611f Passw0rd1
077cccc23f8ab7031726a3b70c 694a49 Passw0rd123
a0876282229e5f193f21127395 b185f0 Password!@#
2d450bc49b158d89cc6ec49db4 7ba095 Password!1
63245e61ad75fbc0b9360b4e38 0d83d8 Password#
f14eee53c480f0063acc5ba8f0 26457b password#1
15eac911fa04058ebdf0e83d2a 53433c Password#1
5c07d711b4111280aa32ff456e d24557 Password#2
627a55d9b030f24af2c8f1a73a 8b079a Password@01
5f74e9be61c3420294d0bf54fd 3b5b13 Password@02
64fbae31cc352fc26af97cbdef 151e03 Password@1
6be4471ee4d67ac1a121345e2f 10e721 Password@12
a29f7623fd11550def0192de92 46f46b Password@123
a0989207854b684f07b5b6fe68 169a35 Password@1234
c972a845781ba9c671425c7194 3bed24 Password@4
d1daf12d1181b4b49c633a343e 26f144 Password0
a57a4481d61c607420beab0aac ed08e2 Password001
f0bcb486973a135f156d70cac3 73b0ee Password007
7100a909c7ff05b266af3c42ec 058c33 Password01
a65e89a846c4f2d9d4618f8cbe 882185 Password0123
632b06c75304ab6d074b8ed8b7 3cf98b Password02
dc92d04be474bbed6eb2b896ac d7ee35 Password03
307bbcfc3b4e38e066b46fa377 893d4d Password06
47a3f21602c0742e9bf5a4df54 82132c Password0606
049df081e6e6af6b5a475d0bbd 23bbfd Password07
06a6066abf57fd751781aae33c d99be5 Password08
56c9696d86ee10914bcdfa34c4 96c590 Password09
64f12cddaa88057e06a81b54e7 3b949b Password1
37f1498f7b42b7452a0eeafa6c a74d8c Password1#
b23b63f32e102c28c256fd0cf7 728456 Password1*
fcb63becd811c9a6fd96619395 63b1ba Password1.
12f73b3b10b9171adcc0ea79f8 b26d8c Password10
2461090ab3b0f182c709bfce37 798807 Password100
249d4e170416ddc78c200a021e 7fa797 Password11
298cf6b234feebe0ee26bf24e3 96670c Password111
dc784e3fc5ce2fec8db6563db3 1ce362 Password1114
7dc21a3e0ac3abd0392a6d7d60 9f6a82 Password112
cac3a73c02d89fd62392800815 e0f425 Password12
3f482230f2df78212886368286 d40399 Password12#
58a478135a93ac3bf058a5ea0e 8fdb71 Password123
2b576acbe6bcfda7294d6bd180 41b8fe Password123!
906cc3291a7fb123ca964eeeca 0aff07 Password123!@#
7a1762d79c21e263eae080fadb b03429 Password123#
b490b475e987909ae9bd83a65a a94665 Password123$
8c3efc486704d2ee71eebe71af 14d86c Password1234
9bff06fe611486579fb7403789 0fda96 Password12345
1bc3af33d22c1c2baec10a32db 22c72d Password12345!
5997fb1b40d4e25698405265e5 b55ba2 Password12345#
e648ec21f9a48072f1f8a33efb 230996 Password12345@
ffce0c45c18cfdbb3ec16289a9 d704da Password123456
fb377972485236757eea4ce99c 35d20d Password1234567
4e4271514b43023eaf7d3b292b dde8b1 Password123456789
17bd91defd0d2fe234239a5bb9 0a9595 Password1234567890
451f66efa5750f683778851d81 3bf027 Password124
a020979c7971441a276ffb3013 8bea45 Password126
fc0423f02741cadc6cfb6bc18d 342128 Password13
ff56768db62329db0661379316 b720c6 Password14
0affe6c2d59f73a032aababa20 a333c8 Password15
cb80a3c8eddb6c4d60ccd5b8ba d62894 Password16
d59287f790dcbcf24f1bbd8c47 03bd54 Password17
d59287f790dcbcf24f1bbd8c47 03bd54 Password17
5dc87c256056458c42ba91e419 11b3b0 Password18
1fd2cb0e346488e8e517fb49c2 bef545 Password19
11464392042adfcef422103803 3e654a Password1970
28ada497570d2b24513db61f02 a4351a Password1982
c39f2beb3d2ec06a62cb887fb3 91dee0 Password2
812792a1f13bb10964ed1dfeac 78c64b Password20
ad39815b87dd7209aa905b6292 d2079b Password2011
a0aba9fecab98903cb8f421374 9f9749 Password2012
6a1fea9fe91a8126a8deacf17a ba4e86 Password2013
e79b80db674a601b9c1f84a3b3 980402 Password2014
48f0b4e30da8707c9c51f32c32 17625b Password201407
d0f8c1bf04159e4fccae47ace7 d6f309 Password2015
b3f1321e7a62f72221cc9f3593 26e10f Password2016
c93bb2701d5078fd9621c59e90 399410 Password2026
628ea7b647595b76ae9ea3aa16 7a6659 Password21
50857c4a53ce7a5c3f854aa230 ea2a71 Password22
bad39df9a50f0d2c01a9ca3904 ea950a Password222
7369650348e40749ff5d9f67cd d420eb Password2233
a10d645982bdd5ae90e008265f 6badcd Password23
a875e6f6e364d6ebd2bed77eff 1b83e5 Password234
93e31760a8aff925da8c7cd2d8 eedfa9 Password2345
d6953eca472e7f3101d5dfba60 b92f46 Password24
c88fffd061ebc66fa56934dfaf c4d55f Password25
1f4bd5fead373f8dfdca2190a4 6c0e21 Password26
b6c201105d9dc98f5d38feede5 7eb085 Password27
9ea8454fa1b7df608139a76ee7 743445 Password28
d23e52cfc48f9d5672047d618d c67bce Password29
c4b0e1b10c7ce2c4723b4e2407 ef81a2 Password3
9666aab25aa416c97b96436e2f 2f2ddd Password30
be7a6b5d44ea33aaaea3917e7c ca271f Password31
da276f8c03ac80ffa69a3464b3 c8cddf Password32
44123b44fe70733ecf12b037c6 feaea6 Password32!
f3118544a831e728781d780cfd b9c1fa Password321
581908aa84594deac95b74d941 e05ff1 Password33
fbd27fd5548d3d6c7ce23f42db 789dd7 Password333
f56c0bf4a31defd36b0a8b88c7 75a7de Password34
70f17a336be61ae1ca30327a80 72ae56 Password345
570d2c38007cfa19ae70e4c270 794a56 Password3456
36f558389c1dacc5068d91b0f5 e4a03c Password37
7247e8d4387e76996ff3f18a34 316fdd Password4
f49440f845ea7c73bc906f29f8 263eda Password4321!
a6f05e37b3fa335e5a086d5346 7099c5 Password45
1e3311cce313d91f44b0913be6 67f36e Password456
34082f4e41427f816fe4835a6b 5ae6fd Password4567
a738f92b3c08b424ec2d99589a 9cce60 Password5
eab6799dcba237f8573e0ca69c ca074e Password54321
bd992c4f35791325f570221644 863d2e Password56
5d140ff0aba86ca9f61c20f9fb 7a67ac Password567
e6be9799eed26d784b9ecbe796 a5847e Password5678
499108ff7eeea55a4765f1c576 65f840 Password6
ea0519192f0f2f5823436551ed e8b68f Password6666
c2e1dde3a073af107dfd02b439 c7bf45 Password67
18a7e4389b63da6c1d7bed1298 32a489 Password6789
8fd992dd15ca326310ca8471de 1289dc Password7
a905669d12e2d2f40f215f1803 9ec435 Password73
5526f7ce84cfed2306fbe09733 62ca83 Password753
fe63557e5f6f26e8bf4fe2937e 329a35 Password76
0454acca4cf219ea7b27e5bcc6 42d398 Password78
5a03a175b652e03d23253f76f4 ce9422 Password786
f503c6b0d2e77c83008d56fa4d e6ae9f Password789
4636190bde3bb52ad2d29ca378 4cb579 Password8
a85b16b65dae336df620c567f2 4d74d2 Password852
74c6b434b4b0017eca03f81274 b9af3b Password86
a5be3c11831bddc88f6d751761 5f3d45 Password9
31c6c91338c60283337eab8226 48ce6e Password90
f56a8399599f1be040128b1dd9
e5c00059679e6acc505b63acde
40739aa18503c6fcf8c7e9d434
99d0f1cf2c2a3a46d7bc5db23c
aa3c4816f9090404304ce1b6d8
5b020e0276640055938e6e308d
c50fb587f8b24de54a07879d50
891ad43f55fdabba0459329916
dceeee34db21ea54de36c6a0b8
b0850ab32b354b1db0eaa0845c
df40d5417de168428ea5c2052c
ef48e97f8e862f91bfd87d17a5
eaf6bdbb1134497bd8fdca4463
1b7c1e2b99987d13f7f37f36a0
72cafec0c6fd2a7b66d7092544
e77c7d490ca7e01ec033b6ebf8
7e4026687ad6be0a6d736f1fab
29aa6786f9b94cfbe439934e54
34d639471710eafd99bcc4438f
0d05cd9c8ded97e26a6b35ef8c
eeaac7a9a4e548f2b5f5772c34
e19ccf75ee54e06b06a5907af1
07c19e98f0ee02e10fce023c82
264726470e85a666b4852a5fc9
89551acff8895768e489bb3054
7dfa0531d73101ca080c7379a9
16936944fa1c4964a8a6e7d2dd
25cb75fb3f857de4bb08feddca
ead0cc57ddaae50d876b7dd638
5a3251184709dfbedb9588b9ec
cb8a428385459087a76793010d
33e17aa21ccc6ab0e6ff30eecb
af112951ba8629d25a6a444175
f7ae84a7918bd587cb13475507
4aa173731c3cacfad8e3e42f19
3b76ab014d58cf6085fff2ff52
e78cff556c1607dd3025c64ddd
92937945b518814341de3f7265
de4f0a21c551b899b9a68e26d3
407a54044d00cc79f9d8cfa7c4
8432ec4c4f9b9ce96b73a6451a
6364271e1a2232e42ecb3406ee
5858d47a41e40b40f294b3100b
077cccc23f8ab7031726a3b70c
a0876282229e5f193f21127395
2d450bc49b158d89cc6ec49db4
63245e61ad75fbc0b9360b4e38
f14eee53c480f0063acc5ba8f0
15eac911fa04058ebdf0e83d2a
5c07d711b4111280aa32ff456e
627a55d9b030f24af2c8f1a73a
5f74e9be61c3420294d0bf54fd
64fbae31cc352fc26af97cbdef
6be4471ee4d67ac1a121345e2f
a29f7623fd11550def0192de92
a0989207854b684f07b5b6fe68
c972a845781ba9c671425c7194
d1daf12d1181b4b49c633a343e
a57a4481d61c607420beab0aac
f0bcb486973a135f156d70cac3
7100a909c7ff05b266af3c42ec
a65e89a846c4f2d9d4618f8cbe
632b06c75304ab6d074b8ed8b7
dc92d04be474bbed6eb2b896ac
307bbcfc3b4e38e066b46fa377
47a3f21602c0742e9bf5a4df54
049df081e6e6af6b5a475d0bbd
06a6066abf57fd751781aae33c
56c9696d86ee10914bcdfa34c4
64f12cddaa88057e06a81b54e7
37f1498f7b42b7452a0eeafa6c
b23b63f32e102c28c256fd0cf7
fcb63becd811c9a6fd96619395
12f73b3b10b9171adcc0ea79f8
2461090ab3b0f182c709bfce37
249d4e170416ddc78c200a021e
298cf6b234feebe0ee26bf24e3
dc784e3fc5ce2fec8db6563db3
7dc21a3e0ac3abd0392a6d7d60
cac3a73c02d89fd62392800815
3f482230f2df78212886368286
58a478135a93ac3bf058a5ea0e
2b576acbe6bcfda7294d6bd180
906cc3291a7fb123ca964eeeca
7a1762d79c21e263eae080fadb
b490b475e987909ae9bd83a65a
8c3efc486704d2ee71eebe71af
9bff06fe611486579fb7403789
1bc3af33d22c1c2baec10a32db
5997fb1b40d4e25698405265e5
e648ec21f9a48072f1f8a33efb
ffce0c45c18cfdbb3ec16289a9
fb377972485236757eea4ce99c
4e4271514b43023eaf7d3b292b
17bd91defd0d2fe234239a5bb9
451f66efa5750f683778851d81
a020979c7971441a276ffb3013
fc0423f02741cadc6cfb6bc18d
ff56768db62329db0661379316
0affe6c2d59f73a032aababa20
cb80a3c8eddb6c4d60ccd5b8ba
d59287f790dcbcf24f1bbd8c47
d59287f790dcbcf24f1bbd8c47
5dc87c256056458c42ba91e419
1fd2cb0e346488e8e517fb49c2
11464392042adfcef422103803
28ada497570d2b24513db61f02
c39f2beb3d2ec06a62cb887fb3
812792a1f13bb10964ed1dfeac
ad39815b87dd7209aa905b6292
a0aba9fecab98903cb8f421374
6a1fea9fe91a8126a8deacf17a
e79b80db674a601b9c1f84a3b3
48f0b4e30da8707c9c51f32c32
d0f8c1bf04159e4fccae47ace7
b3f1321e7a62f72221cc9f3593
c93bb2701d5078fd9621c59e90
628ea7b647595b76ae9ea3aa16
50857c4a53ce7a5c3f854aa230
bad39df9a50f0d2c01a9ca3904
7369650348e40749ff5d9f67cd
a10d645982bdd5ae90e008265f
a875e6f6e364d6ebd2bed77eff
93e31760a8aff925da8c7cd2d8
d6953eca472e7f3101d5dfba60
c88fffd061ebc66fa56934dfaf
1f4bd5fead373f8dfdca2190a4
b6c201105d9dc98f5d38feede5
9ea8454fa1b7df608139a76ee7
d23e52cfc48f9d5672047d618d
c4b0e1b10c7ce2c4723b4e2407
9666aab25aa416c97b96436e2f
be7a6b5d44ea33aaaea3917e7c
da276f8c03ac80ffa69a3464b3
44123b44fe70733ecf12b037c6
f3118544a831e728781d780cfd
581908aa84594deac95b74d941
fbd27fd5548d3d6c7ce23f42db
f56c0bf4a31defd36b0a8b88c7
70f17a336be61ae1ca30327a80
570d2c38007cfa19ae70e4c270
36f558389c1dacc5068d91b0f5
7247e8d4387e76996ff3f18a34
f49440f845ea7c73bc906f29f8
a6f05e37b3fa335e5a086d5346
1e3311cce313d91f44b0913be6
34082f4e41427f816fe4835a6b
a738f92b3c08b424ec2d99589a
eab6799dcba237f8573e0ca69c
bd992c4f35791325f570221644
5d140ff0aba86ca9f61c20f9fb
e6be9799eed26d784b9ecbe796
499108ff7eeea55a4765f1c576
ea0519192f0f2f5823436551ed
c2e1dde3a073af107dfd02b439
18a7e4389b63da6c1d7bed1298
8fd992dd15ca326310ca8471de
a905669d12e2d2f40f215f1803
5526f7ce84cfed2306fbe09733
fe63557e5f6f26e8bf4fe2937e
0454acca4cf219ea7b27e5bcc6
5a03a175b652e03d23253f76f4
f503c6b0d2e77c83008d56fa4d
4636190bde3bb52ad2d29ca378
a85b16b65dae336df620c567f2
74c6b434b4b0017eca03f81274
a5be3c11831bddc88f6d751761
31c6c91338c60283337eab8226
Give me DA and 5min on your domain controller if you do not believe me :)
Who says, I don't believe you?
There are several hashes - if you allow all those types, there will be weak ones. But honestly, who has access to those at the DC is already two steps too far in. So what is flying through the air is important and there, if you use kerberos, I am pretty sure, we have salt.
There are several hashes - if you allow all those types, there will be weak ones. But honestly, who has access to those at the DC is already two steps too far in. So what is flying through the air is important and there, if you use kerberos, I am pretty sure, we have salt.
All valid points but not related to question. I never give out DA because of this but every environment I start in has a DA group with 30+ user accounts in them despite of the. No more that three are left when I am done.
ASKER
Thanks guys for responding but i am still confused.
My Domain Controller environment is on Windows 2008 R2. On Event viewer I see event viewer Event ID 4624 with Authentication package as Kerberos for user account logon events.
I have 2 conflicting suggestions.
One supposedly says that the following password hashes are stored on Domain Controller,
•MD4 (aka NT Hash) - Used for NTLM authentication.
•AES256_CTS_HMAC_SHA1_96, AES128_CTS_HMAC_SHA1_96 - Used for Kerberos authentication since Windows Server 2008. Salted with user logon name and hashed 4096 times using HMAC-SHA1.
•29 MD5 hashes, each using a different combination of login and domain name. Used for WDigest authentication
But Shaun says its only 1 hash, using MD5 and no salting.
Does this mean there is no consensus? Can some one clarify? Is this something that I can check on my environment? If yes, then how?
My Domain Controller environment is on Windows 2008 R2. On Event viewer I see event viewer Event ID 4624 with Authentication package as Kerberos for user account logon events.
I have 2 conflicting suggestions.
One supposedly says that the following password hashes are stored on Domain Controller,
•MD4 (aka NT Hash) - Used for NTLM authentication.
•AES256_CTS_HMAC_SHA1_96, AES128_CTS_HMAC_SHA1_96 - Used for Kerberos authentication since Windows Server 2008. Salted with user logon name and hashed 4096 times using HMAC-SHA1.
•29 MD5 hashes, each using a different combination of login and domain name. Used for WDigest authentication
But Shaun says its only 1 hash, using MD5 and no salting.
Does this mean there is no consensus? Can some one clarify? Is this something that I can check on my environment? If yes, then how?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
vivekk9, it would be most helpful to me if you told me what you need this info for. Why is it security relevant for you? What would be the scenario that you plan to defend against?
If you revealed all that, it is much easier to help you, because not all weak looking things actually matter.
If you revealed all that, it is much easier to help you, because not all weak looking things actually matter.
+1 what the hell is you actual concern ?
having the biggest salt around clearly does not make your network any safer.
multiple hashes of each password are stored. some are not salted ( though that hardly matters in this case ). others are (afaik). and the whole db is encrypted using a reversible crypt function. don't remember which but that does not matter because the decryption key is stored on the same computer anyway and most audit/hack tools would just pull the db's contents from memory.
( @shaun : preimage resistance does not mean much to a hash function : they are injections so many input strings will produce the same output. this demonstrates that grabbing the original string is simply impossible. at best you'll get a list of possible strings with lengths shorter than whatever you deem reasonable for a password )
but then storing an unhashed md5 of a password is plain dumb : any string producing the same md5 will represent a valid password, and we have rainbow tables, or brute force techniques. hopefully this md5 is afaik not used in the actual local authentication schemes ( but i'm unsure about the actual use cases... maybe someone knows ).
... if the question is how difficult it is for someone with admin privileges on the dc to grab user's passwords or at least working credentials, the answer is pretty much "trivial"
... if the question is how bad is it for the rest of my network security, the answer would be that's irrelevant in most cases because accessing the dc, decrypting the db and grabbing passwords will be more complicated than doing whatever mischief they want to achieve in some other way.
having the biggest salt around clearly does not make your network any safer.
Does this mean there is no consensus? Can some one clarify? Is this something that I can check on my environment? If yes, then how?
multiple hashes of each password are stored. some are not salted ( though that hardly matters in this case ). others are (afaik). and the whole db is encrypted using a reversible crypt function. don't remember which but that does not matter because the decryption key is stored on the same computer anyway and most audit/hack tools would just pull the db's contents from memory.
( @shaun : preimage resistance does not mean much to a hash function : they are injections so many input strings will produce the same output. this demonstrates that grabbing the original string is simply impossible. at best you'll get a list of possible strings with lengths shorter than whatever you deem reasonable for a password )
but then storing an unhashed md5 of a password is plain dumb : any string producing the same md5 will represent a valid password, and we have rainbow tables, or brute force techniques. hopefully this md5 is afaik not used in the actual local authentication schemes ( but i'm unsure about the actual use cases... maybe someone knows ).
... if the question is how difficult it is for someone with admin privileges on the dc to grab user's passwords or at least working credentials, the answer is pretty much "trivial"
... if the question is how bad is it for the rest of my network security, the answer would be that's irrelevant in most cases because accessing the dc, decrypting the db and grabbing passwords will be more complicated than doing whatever mischief they want to achieve in some other way.
@skullnobrains: That is part of an irrelevant section of the quote I posted.
Original question was answered. Feel free to open a discussion or a new question
Original question was answered. Feel free to open a discussion or a new question
ASKER
Thanks guys for the response. Let me go through them to understand further.
The reason i am asking this is because our Information Security team needs to fill out a security assessment for a customer and they have asked a question related to how passwords are stored. I haven't seen the form and dont know the larger context of their questions.
The questions are as below wrt storing passwords
1. Are Salts used in combination with a cryptographic hash?
2. What hash is used?
3. Are Salts random per user?
4. How many characters are used in the salt.
Obv. if the answer to first question is No, other 2 don't arise.
When this was asked by our InfoSec team, i decided to find out how passwords are stored in Active Directory so that i can give them a comprehensive answer.
Hopefully this gives some background on why i was asking the question.
The reason i am asking this is because our Information Security team needs to fill out a security assessment for a customer and they have asked a question related to how passwords are stored. I haven't seen the form and dont know the larger context of their questions.
The questions are as below wrt storing passwords
1. Are Salts used in combination with a cryptographic hash?
2. What hash is used?
3. Are Salts random per user?
4. How many characters are used in the salt.
Obv. if the answer to first question is No, other 2 don't arise.
When this was asked by our InfoSec team, i decided to find out how passwords are stored in Active Directory so that i can give them a comprehensive answer.
Hopefully this gives some background on why i was asking the question.
as far as password storage go, you can probably answer directly that they are stored in 2008rd dc.
ntml hashes are not salted, not even mentioning other above issues.
but you can instruct 2008rd into not storing ntlm hashes.
you should check that setting before answering. if ntlm hashes are used, the answer is not salted and a bunch of other reasons why they're easy to break.
ntml hashes are not salted, not even mentioning other above issues.
but you can instruct 2008rd into not storing ntlm hashes.
you should check that setting before answering. if ntlm hashes are used, the answer is not salted and a bunch of other reasons why they're easy to break.
Wow, what a question to ask... if your customer doesn't trust Microsoft's DCs, well, what can you do about it? Nothing.
I guess, your customer is worried about password saving in general, as in keepass, excel sheets, local hashes - but not how it's stored at the DC, because, who cares? The DC hashes cannot be grabbed unless you own the DC already.
I guess, your customer is worried about password saving in general, as in keepass, excel sheets, local hashes - but not how it's stored at the DC, because, who cares? The DC hashes cannot be grabbed unless you own the DC already.
Wait a second. Where exactly is the customer's data being stored that falls under the scope of this survey?
ASKER
Sorry for the late response. I did some reading and research and read what you guys had to say.
Shaun, Vikas, Mcknife and John's post are correct.
The password is stored in unicodePWD attribute with MD4 hash and is not salted. The supplemental credentials like kerberos keys, etc are stored encrypted with AES and are salted.
This link , https://social.technet.microsoft.com/Forums/windowsserver/en-US/034a0e33-a8ab-474e-ba6c-3371724d0be1/forum-faq-how-is-user-password-of-user-objects-stored-in-active-directory-can-i-view-it-can-i?forum=winserverDS, given my John does help.
Thanks Vikas and John for pointing in the right direction.
Thanks a lot Shaun for your answers and for being so specific with the answer. That helped a lot.
Shaun, Vikas, Mcknife and John's post are correct.
The password is stored in unicodePWD attribute with MD4 hash and is not salted. The supplemental credentials like kerberos keys, etc are stored encrypted with AES and are salted.
This link , https://social.technet.microsoft.com/Forums/windowsserver/en-US/034a0e33-a8ab-474e-ba6c-3371724d0be1/forum-faq-how-is-user-password-of-user-objects-stored-in-active-directory-can-i-view-it-can-i?forum=winserverDS, given my John does help.
Thanks Vikas and John for pointing in the right direction.
Thanks a lot Shaun for your answers and for being so specific with the answer. That helped a lot.
Glad we could help.
Please remember to endorse my, or any other expert's comments that you found helpful by clicking on the "Thumb's Up" button
Please remember to endorse my, or any other expert's comments that you found helpful by clicking on the "Thumb's Up" button
vivekk9, still some here wonder why you are asking this.
ASKER
-Vivek