I am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?
I'm not sure how modern hashes fare in this regard, but one issue is that hashing a hash reduces your input space from all possible passwords to all possible hashes of the first hasher.
In my experience, it wouldn't be a reduction. I.e. most passwords are shorter than most hashes.
I'm not sure how modern hashes fare in this regard, but one issue is that hashing a hash reduces your input space from all possible passwords to all possible hashes of the first hasher.
In my experience, it wouldn't be a reduction. I.e. most passwords are shorter than most hashes.
Technically, it does actually. Suppose we use SHA-256 as first hashing algorithm, the input space for the second is effectively reduced to the 256 bits of output from the first which is much smaller compared to the input space of the first algorithm.
I am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?
https://link.springer.com/chapter/10.1007%2F978-3-540-28628-... https://link.springer.com/content/pdf/10.1007%2F978-3-540-28... Abstract: "In this paper, we study the existence of multicollisions in iterated hash functions. We show that finding multicollisions, i.e. r-tuples of messages that all hash to the same value, is not much harder than finding ordinary collisions, i.e. pairs of messages, even for extremely lar…
Shouldn't the reduction is input space for the subsequent hash functions actually make it easier to find collisions ?
Or is finding collisions not closely related to input space ?
The paper is a bit above my level of understanding and I tried making sense of how the cryptanalysis is done to no avail.
I used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Stud…
What if I send an email with a partial dictionary, hidden in an invisible HTML block. If the user is blocked from replying, I know their password was in my original email.
While I can envision a case where you might be able to make this work for specific configurations of the blocking and specific bounce handling and from address forging, while it would allow you to use to the resources of the remote org to do most the checking, it would also require fairly intimate knowledge of quite a few configuration variables. So may, in fact, that you would probably already have an administrator password of some sort if you were able to carry it out. :)
I built my latest application using Amazon Cognito for user management. My application and database don't ever know anything about the passwords. Amazon's problem.
While letting them handle the security options is probably going to result in a more secure system for you, it's certainly not "Amazon's Problem" when your database gets leaked and your user data gets out. For example, you're still going to have to explain to your users that you were compromised, and you're still going to show up in the haveibeenpwned list, not "An AWS Cognito Account".
Most of those passwords that got cracked, my reaction is, OK, of course that's a weak password... but "1qaz2wsx3e" and "A3eilm2s2y"? Geez! How'd they get those?
> 1qaz2wsx3e That's just diagonals on the QWERTY keyboard. > A3eilm2s2y Apparently that's an in-game password for https://en.wikipedia.org/wiki/Parasite_Eve_II Commonly used passwords can be pre-hashed and easily cracked.
I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…
> who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. On the other hand of you are not part of the security team something like this can get you in some real trouble. Don't do it at home kids!
I tried to send an email and now my AD account is locked!
That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.
It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.
I remember seeing a list of cracked passwords and one of the ones they got was !QAZ2wsx#EDC4rfv%TGB6yhn. It passes every single password strength checker and dictionary word checker in the world, and still gets cracked.
I used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Stud…
What if I send an email with a partial dictionary, hidden in an invisible HTML block. If the user is blocked from replying, I know their password was in my original email.
The user will see the bounce, so before you know they couldn't reply, they should know something weird is going on.
I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…
That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.
It may have improved, but a few years ago at least zxcvbn was implmented by repeatedly trying various password "simplifications" at some kind of entropy cost. At the time it was quite easy to construct long (something like 60-char - our limit at the time) pathological passwords where a single zxcvbn check would take at least a minute of CPU time, with strongly super-linear growth for each additional char.
Might have been improved by now; not sure. If it's not you might be wasting electricity another way ;-).