F5F Stay Refreshed Software Operating Systems IT audit examines password details to ensure security and compliance.

IT audit examines password details to ensure security and compliance.

IT audit examines password details to ensure security and compliance.

Pages (2): Previous 1 2
C
camilo645
Member
124
08-02-2016, 05:11 PM
#11
Your password remains secured on your computer and transmitted to the server for decryption. Once decrypted, it undergoes hashing and is checked against the stored value. It cannot be processed locally since the verification occurs on the server side.
C
camilo645
08-02-2016, 05:11 PM #11

Your password remains secured on your computer and transmitted to the server for decryption. Once decrypted, it undergoes hashing and is checked against the stored value. It cannot be processed locally since the verification occurs on the server side.

P
Phozzonunnium
Member
55
08-04-2016, 07:29 AM
#12
Hash functions work in a predictable way. Even though they appear random, they process the same input every time. Sending plaintext passwords or hashed passwords is risky because it exposes the underlying data. The main purpose of hashing is to verify integrity without revealing the original value. Including a cleartext step adds unnecessary vulnerability, especially if sensitive information is stored in memory outside the client device.
P
Phozzonunnium
08-04-2016, 07:29 AM #12

Hash functions work in a predictable way. Even though they appear random, they process the same input every time. Sending plaintext passwords or hashed passwords is risky because it exposes the underlying data. The main purpose of hashing is to verify integrity without revealing the original value. Including a cleartext step adds unnecessary vulnerability, especially if sensitive information is stored in memory outside the client device.

B
B_Mathias99
Member
70
08-04-2016, 01:03 PM
#13
Yes, it does.
B
B_Mathias99
08-04-2016, 01:03 PM #13

Yes, it does.

V
Velizar06
Posting Freak
865
08-05-2016, 12:41 AM
#14
Encryption keys might be compromised; hash values must be cracked through trial and error (some methods exist, like adding salt, but a one-to-one reversal isn't guaranteed).
V
Velizar06
08-05-2016, 12:41 AM #14

Encryption keys might be compromised; hash values must be cracked through trial and error (some methods exist, like adding salt, but a one-to-one reversal isn't guaranteed).

S
SlushieMagic
Member
51
08-07-2016, 03:31 AM
#15
If the system requires a hash for verification, attackers can easily provide it and gain access without trying every possibility. There’s no reason for manual guessing if the method already works.
S
SlushieMagic
08-07-2016, 03:31 AM #15

If the system requires a hash for verification, attackers can easily provide it and gain access without trying every possibility. There’s no reason for manual guessing if the method already works.

P
PvPTools
Junior Member
7
08-07-2016, 12:15 PM
#16
It seems like you're mixing up hashing and encryption.
P
PvPTools
08-07-2016, 12:15 PM #16

It seems like you're mixing up hashing and encryption.

Y
yoppy218
Member
180
08-07-2016, 01:28 PM
#17
This situation is distinct from what we're talking about. If a malicious party had direct access to the server, it's likely encryption keys are either visible or ignored. Sending encrypted plaintext of my password would give them my actual password. Sharing an encrypted hash of my password reveals only the hash value, not the password itself. In either case, they could potentially use that information to verify my account on this system. The value lies in knowing a password so they can test it across various authentication platforms. Under good design, hashes are salted for each app, and sending them to another service won't work unless using the same salt. My idea is that domain controllers keep passwords as salted hashes, receiving only encrypted versions via secure channels like TLS/SSL—making it hard for auditors to detect if plaintext wasn't sent or if brute-forcing was attempted.
Y
yoppy218
08-07-2016, 01:28 PM #17

This situation is distinct from what we're talking about. If a malicious party had direct access to the server, it's likely encryption keys are either visible or ignored. Sending encrypted plaintext of my password would give them my actual password. Sharing an encrypted hash of my password reveals only the hash value, not the password itself. In either case, they could potentially use that information to verify my account on this system. The value lies in knowing a password so they can test it across various authentication platforms. Under good design, hashes are salted for each app, and sending them to another service won't work unless using the same salt. My idea is that domain controllers keep passwords as salted hashes, receiving only encrypted versions via secure channels like TLS/SSL—making it hard for auditors to detect if plaintext wasn't sent or if brute-forcing was attempted.

M
MrBohica
Junior Member
10
08-07-2016, 01:44 PM
#18
Based on my research, they probably capture data while it's unencrypted in plaintext, either through local software tools or by altering the system to require passwords for access. Most likely, this mirrors common IT practices where organizations exaggerate their security measures to pressure staff into following rules they can't realistically enforce.
M
MrBohica
08-07-2016, 01:44 PM #18

Based on my research, they probably capture data while it's unencrypted in plaintext, either through local software tools or by altering the system to require passwords for access. Most likely, this mirrors common IT practices where organizations exaggerate their security measures to pressure staff into following rules they can't realistically enforce.

J
163
08-07-2016, 06:25 PM
#19
Well, I'll take it. It turned out they simply looked up the definition. That's pretty cool.
J
Jazzy_Games123
08-07-2016, 06:25 PM #19

Well, I'll take it. It turned out they simply looked up the definition. That's pretty cool.

Pages (2): Previous 1 2