CODEWITHSUNDEEP
securityhashpassword-protectionbrute-force
Matthew
Matthew

Reputation: 10444

What can be done to protect against brute-force of compromised password databases?

In light of the recent data breach at Blizzard I want to ask about brute-force and salted-hash password storage.

Ars Technica has a good article on why even the salted-hash passwords that Blizzard stores can be cracked in short order.

Because of the salting and hashing used, we know that a brute force attack is the only viable way to crack the "complicated" passwords (dictionary/plain-word passwords are trivial)... However Ars Technica makes a good point that the vast improvement in computational power (both local and in the cloud) makes brute-force cracking more viable.

For a website, Jeff Atwood notes that forcing delays in authentication attempts can realistically thwart brute-force attempts.... But in the case of the Blizzard breach, hackers have physical control of the DB, so no such accessibility limit can be imposed.

Consequently, Jeff also recommends pass-phrases because of the increased entropy facing a brute-force attacker.... But this, too, will eventually effectually fade as computational power becomes greater and more accessible.

So the question is: What brute-force protection schemes can be implemented that aren't vulnerable due to increasing computation power?

Two-stage authentication is often considered, but I've heard that some of these algorithms are also being broken, and a physical authenticator has a likely static algorithm, so once it's cracked all users would be vulnerable.

What about scheduled rolling salts that apply to the entire authentication DB? This would add a lot of overhead but seems like it would secure even in cases where the physical DB is leaked.

Upvotes: 2

Views: 1429

Answers (1)

cegfault
cegfault

Reputation: 6632

Security is a combination of a few things (there is much more than this list, but rather than turning this post into a book, I'll keep it at these for now):

  • Encryption - complexity; making it difficult to know what the original content is
  • Obfuscation - unclear/protected; making it difficult for other scripts/users to know or guess how your security scheme works.
  • Intrusion Prevention/Response - determining when a security breach (or attempted breach) has occurred, and responding to the incident

Encryption will be things like hashing, salts, SSL, keys, etc. Obfuscation will be things like steganography, using rotating salts, separating the passwords off into another server that no script can access, etc. Intrusion Prevention/Response will be things like rate limiting, delays, shutting down servers once the breach is made known, etc.

Now looking at your question: What brute-force protection schemes can be implemented that aren't vulnerable due to increasing computation power?

My answer: none. Unless someone builds a quantum computer or a mathematician writes an expansion to group theory in a way that would blow all of our minds out of our heads, then any and all "brute-force protection schemes" will be vulnerable to increasing computational power (especially distributed processing, such as cloud servers or bot-nets).

It seems like your fear is the case of Blizzard, where the database had been accessed, and the hashed passwords were seen by the hackers. If someone has the hash, and knows your salts/hashing procedure, then it's only a matter of time before they can get the password. At this point, we are talking only about encryption, because everything else is known and/or moot.

It's a matter of math: the longer and more complicated the password, that's increasing orders of magnitude, and the problem becomes an exponential with each added character. But if you exponentially increase the computational power of the brute-force algorithm, you're back to square one.

If a hacker gets a hold of the hashes that are stored in your database, then immediately lock the database, figure out how they got in, fix that security hole, and add a step to your authentication procedure, update the database with the new authentication procedure and turn everything back on.

In other words, make sure your authentication server/database is secure on every level so that hackers can't get access to it.

If you just want to "buy more time", then add complexity. But keep in mind that this doesn't make your database more secure. It would be better to analyze how to lock the database down to prevent someone from getting the hashes in the first place.

Upvotes: 1

Related Questions