Admin
Joined: 09 Nov 2005
Posts: 7410
Location: Russia
|
 Posted: Mon Oct 27, 2008 8:03 pm Post subject: Hash Bruteforcing History |
 |
|
Let’s get the picture, what happens when a user publishes a hash, password to which is to be recovered, on the forum (to be more specific, let that be an MD5 hash “0040626ebe4c11e2f79fc581e0c9af66”)? Precisely – all who have free time and the desire engage in the recovery using different attacks, and it’s obvious that many of them do the same job, trying to recover the hash password with same attacks and same settings.
It would be great if the password could be easily recovered with a hybrid or combined attack; but what if none of the attacks worked out? The only option that remains is brute-force attack, which, despite that it’s most time-consuming, guarantees the complete recovery of the password, provided that the attack settings – character set and length of passwords to be validated – fit right.
That leads us to the sad conclusion that if we knew, with which parameters of brute-force attack others have tried to recover the password, we wouldn’t have spent our time on running the same attacks!
Hence, the idea is to store the history of hash bruteforcing along with the hash itself. This is how it would look: on the forum, along with the hash “0040626ebe4c11e2f79fc581e0c9af66”, we will publish its history – e.g., “02C.068.1E6”. Enter it here (or decrypt it on your own), and you will learn that this hash has been bruteforced with the following parameters:
| Code: | character set: numeric; password length: 1…12 characters.
character set: loweralpha-numeric; password length: 1…8 characters.
character set: alpha-loweralpha-numeric-symbol14; password length: 1…6 characters. |
With this information available, we know that repeating these attacks won’t make sense, but we can attempt to recover the password with an attack with different settings; for example:
| Code: | | character set: numeric, password length: 13 characters. |
If the password could not be recovered again, its history is to be updated to “02D.068.1E6”, and the search is to be continued with new parameters and hash history kept current.
Obviously, such history is necessary for hashes from really strong passwords, which couldn’t be recovered with other attacks, and which require the effort of many people.
Of course, there are reasons for doubting the validity of the history (as re-validating it would require attacking the hash with all attacks from its history), but I am sure that a user who is desperate to recover the password to a hash is not going to give a garbled version of its bruteforcing history.
Maybe with time this will become a de-facto standard for working with hashes or maybe it won’t; anyway, I think the idea is worth being told to as many users working with hashes a lot as possible.
The detailed description of the hash bruteforcing history format can be found here. It already contains the required minimum for coding hash history, and I encourage you to try it in action with real hashes.
Hash history can be stored in the “Comment” field, and such hashes can successfully be loaded to PasswordsPro (in the format “:0040626ebe4c11e2f79fc581e0c9af66:::02D.068.1E6”). If this proposal finds support on many forums and will begin to evolve, I will implement hash processing history in PasswordsPro directly.
P.S. The idea of keeping hash search history was originally suggested by user with nickname -=lebed=- from the Russian forum, and for that we give him a special thanks! |
|
Admin
Joined: 09 Nov 2005
Posts: 7410
Location: Russia
|
| Posted: Tue Oct 28, 2008 6:41 pm Post subject: |
|
|
Yes, the information on the initial length in this format is not available. Nevertheless, it’s hard for me to picture a user that would engage in searching an unknown password beginning with the "8-8,loweralpha" or "14-14,numeric" range; otherwise, the password could simply be skipped. That is ahy this format assumes that the minimum length of passwords in each record is always equal to one character; i.e. the record 02D means that the numeric charset certainly completed the entire range from 1 to 13 characters, and now it can start searching within the "14-14,numeric" range, skipping the 1-13 range.
P.S. If the length of a password is known in advance (what occurs very, very rarely) – for example, 8 characters – you can immediately link it with the 6E7 history, thus clearly telling everyone that all possible passwords with the length of 1...7 characters are to be ignored. |
|
