What is the current speed an offline password cracking attack can be performed in guesses per seconds?

It is for sure heavily influenced by the used hashing-algorithm and the used hardware. But I am more interested in the general top bar achieved by a reasonable price without a botnet.

Since I need this information for my thesis, I would be interested in citable sources where this information is published. A scientific paper would be ideal.

In the question How can hackers get 1 billion passwords per second? 1 billion guesses per seconds are mentioned but without a source.

The zxcvbn test lists a speed of 10B / second for a fast hash with many cores. But it is also without a source and I am not so sure about what the B stands for. Billion would be quite a lot.

  • Welcome to the site! There are lots of benchmarks available online, e.g. this one: gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 Yes, B indeed means billion. Scientific papers might talk about the theoretical number of bytes in an average word and the number of cycles per byte and derive a figure from that... they're always vague, theoretical, limited, and hard to read. I'm not sure that is what you are looking for, this is very easy to just run a benchmark on, no "science" needed. – Luc Aug 22 '19 at 21:48
  • You've kind of asked "how long is a piece of string"? Or, more specifically, "how fast is a car?" What do you consider a "reasonable price"? And why not a botnet? It seems like you have some very specific requirements that you have not disclosed. Why would you think that B would not mean "billions"? – schroeder Aug 23 '19 at 7:23
  • zxcvbn does indeed explain it's source. – schroeder Aug 23 '19 at 7:26

It depends on several factors. Primarily, how are the passwords stored?

The current best practices are to use a key stretching algorithm. The NIST specifically states using key derivation algorithms that are like PBKDF2 and Balloon (13th paragraph,, not counting the bulleted list as a paragraph). The community typically lists PBKDF2, bcrypt, scrypt, and Argon2, with PHP providing bcrypt and Argon2 for its password_hash() function.

The link for Argon2 is to its white paper. Between this and the NIST standards, these are hopefully citable documents, and the Argon2 white paper includes additional citations.

The reasoning behind making their use a best practice, is these methods have configurable difficulties, and an administrator setting up the authenticator for their system should tune their chosen method to make brute-force guessing prohibitively expensive.

If the cost is tuned to require enough work for a processor core to be tied up for a full second, this has little impact on, for example, a web server that occasionally handles authentication. A user can be reasonably expected to wait for a second, and other users will be minimally impacted, as many web servers have multiple cores.

On the other hand, a naive attacker will only be able to guess one password each second, per core, and some key stretching algorithms specifically target features that make (expensive) memory more valuable (Argon2, scrypt), or make parallel processing, such as with multiple GPU cores, much slower (Argon2, bcrypt). While a dedicated attacker will generally have more resources to devote specifically to brute force verifying passwords, they would still only be guesses tens of passwords per second, rather than the millions or billions of guesses possible with modern ASICs attacking hash algorithms.

If the passwords are stored as just salted hashes, though, there exists hardware that is especially suited for a very similar task, and it would take very little to design an ASIC that performs comparably: Bitcoin miners. While a hash guesser would probably be far more expensive on a per-unit basis, due to the economies of scale that Bitcoin miners enjoy, a single $2,400 unit can perform 14 trillion bitcoin hash guesses per second.

General purpose GPU-based attacks against hashes and common password encryption/obfuscation systems that don't use properly configured key stretching algorithms can typically make millions to several billions of guesses per second, depending on the algorithm, as shown in the benchmarks that Luc linked in a comment.

| improve this answer | |

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