Hot answers tagged

23

The main reason for hashing passwords seems to be that users reuse passwords and, thus, leaked passwords would disclose sensitive information about a user This is an incorrect statement. The main reason of hashing is to protect passwords from disclosure in case an attacker has got access to database (access to database directly or to its backup). It ...


8

The source explains an overarching concept and is perhaps slightly ambigious rather than outright misleading. Hashes sent alongside data in their "raw" format are definitely susceptible to a tampering attack and, therefore, we need to either: Share the hash value out-of-band: A simple example is downloading a file off a website which shows the file's ...


6

Inferring that the communication channel between client(s) and server is secure (like a well configured TLS tunnel), sending a mangled password or the password in plain text has no direct benefit or loss to the authentication mechanism. Both are susceptible to replay attacks, it's just that in one case you replay the password, in the other you replay the ...


4

This isn't a breach. A breach happens when someone gains access to data they shouldn't have. While you have discovered some (legitimately concerning) details about their authentication process, you have not uncovered any sensitive customer data. Nor can an attacker take advantage of this as easily as you imply. An attacker certainly could sniff the ...


4

The comments have ping-ponged around making it difficult to see the whole. Rather than play whack-a-mole, here is a summary. First, let's remember that any password scheme must improve on best practice. Best practice is to use a good password manager with a good password generator. Let's also remember that security is only as strong as its weakest link. It ...


3

Storing encryption keys next to encrypted data is always a security risk, even if the encryption keys are hashed. Now if I understood correctly, the reason for storing the encryption keys is to check that the user can decrypt the data (since the key is hashed, you wouldn't be able to reverse the hash to decrypt the data). But for this purpose you can use an ...


3

Your source is misleading (Microsoft misleading, who'd have thought!). You cited this: Hash values are also useful for verifying the integrity of data sent through insecure channels So technically it says it's useful if the data was sent through an insecure channel. It doesn't specify how the hash was sent. You are completely right: if the attacker can ...


2

I guess it all depends on your thread model and szenario. I am reading between the lines that you are afraid of what will happen if an attacker gets access to the table containing the 2FA secrets, for example by a leaked backup or SQL injection. If this is the case, you can encrypt the secrets with a systemwide key, that is loaded into your application ...


2

It depends. There is not enough information in your question to give specific answers, and probably without knowing the server side, it will be hard to evaluate. Simply hashing the password on the client side is only just a litte better than submitting it as plain text to the server. It ensures, that the server never truly receives the original password. ...


1

While the actual SDK code is not available, we can make an educated guess that the ENIntervalNumber is NOT used to calculate the duration of contact. Let's step back a minute from the crypto to describe what's actually happening on a person's phone. This is documented here, but to give a quick summary: Alice who has enabled the app is scanning for ...


1

If the hash of some data is computed and sent along w/ the data, can't an attacker alter the data, re-compute the hash and the receiver would be none the wiser? In a data stream that is only hashed, then yes they can. If you want to mitigate this you need to ensure that this cannot be done without detection, such as signing the hash and including the ...


1

office2john is designed for encrypted files, not files that just have an easily-removable snake-oil protection field. Anyway, here's a quick implementation of the algorithm that they use: #!/usr/bin/env python3 from base64 import b64encode, b64decode from hashlib import sha512 import struct def hash_password(password, salt, spincount, hash): result = ...


1

Because cracking a hash is work-intensive. And this work directly corelated with electricity cost. Allowing people to hog GPUs for a long time for free is absolutely infeasible from a business perspective. You can't compare this to a regular web server either, because a regular webserver takes comparatively only a tiny amount of work to serve you the ...


1

If an attacker can manipulate the file you download, surely they can also manipulate the text file with SHA256 checksums. Unless they have access to the PGP key, they cannot create a valid PGP signature for any file or message, and so a signed message which contains the SHA256 checksums or a valid detached signature for a file is guaranteed to be written by ...


1

Does this represent any security risk I'm unaware of? The largest security risk is that if someone compromises the database, they will have both encrypted data and hashed keys, and can mount a brute force attack on the keys. Correspondingly, you must treat these as passwords, and use a strong password hashing algorithm like bcrypt and not a high-...


1

There is absolutely no advantage to hashing the password with a fast hash before passing it to the password hashing function. The fast hash would become part of the password hashing algorithm, for example you'd be using the password hashing algorithm SHA-256+bcrypt instead of bcrypt. The attacker would just have to tweak their password breaking program to ...


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