New answers tagged

2

In Windows 10 Anniversary update, Microsoft changed the encryption algorithm used for password hashes in SAM, the main difference being they switched the cipher used from RC4 to AES. As pwdump7 is closed source and I wasn't able to find the date of its release, we can't tell for sure, but most probably it was never updated to be able to decrypt this newer ...


2

Once particular user find him positive for covid-19 he will upload his private key to the server. A private key is supposed to be kept private and uploading it to a server will defeat this requirement. I'm very much concern about user's privacy. So I need to make a user completely anonymous. in my case I don't want the server to find out UUID of A....


0

Nope. The entire certificate entry table is excluded from the Authenticode digest. The intuition for this is that, in the case of multiple certificates, the length and other metadata in the certificate entry table would cause problems for consistent hashing. MSDN offers similar reasoning (link): When included in a certificate, the image digest must ...


2

According to the Argon2 Specs, specifically section 9 Recommended Parameters, the following procedures should be done to determine which parameters to use: We recommend the following procedure to select the type and the parameters for practical use of Argon2: Select the type y. If you do not know the difference between them or you consider side-...


3

I have read that it's not enough to hash a salted password once. You need to keep hashing it thousands of times to make brute forcing more difficult for attackers. That is right. You want your password hash function to be slow, so that an offline brute-force attack would also be slow. hash = hashManager.ComputeHash(hash); You really want to use the ...


5

tl/dr: Even if your arguments were correct, building a rainbow table for a single password for all possible salts is practically impossible. With a 128 bit salt and a 184 bit digest (bcrypt), building such a rainbow table for even a single password, and then storing it on high density Micro SD cards, would require a stack of Micro SD card weighing almost as ...


3

It depends on where the data was changed and all you mentioned outcomes are possible. TLS messages has some public scructure. For example, TLS record: and if its structure is broken, then entire message is considered broken. This doesn't necessarily say if encrypted data was additionally tampered. If only ciphertext was tampered so entire structure remains ...


0

Your dd command is simply copying 512 bytes to the output file. If you want a hash, you need to pipe it into a hash function such as: dd if=\\?\Device\HarddiskVolume11 bs=512 count=1 | md5sum For example on my Linux machine (with normal slashes instead of Windows backslashes): dd if=/dev/sdb bs=512 count=1 | md5sum 1+0 records in 1+0 records out 512 bytes ...


1

Complementing the previous suggestions. How about using SHA-3 (which apparently was not official until 2015, later than this discussion) prepending the card number with a merchant specific secret key in order to make the hashes merchant-specific. Simply prepending a secret key to the message was insecure for SHA-1 and SHA-2 due to their length-extension ...


2

OAuth2 says that the method of client authentication is up to the authorisation server. It can be anything. Based on RFC 6749, If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server. The authorization server MAY accept any form of ...


1

Since hashing algorithms don't use keys would the best strategy be to pick Blowish or SHA512 and salt using the key? With HMAC you can use secret key to generate hash for sensitive data. I need to provide a key so that a single input is represented different across different reporting platforms, time periods Use different key for each different ...


1

Any hashing algorithm that is used in practice should have a key space that is impossible to brute force. On the other hand, the set of actual passwords is much more limited, so attackers will not search all possible passwords, but only those that are used by real users. Now if you have a good password, and an attacker does a brute force attack, it is not ...


2

When I decode it, I get random 8 chars regardless of password length. With the given base64 of length 24 you get 16 bytes. These 16 bytes are 8 unicode characters only when interpreted as utf-16. When interpreted as utf-32 it would be 4 characters and when interpreted as utf-8 it would be a variable number of (possible invalid) characters. But nothing in ...


1

If the goal is to prevent someone with access to the password database from logging in, then server-side hashing is an absolute must Well, yes. There's your answer right here. my understanding is that the purpose of hashing is to help people who share the same password across many sites Hashing mostly doesn't help there. If Eve compromises server S2 and ...


1

Your technical analysis makes sense, but one basic assumption is flawed. The purpose of hashing is not to help people who share the same password across many sites. This is a absolute no go and should neither be encouraged nor supported. The main goal of hashing is protecting passwords against offline attacks. If an attacker is able to access the password ...


2

Does it matter if a brute force search for a password returns a collision and not the password? There are other answers addressing this question quite well, so I'll explore a different angle: It doesn't matter, because brute-force searches are unlikely to ever find a collision instead of the original password. Assumptions: The password is shorter than the ...


0

Linux Specific TLDR; sha256sum -c thefile.sha // thefile: OK Success! Unless you ran that command in a directory that doesn't contain the target of the shasum, in which case you'll get: sha256sum: thefile: No such file or directory thefile: FAILED open or read sha256sum: WARNING: 1 listed file could not be read /TLDR; Verify for Yourself Everything ...


-1

Does it matter if a brute force search for a password returns a collision and not the password? If a password is the only mechanism for accessing a resource, it often does not matter if it is exact or a collision. If you enter "dog" or "cat" and your hashing algorithm was string.length, then either will grant you access. While this is often the case, it ...


49

Steffen's answer covers this perfectly, but I just wanted to add a few more details. Anything that gives a match is usually fine As he says, you generally don't care about finding the actual password, because many applications will be happy to authenticate you with any string that happens to hash to the hash value stored in the database. This is most ...


18

The main goal of brute forcing is not to get the original password but to get a password that works. Thus it does not matter much if the found password was not the original one as long as it works. It is very likely though that with efficient and intelligent brute forcing based on a dictionary of common passwords and typical modifications the resulting ...


-1

Just to add up to the question: Your hashed values need to be of certain 'difficulty' because if a malicious user knows your algorithm, he can create some 'rainbow' tables where the hashes in this table were previously made by an attacker and check if "your hash" corresponds to a hash in the 'made' table.... thus knowing what was the original value hashed ...


Top 50 recent answers are included