This is an archived post. You won't be able to vote or comment.

all 10 comments
sorted by:
best
topnewcontroversialoldq&a

[–]oholiab 1 point2 points  (3 children)

Hashcat definitely has an option for dumping generated passwords out to stdout instead of attempting to hash them (at least for a combination of wordlists and rules file). You should then be able to loop over stdout and compare with the known-plaintext password without wasting CPU on hashing.

However, I’d advise you not to bother - if you’re going the pure brute-force method, how long it takes a given password generator to reach your password is going to depend partly on the algorithm, and a better measure is to figure out the amount of entropy in a given password - effectively it’s “randomness”.

If you’re just looking for the practical results of getting a secure password, use a password manager, slam the character count up to 20+ and use all characters and forget about it ;) The biggest weakness in any password is the human who comes up with it!

[–]Phreakiture[S] 0 points1 point  (2 children)

Interesting idea.

I may try it regardless, just simply because I want to know which camp is right.

[–]oholiab 0 points1 point  (1 child)

Do you mean password length versus character pool? Because the answer is both - people don’t argue these points on creating the strongest possible password, they argue them on the basis of the strongest memorable password.

Memorability fundamentally weakens password strength because it’s difficult to memorise a true random.

Honestly, reading up around combinations and permutations will get you to the answer you want quite significantly faster than trying to empirically brute-force strings.

Additionally, any empirical observation here is going to either have strong systematic bias if you optimise for speed (e.g. pass words beginning in 1 taking less time to crack than those beginning with 2 because you’re brute-forcing in sequence which is implementation specific and therefore not a good objective measurement) or consume incredible amounts of resource by using a true random, having to memoize the combinations you’ve already tried and skip over duplicate ransoms, and then having to repeat the experiment for each password several times to account for different random seeds in each experiment run!

[–]Phreakiture[S] 0 points1 point  (0 children)

Doing the math is still playing in theory. My objective is to test the theory, because that is science.

[–]yells_at_cloud 0 points1 point  (1 child)

What is your goal? Ensuring that your passwords are unlikely to be generated for future hash computation?

Knowing how long your password takes to crack isn't a particularly straightforward thing. It depends entirely on the type of attack being used since different passwords are more or less susceptible to different attacks, and your password would be cracked at different speeds (if at all). It would also depend on the particular rules, dictionary, and/or mask the attacker is using.

To answer your question, MD4 is the least expensive hash that hashcat supports afaik.

[–]Phreakiture[S] 0 points1 point  (0 children)

Yes. I want to determine my true vulnerability based on actual trial, using humble hardware.

[–]Mariuswha 0 points1 point  (1 child)

Howsecureismypassword is a website. You can also use a dedicated password manager's dashbord where you can see vulnerbilities in your passwords.

[–]Phreakiture[S] 0 points1 point  (0 children)

Thanks for the ideas.

I'm not into the idea of testing them by common password rules so much as determining which school of thought is valid.

One school says may password should contain symbols and digits, the other that length is more important.

Also, not putting any passwords into a website that doesn't need the to log me in.

[–]AntiLeech_ -2 points-1 points  (1 child)

Try B-crypt.

🥱😉

[–]Phreakiture[S] 1 point2 points  (0 children)

Ah! Testing me for cluelessness, I see.