1
$\begingroup$

some years ago it took long time to "decrypt" hashes because they took slow cpu to brute force. Nowadays they use graphic cards for stuff like this and can do this most time in less than 20 Minutes without problems.

So: Even if they don't take that long to decrypt hashes, would it still be worth time in developing, debugging and troubleshooting(, ...) or would they still take only minutes to crack a hash when using dynamic keys (never the same two) ...

Is there any kind of formula to calculate how much time they'd need like there is with normal hashes?

$\endgroup$
  • $\begingroup$ dynamic keys = salt? And you're only considering the old "simple" hash which just hash the passwords. Nowadays you perform so much black magic on the passwords that you're not better off than back in the good ol' days when a (simple) hash was considered secure. And the answer depends: Do the 20min attacks consider salted hashes? Do they use rainbow tables? If they consider salting than you'd need 20min for each password... $\endgroup$ – SEJPM Aug 12 '15 at 13:04
  • $\begingroup$ By dynamic keys I mean salt and pepper, and BOTH change from password to password, so its never the same... $\endgroup$ – SophieXLove64 Aug 12 '15 at 13:05
  • $\begingroup$ The formula you need: $NumberOfPossibilities \times NumberOfPasswords \times TimePerTry \times NumberOfPossiblePeppers = OverallTime$ $\endgroup$ – SEJPM Aug 12 '15 at 13:11
  • $\begingroup$ Thank you, SEJPM :) Just don't really understand how you got to that formular o.O $\endgroup$ – SophieXLove64 Aug 12 '15 at 13:13
0
$\begingroup$

Your question is about breaking password hashing schemes (PHSs).

The usual way to break password hashes is by brute-forcing the input until you find a match between the resulting hash and the obtained hash.

Now there're some counter-measures to harden the schemes against various attacks that would allow you to break many passwords very fast, because most passwords are weak.

So let's build some formula to estimate the time you need to break a collection of given hashes $(h_1,h_2,...,h_n)$.

The first thing you do is think about how many values are actually possible for the passwords. Are they restricted to lower-case only? Do they actually use numbers? How long are they? This is expressed in the metric $NumberOfPossibilities$ which can usually be approximated by the size of the dictionary you use times the permutations you try. If you assume clever users you can computer $NumberOfPossibilities=NumberOfPossibleChars^{NumberOfChars}$.

Now we have to consider how much time do you need to actually try any of those passwords. Because if we'd consider 0-time we could instantly brute-force all passwords (which would be boring). This metric is called $TimePerTry$ and good programs use functions that require you to spend 100ms and more per try using PHSs like PBKDF2, scrypt, bcrypt or Argon2.

As you've expicilitly asked for different salt and pepper for each password you also need to consider each password by itself as they all have different salts. This is captured by $NumberOfPasswords$.

Finally you also asked for pepper, which is a value that is assumed to be need to be guessed by the attacker (and sometimes also by the defender). The amount of possible values for the pepper is captured by $NumberOfPossiblePeppers$.

This finally gives you the above mentioned formula $$NumberOfPossibilities \times TimePerTry \times NumberOfPasswords \times NumberOfPossiblePeppers = OverallTime$$ to calculate the overall time to break the scheme. The needed memory requirements (of own interest) and the parallelization can be calculated / inserted in a similar manner as the other values and I'll leave this as an exercise.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.