What is Reddit's opinion of oclHashcat-plus?

From 3.5 billion Reddit comments

Let me take a crack at this question. I don't know much about using hashcat, but it's a beast, just like John The Ripper is a beast with GPU support.

These are offline attacks, that are utilized for when some asshat company doesn't secure their Gibsons properly, or from when a good company just has persistent blackhats who really want their user base's data. They dump the passwords to some site like dazzlepod, and then they use some decent machine's (or a bunch of machines) CPU/GPU cycles to rip the passwords using tools like JTR, or Hashcat. They can use dictionary attacks, massive dictionaries, can crack very good passwords. Massive dictionaries with word mangling can crack even better passwords. They can use Rainbow Tables to tear into hashes with ease.

They aren't really bruteforce attacks since they compare a word, phrase, or mangled jumble to a hash in order to guess the password. So the application isn't really going through each possible digit or character, it's comparing strings. With hashcat, it's comparing a shit tonne of strings per second using GPU.

TLDR; I think truely random passwords passphrases (like XKCD's passphrase comic) are still safe. Given enough time and power, massive fucking dictionaries, no password or passphrase is safe. However weak hashing algorithms are not safe.

Your information is extremely outdated. As per hashcat's performance benchmark you can attempt over 7 billion passwords per second of MD5, and that's just on a regular computer with one graphics card. Let us assume the character set is lowercase and uppercase characters along with 12 special characters, giving us a nice character set size of 26+26+12 = 64.

Then, an 8 character password takes 64^8 / (7 * 10^9) seconds which is about 11 hours. This is with a desktop PC with a single GPU, mind you. It is also using a brute force search which is not necessary for the vast majority of passwords due to dictionary attacks. Most MD5-hashed passwords are cracked in mere seconds unless they are very long and have a large character set as well as a password that is not susceptible to dictionary attacks.

MD5 was considered broken years ago and should never be used. Compare the 7 billion hashes per second to a modern algorithm such as bcrypt, which hashcat can perform slightly over 4000/second. And that does not get into the areas of cryptanalysis (analysing how an algorithm works to try to find weaknesses or prove strengths). See, for instance, this article.

Finally, note that salts are useless when attempting to crack a single password. Their strength lies in preventing techniques such as rainbow tables from extremely effectively cracking hundreds or thousands of passwords. Cracking a single password is not any more difficult with or without a salt. Also, I am not an expert so don't take my word on the above, educate yourself!

EDIT: That is not to say that Battlelog is susceptible to this. I am merely stating that MD5 is broken and should never be used.

>graphics cards process combinations??

Yes. Exceptionally faster than general purpose CPUs.

http://security.stackexchange.com/questions/32816/why-are-gpus-so-good-at-cracking-passwords

http://hashcat.net/oclhashcat-plus/

https://securityledger.com/2012/12/new-25-gpu-monster-devours-passwords-in-seconds/

I don't think the size of the salt matters much - the algorithm doesn't have to find the salt, just the password. A randomly generated high-entropy password still helps, because it's less likely to be checked.

Hashcat claims that, with a recent GPU, it can crack over 1 billion SHA256 hashes per second. If there are 10k users on the wiki, that's 100k guesses per user per second. Let it run for 60 seconds - how many users will have passwords in the first 6 million guesses? And you can easily scale computer power and time up a couple of orders of magnitude each.

Here's a better explanation, by Troy Hunt: Our password hashing has no clothes.

The only purpose of the salt here is to prevent pre-computation; the time to crack any given password remains the same.

Assuming a brute-force approach, this keyspace table suggests 357942375000 possibilities for a len=6, 1/0/0/0 (single number required).

Hashcat benchmarks suggest something around 2-3GHash/s for SHA1.

If I haven't flubbed the numbers (it's late) that puts something like 120secs to bruteforce an entry at the low end.

Smarter dictionary/template-driven approaches could well be faster.

>A GPU is a dedicated processor for visual data

Kind of. Actually the things a GPU was designed to do also are good for other stuff that does not involve graphics: If you want to do certain simple calculations on a lot of data at once, then its often possible (and much quicker) to use the GPU. An example would be hashcat, a program that can reverse hashes like md5 using GPUs.

You still have to get the rainbow table; this either requires tons of storage or tons of storage and lots of calculating hashes on GPUs. It only pays off if you're attacking tons of password dumps that use the same password hash technique.

Do you have a rainbow table for unsalted MD5? Unsalted SHA2-512? How complete is it?

