Hot answers tagged

27

TL;DR: The answer depends on the hash algorithm, what part of the hash is revealed and the strength of the password. Assuming that the hash algorithm is known the knowledge of a specific part of the hash might make brute force attacks easier: The attacker might now run most brute force tests offline and also in parallel and is thus not restricted by rate ...


9

1) password hashing iterations If you don't care about waiting a little longer, you can use the maximum count value, which is 65011712. This isn't strictly the number of iterations so much as the number of bytes to be hashed. S2K works by repeatedly feeding the password and salt to a hash function for a specific number of bytes. The more bytes, the longer ...


3

There is quite no case when it's not easier for the adversary. The only case is if the password is salted (with large random) and the salt is not displayed. The main concern is to know how much easier it is for the adversary. In the worst case, he can perform offline dictionary/bruteforce attack and due to the dispersion of the hashing function, he ...


3

The password is not hashed in the application but in the server. The server gets the password+OTP token in clear (protected with HTTPS between client and server) and can extract both password and OTP token from this, then proceed with normal password verification.


2

Many application control products (aka, application whitelisting) use hashes to identify approved executables. If you duplicate the hash of an approved file, that would be sufficient to execute applications in most cases where such controls are used. Code signing also relies on file hashes. The security of these products stems from two sources: first, it is ...


1

First of all, don't use SHA-1 or MD5, as they are both deprecated (see this IETF draft). As @dandavis has correctly noted, security through obscurity does not make your system more secure. Actually, the post that @Steffen Ullrich shared in his comment is excellent and thoroughly explains why you shouldn't focus on keeping the algorithm you used a secret, ...


1

Because it is stored as a one-way hash - since Amazon know how long the OTP part, is they trim that off what you typed before generating the hashed version to compare with what they have stored.


1

Rather than designing such a system yourself, you might want to take advantage of an existing File Integrity checker such as Aide: Aide creates a database from your filesystem and stores various file attributes like permissions, inode number, user, group, file size, mtime and ctime, atime, growing size, number of links and link name. When someone ...


1

There is no problem if you have a good password created by diceware or Bip39 with good entropy then a polynomial-time adversary even with the knowledge of the hash and salt cannot do anything. If your password is already 123456, we already assumed that can be broken, part of it leaked or not. What about the salt is not available to the attacker, good luck ...


1

You could do both, you hash it at the client so if the attacker can get through the https security they will not be able to see the plain text password. Then hash it again at the server so if the attacker gets the passwords stored in the server he can not just send that to the server and gain access to the password.


Only top voted, non community-wiki answers of a minimum length are eligible