Can it beat the 5 billion guesses/second of a stock Radeon HD7970 on MD5? Can you get started as fast as I can with a 35¢/hour AWS EC2 Cluster GPU instance?

Hashing IPs is useless, even with a salt. The number of IPv4 address is small enough (254 to the 4th power = 4.162.314.256) to try them all in a couple of ~~hours~~ seconds with a tool like oclHashcat.

EDIT: In other words, it is absolutely impossible to store IPv4 addresses securely.

So to summarize: Workers might find drive, try and use drive; because of being in weather / trash for months 99% chance drive will need data recovery services. Workers take drive, speed $600ish to get data back. Then gamble on brute forcing a password that might take years to crack if it ever happened.

Good luck workers.

Edit, workers go here for the software you will need to do this.

For MD5 it's about 7 billions(billions, not millions) checks per second on a single AMD6990. ( http://hashcat.net/oclhashcat-plus/ )

With this speed, any password with length of 6 digits/symbols/characters can be done in about two minutes. (salt doesn't reduce time too much since it's known).

If you are indeed remembering this fact from a few years ago, it was quite possibly when people hadn't yet figured out that GPUs can be awesome for doing massively parallel tasks with simple calculations... like computing a hash.

In terms of the amount of effort involved compared to practical workability, buying a relatively high-end GPU (I think AMD are currently better at general compute) and running an off-the-internet program (example and example) capable of using it to run staggering amounts of hashes compared to any CPU, is far more likely to come up better than figuring out if a small chip can actually do anything.

Also, looking at it simply, you're facing off ~30nm custom designed silicon with likely 200nm, so the number of HDMI ports you can get for the price of an AMD 7970 better be pretty damn huge.

Sort of…

Salting a "fast hash" like MD5 is not entirely useless, but the speed hashcat can blast through MD5 (including salted MD5) means it is reasonably described as useless.

The real answer is - don't use hashes for storing passwords. Use 'key derivation functions' which are designed for it. These days, that means scrypt, bcrypt, or pbkdf2 (roughly in that order, but it doesn't actually matter - any of those three will be "good enough", and the differences between them aren't significant enough to matter, choose whichever of them is easiest to implement in your tool chain of choice).

All three of those choices will automatically mean you're using "salting", but salting on its own isn't the solution - you need proper salting combined with slow hashing algorithms - and algorithms designed to protect against the sort of attacks that're available. Check out some of the numbers at the bottom of this page: http://hashcat.net/oclhashcat-plus/ - a modern consumer gaming PC can run something like 5 billion MD5 hashes a second, or 2 billion SHA1s, or 1 billion SHA256s. Compare that to the PBKDF2 line - only 130 thousand per second - ten thousand times slower! now look at the bcrypt line - not quite 4 thousand attempts per second - more than a million times slower than MD5. So if I get your password hashes, and decide to try every one of the 32 million passwords revealed in the rockyou exposure in about one hundredth of a second if you're using MD5 or SHA1 or 256 - even if you've salted them it's not going to take me very long to get all the "weak" passwords. If you used bcrypt though, it'll take me 2.5hours per password to check them against my list of 32million "common" passwords.

If you are wanting to crack some hashes http://hashcat.net/oclhashcat-plus/ take a look into that. Should point you in the right direction. There are similar tools that run a little better on AMD/ATI cards if needed. I just cannot remember their names off hand.

I am not gonna hold your hand through how to use it as I feel it is more educational for me not to, but just giving you that tool should be enough. Best of luck! and happy learning.

>Say you could only see approximately where a finger was when entering a password, and not exactly which key was pressed, could you realistically guess the password entered?

It depends on how many guesses I'm allowed to have and if I already have the password hash or not. Modern password crackers need the hash to have something to compare.

>Do any tools to do this exist?

hashcat accepts plug-ins.
I doubt there exists one for this exact purpose, but it's a good idea.

e.g. if you narrow the keyboard down to 4 quadrants, and are able to specify that the 1st character is in the top-left quadrant and you know if the shift key is held down,etc., then your space for possible solution of a 9 character password is reduced from 72^9 (51998697814228992) down to maybe 16^9 (68719476736).

If you can do a modest 1 million guesses per second, then....

• 51998697814228992 / 1M = 51998697814 seconds = 1648 years.

• 68719476736 / 1M = 68719 seconds = 19 hours.

If you have a sha hash, hashcat and a reasonable video card will make mince meat of 16^9 problem space in a few seconds.

Hash functions such as sha512 aren't really meant for passwords; these hashes are designed to be both secure (can't reverse) and fast -- in the case of passwords, fast is bad. Also, you're using the same salt(s) for every password, which is also incorrect.

The reason fast is bad is in the event of your database being compromised, an attacker can brute force passwords, even if you've used salts. For example, a decent CPU cracker can do 100 million + hashes per second.

The solution then, is to use a slow hashing method designed for use as a password hash such as bcrypt with a changeable work factor. You can reasonably tune this to only allow, say, 50 hashes/sec on a reasonably modern computer, making all but the weakest of password virtually uncrackable.

Your method whereby you hash and rehash the results is actually LESS secure then hashing it a single time with a proper hashing method ( This is because there is a finite number of possible outputs from a hash method therefore you're reducing the possible number of eventual results ).

TLDR: Cryptography is hard, use something designed for the purpose put together by people who know what they're doing, ie. Bcrypt in PHP

can you post the source for that 4 minutes claim ?

4 minutes on what kind of machine ?

with the number and code provided it takes closer to 1minute on average here for a small message (insignificant regarding the 14000 padding length for the POW).

so i checked a bit closer, its having a performance of 1/8 million double sha512 per second here using that python code.

now compared with sha512 performance on modern machines of between 50M and 200M hash's per second, sending a message would take around 1 second.

since this is also perfectly parallelizeable this POW is utter useless...

source for sha512 speed: http://hashcat.net/oclhashcat-plus/

CONCLUSION: this means a naive python implementation of a POW like this will NEVER be useful in the slightest because it will be A: too slow for convenient use by the normal user, and B: easily sped up by the advanced spammer.

The format is:

user:<md5(password)>#<fuck if I know>

I don't know what the part after the # is, but it's too long (256 bits) to be an md5sum. Just delete the # and everything after that. Note that it is not hmac-md5, it's just good old fashioned md5. For the line in your post, jtr took 40ms to spit out 'hello'. Since it's just md5, not hmac-md5, use oclhashcat if you have an ATI or nvidia video card.

Look into this program. Works great when you have captured the handshake. http://hashcat.net/oclhashcat-plus/

https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

That page explains how to get the handshake into ocl

It's much easier to use maskprocessor and oclhashcat-plus to do a mask attack. " Masks are a way of controlling a per-position keyspace when attacking passwords. Masks can define an entire character set or a single character."

For example: >?l = lowercase

>?u = uppercase

>?d = 0123456789

>?s = !"#$%&'()*+,-./:;?@[]^_`{|}~

Using: >mp64.bin ?l?u?l?l?u?U?l?U | ./oclHashcat-plus64.bin -m 100 --remove --outfile hashes.txt.out hashes.txt will look for passwords in the keyspace of aAaaAAaAa - zZzzZZzZz

http://hashcat.net/oclhashcat-plus/

But you need to be a bit of a hacker to use it. Someone should write a FAQ. In the meantime there are people who will help you out on this sort of thing. Good luck.

Yes! A long and strong password is the best way from having it discovered when a site you use gets hacked. Quality applications don't store passwords in plain text: they use a one-way cryptographic function (a hash function) to make validating a password possible, but finding the password difficult.

When a database is hacked, the password hashes can be attacked offline by video cards rented cheaply from Amazon without being prone to lockout.

If a site uses salted or unsalted MD5, a password dump can be brute-forced at five billion guesses per second with a single Radeon HD7970. That's every five-character mixed-case password with 200ms to spare. Every six-character mixed-case password takes under five seconds.

A ten-character mixed case password would take most of a year at that rate. A fifty-character mixed case password would take so comically long it doesn't make sense to think about it.

Responsible sites use functions configured to be slow, like bcrypt, scrypt, or PBKDF2. A five-character password in bcrypt (with a reasonable cost factor) could take the better part of an hour to crack with the same video card as above.

However, you can't know how a site stores its passwords, so what I do is to use different 50-character (or whatever the maximum is) passwords for everything, and keep those passwords in a password vault application.

http://hashcat.net/oclhashcat-plus/ and http://www.insidepro.com/ win most of the password cracking competitions (See DEFCON 'Crack me if you can'). They are not based on rainbow tables either... they're mostly just dictionary attacks followed by brute force.

Rainbow tables are not really anything special, they don't magically make long passwords easy to break.

Not before (just one example) oclhashcat with nvidia card(that costs less than $2000) will work at least as fast as ATI5970(which by the way sucks on linux - 1 gpu core simply doesn't work with latest drivers).