Password Cracking with 8x Nvidia GTX 1080 Ti GPUs
servethehome.com
servethehome.com
http://blog.zorinaq.com/whitepixel-breaks-286-billion-passwo...
It's interesting to note that 6.5 years later a single GPU like the Nvidia 1080 Ti can match the whole 2010 machine (32 billion hashes/sec). This is a doubling of speed every ~2 years. Moore's Law is still alive and kicking (contrary to what many claim)!
[1] Incidentally posting this machine on HN is how I got pointed to Bitcoin thanks to the reply of a HN user :) https://news.ycombinator.com/item?id=2003888
http://www.cnbc.com/2017/05/23/jeff-gundlach-has-a-theory-on...
As you can see, ETH <-> Fiat pairings have more volume than BTC -> ETH right now.
Bitcoin is a form of safety and asset diversification in a world of economic uncertainty. Wealthy foreigners like bitcoin because it is in many instances safer than keeping money in a bank
Bitcin turned anyone who bought even just a few dollars of it in 2009-2010 and held, rich And those who bought $1000s if it in 2011 into millionaires. This may be is the greatest gain of any tradeable instrument in the history of civilization. You can't find those kind of returns anywhere else, short of investing in the next Uber or Facebook but those were private ventures and unlike Bitcoin not open to the public.
Selling 1000 books on amazon for $8, although virtually possible for ordinary people to d, is like a piddly 3 bitcoins that any fool could have bought have bought in 2012. Goes to show how capital beats labor. To get rich, look for things that will go up and put your money in it early. Easier said than done, but the returns are astronomical when you get it right.
As for the tax man, declare the capital gains and you'll be right as rain.
That statement is so often misunderstood, in multiple ways.
First off, Moore's Law isn't technically about performance increases. It's about doubling of transistors every 2 years on the same die space. We still got that on CPUs until very recently, even though CPU performance has stopped doubling every 2 years like 15 years ago. But now even the transistor count doubling doesn't happen every 2 years - for CPUs. If that were to happen we'd all have 32- or 64-core laptops by now. And even then the performance wouldn't be anywhere close to 64x (compared to single core).
The second misunderstanding, which exists in your post, too, is that most people refer to Moore's Law dying when they talk about CPUs (especially if we discuss performance).
However, GPUs have indeed kept doubling or so their performance every 2 years, also until very recently. Now it's more like a 30% improvement per year, or 70% improvement every 2 years, which is still way better than CPUs.
And the reason for this is because GPUs pretty much scale with number of cores. If you have 4000 CUDA cores in 2017 for 150W TDP and a $1000 price, then you're going to have let's say 7000 CUDA cores for 150W TDP and $1000 price in 2019, and the performance will be 70% greater. It doesn't work like that for CPUs, and it hasn't for like 15 years.
I strongly disagree that the rate of CPU perf improvement has slowed down "15 years ago". What a laughable statement. You have to look beyond core count to gauge performance. Microarchitectural improvements, new instruction sets (SSE, AVX), bigger caches, etc certainly still help keep the pace. Have a look: https://www.hpcwire.com/2015/11/20/top500/ In particular: https://6lli539m39y3hpkelqsm3c2fg-wpengine.netdna-ssl.com/wp...
Also perhaps you get confused by the fact the average wattage of CPUs sold to consumers is dropping. If, from the performance of a 60-70 watt Netburst Pentium 4 from 2001, you project the expected performance of a 2017 CPU according to Moore's Law, then you should look at today's 60-70 watt CPUs, not at modest 10-20 watt CPUs that seem to be quite popular these days.
Moore's law is fuzzy and has been for a while. I doubt if even Moore has the authority to say what it is about anymore.
When one person hears "Moore's law" or any other words what are the chances the person hearing those words is thinking the same thing as the speaker? For some words the listener hears the same thing the speaker intended, but I don't think it is for these words anymore.
Performance is still exponential the practical of Moore's law is still real.
It's more the workload than anything - CPUs scale very well with the right tasks. Nobody gives GPUs the 'wrong tasks' that don't scale
Mining in 2010 with such a machine. That must have yielded a considerable ROI.
In GPUs, which is why tech that can take advantage of parallel processing such as Deep Learning, AR or coin mining has a bright future, whereas the rest is slowly falling into standardized oblivion with low-paying jobs.
As you point out, graphics, deep learning, AR, and others can benefit from increased computational power. Therefore, we're seeing Moore's Law (which didn't start with Moore) appear where that increased compute ability can be most readily applied.
Meanwhile, when an exciting new technology appears, there are always a small group of people that have the required expertise. With IT, young brains are able to learn these new skills incredibly quickly, so markets respond very quickly. From what I've seen, there's usually an overshooting effect where people think "there's a future in X" for longer than they should. Maybe school is to blame. But basically, you have a ton of new entrants to the market, and they fill demand, but demand levels off sooner or later, and that leads to the low-paying oblivion you're talking about.
I point all this out because there's nothing magic about deep learning, AR, etc. They may not be high paying niches for long. And already, the most-reliable/highest-paying opportunities seem to be working in small groups serving defined markets.
If you look at a US English keyboard, you've generally got 47 unique character keys. Let's double it and say there are 100 different characters you can type just using the character keys and shift.
This machine could brute-force crack any 6 character password in under 4 seconds, any 7 character password in just over 6 minutes, and any 8 character password in just over 10 hours.
And that's using the least efficient method known.
Note that using salts don't necessarily slow down brute-force cracking of a specific hash if the salt is known and understood.
I get that the combination of password reuse, short passwords and the fact that some services store passwords in plain text or as MD5 hashes makes it easy to break into accounts once a single service is compromised.
So my takeaway is not to use longer passwords, but to use a password manager and have unique passwords for every service. My current setup is 8 character passwords for online services (easier to occasionally type in manually).
Am I running a risk by not using 12 character passwords?
1) Don't use a really bad password like 'password'.
This one is the most important because it might allow an attacker to compromise your accounts online--that is without compromising the site itself.
2) Use a different password for each site.
This one is important because you don't want a compromise of smallvillelittleleague.org, which stores its passwords in plaintext, to mean that an attacker now has access to your banking accounts.
3) Use 2-factor on high importance / risk websites.
4) Use very strong passwords everywhere (i.e. long randomly generated).
If you've done 1-3 above the scenario where having a very strong password over a medium strength password is of concrete benefit is fairly narrow. It requires that the attacker get a website's password hashes, that the hash used be a fairly weak one, but that the website not be totally owned (because if it was then there's no additional benefit to having your site specific password).
All IMO of course.
You can also go the route of using passwords like:
MyEmailIsFromGmail!
or
HackerNews?MoreLikeSlackerNewsUsing a password manager to generate random passwords you get a way to be impervious to dictionary attacks, in addition to being able to generate and manage longer passwords. I'm generally using 20 char passwords, and I'd turn it up further if there weren't so many stupid websites that limit the max length of passwords to 20 characters.
For passwords I need to type, especially if I need them occasionally on a touch screen tablet, I'll use a long all-lowercase letters password. Some of them have a 'make pronounceable' option as well that gives random syllables and makes typing a 20 char password easier than typing an 8 char password of completely random characters. 20 chars of lowercase alpha is a lot more secure than 8 chars of mixed-case alphanumeric and punctuation.
For online services (e.g., HackerNews), what's the scenario where an attacker cracks an 8 character password in 8 hours? I assume the attacker would need to download a copy of the service's password store and in that case the service has been hacked to a degree that the attacker won't need to crack passwords anymore.
The other side is to use a fairly expensive hash, and methods to mitigate/reduce use of a login system as a DDOS vector... having the system, and database used for authentication separate from your actual application is a good start, as is exponential backoff on bad passwords by IP and username.
Moving to a separate "auth" domain that returns a signed or encrypted token, and having that in isolation won't stop your processes from running if you get too many requests for auth at once. Having an exponential and random wait before returning from a failed login is another. Keeping track of IP/user requests in an N minute block is also helpful.
token re-auth may be on the auth domain, or the actual service domain, so that can be different.
Servethehome is including colocation rental costs (which also means colocation power cost, typically 3x utility markup) in their cost-per-hour estimate here.
http://www.datacenterknowledge.com/archives/2013/01/17/ovhs-...
Don't expect much rotting that far north. It will take centuries to even start to rot. Also don't expect underwater logging either. This is the Boreal forest, not the rockies one. It's even past the northern limit for Boreal Cedar, the only mildly valuable tree you might find. After that, you get young evergreen and pine. They burn before they get old and grow slowly due to the climate.
Further, tiny dams produce very little power. So, if you play with the numbers you can get extremely different results.
On the other hand if you look at the annual 13,100 GWh from https://en.wikipedia.org/wiki/W._A._C._Bennett_Dam times the 49 years it's been in operation that's the equivalent of (1,000,00 kg / GWH from coal) * 13,100 * 49 = 707,573,630 short tons of CO2 which is vasly larger than all the biomass in the lake to start with. Further, you can log the land before you start minimizing the total biomass flooded.
There is also a windfarm about 10 minutes from there, and they also have access to the regular hydro quebec power grid.
That location in beauharnois was very strategic... cheap land, hydro dam right beside, near the hydro quebec main transmission line for US interconnect... only thing they were missing was fiber but they brought it in.
On the other hand, in CA more rack space was relatively cheap.
[0]: http://chicagoloopster.medill.northwestern.edu/2012/01/27/so...
Ah, that explains a lot. I recall seeing that AMD cards are being used for most of the Bitcoin / Etherium stuff right now, so I thought it was odd to see team-green used in this case. IIRC, AMD cards have faster integer performance, but are slower in floating-point than the NVidia cards. Password-cracking is primarily integer-based however, soooooooo...
But since they're actually building a Deep Learning Platform (and while waiting for other stuff... using it to quickly-test a password cracking solution), these benchmarks make sense. Plus, its an interesting datapoint in any case.
I do wonder what the AMD-cards would do however. Whether it'd be more efficient, or faster... (or hell: maybe conventional knowledge right now is wrong and NVidia is faster)
That single low level detail meant that AMD destroyed Nvidia when it came to computing hashes quickly because the innermost loops of those algorithms contain a ROR.
Since then the situation has changed, NVidia has improved their performance but bitcoin mining has moved to ASIC almost entirely and for other algorithms AMD still seems to come out ahead of Nvidia.
For deep learning the situation is reversed, there it is almost entirely Nvidia, a major reason is that Nvidia put substantial effort in low level libraries that get the maximum out of their hardware for deep learing applications.
The author didn't mention the work factor so I don't know how comparable the results are. But I thought the merit of scrypt over bcrypt was that it was memory hard, i.e. hard to run on a GPU. It doesn't seem to be the case.
Contrast this with scrypt which writes memory (typically megabytes) only once, and a byte is read, on average, only once.
bcrypt and scrypt are both, at the moment, memory hard on GPU, but for different reasons. bcrypt reads/writes many times a small buffer. scrypt reads/writes once a large buffer.
Don't pay too much importance on comparing the hash/sec of these 2 algorithms in this specific benchmark. The configurable work factors influence speed a lot.
One day L2 caches will be big enough and we will see a sudden massive cracking speed improvement for bcrypt. This isn't going to happen anytime soon for scrypt.
Scrypt difficult is 128 bytes × N_cost×r_blockSizeFactor [3]. The "standard" parameters 16384 = N blocksize = 8 results in 16MiB of memory per instance.
On a 512MiB GPU that was only 32 instances in parallel. A modern 1080Ti (with 11GiB) that can be 704 instances. Now we're cooking with gas. Moore's Law it happens.
[1] http://www.anandtech.com/show/2744/2
[2] https://www.evga.com/products/productlist.aspx?type=0&family...
[3] https://stackoverflow.com/questions/11126315/what-are-optima...
It's not really the author, it's the Hashcat benchmark which they've just straight run onto the system, there's the exact same problem with e.g. PBKDF2:
Hashtype: PBKDF2-HMAC-SHA256
[…]
Speed.Dev.#*…..: 14417.6 kH/s
Hashtype: Django (PBKDF2-SHA256)
[…]
Speed.Dev.#*…..: 729.6 kH/s
Hashtype: PBKDF2-HMAC-SHA512
[…]
Speed.Dev.#*…..: 4974.7 kH/s
Hashtype: OSX v10.8+
[…]
Speed.Dev.#*…..: 147.2 kH/s
8x AMD R9 290X https://gist.github.com/epixoip/8171031
8x GTX 980 https://gist.github.com/epixoip/c0b92196a33b902ec5f3
8x GTX 1080 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
My GPU was able to try 20GB passwords in a couple of minutes. That was the largest password list I’ve found on the internets.
However, neither system can brute force even a short 8 characters password. If the password is lower+upper+digits, that’s (26*2+10)^8=2.14E+14 passwords. This number is way out of range even for a PC with 8x 1080 Ti.
Those GPUs are only useful in a very small number of corner cases.
https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
To test 2.14e14 passwords, you need 4.5 hours.
Add a single extra character to that password and the time will become too long regardless on your hardware.
The best way to crack a password isn't to brute-force it first, it's to first analyze who made the password, and the password system, to narrow down all possibilities before you try brute-forcing.
Example; if a person is American, you can pretty much assume they're restricted to the typical US keyboard and its symbols, for 90+% of the population. Very few people know of ALT codes or unicode or even the character map, even in IT. That narrows your symbol subset down dramatically. System for passwords truncates after 12 characters, has a minimum of 8? You already know you don't need to try doing anything with more than 12 characters, and you can limit your password cracking to starting with 8 characters and ignore anything with fewer than that. That eliminates a whole slew of brute-forcing that is required, as you've now narrowed down the password range.
All it takes is a little thinking. Man can make it, man can break it, there is simply no exception.
> Man can make it, man can break it, there is simply no exception.
Nice platitude, but this is simply not true.
You got an example of anything man has made that man has not broken?
"I believe the poster upthread already considered only restricted characters (upper + lower + digits), so the difficulty they stated is what remains after your analysis."
No it's not, because they didn't think of things like password truncation (which my bank annoyingly does) and various other things.
I tested it. It took me almost an hour to crack my chosen mixed-character + symbol 15 character password with a GTX970 implementing the few rules I stated above. Howsecureismypassword.net says it would take a computer 16 BILLION years to crack.
My point very firmly stands.
I can understand why you were doubtful if you were off by 33x.
Password matching is the low hanging fruit, I usually run them on a regular server.
Where you need the large GPU workloads is in applying rules to these lists and in generating variations. There is also work in generating the rule files themselves.
The good rule sets like dive[0] have 1.2M+ rules[1]. Run that again through your 20GB list and you'll see quickly why you need many GPU's :)
[0] https://hashcat.net/wiki/doku.php?id=rule_based_attack
[1] you don't need that many rules, it is very rapidly diminishing returns after ~60% cracked and thousands of rules.
Would love to see numbers for Argon2 :)
7zip amazes me. It hasn't been regularly updated for years, and still comes out on top of most benchmarks. And yet I find that many, if not most, people on Windows use WinRAR.
It's good software, easy to install, easy to use, and it doesn't nag the user with warnings about licensing. I don't quite understand how WinRAR got popular in the first place with that kind of competition.
(Actually, besides portability and interoperability, there's probably no good reason to use SHA-anything over blake2. Although if you are working in environments that provide hardware crypto support (Intel SHA Extensions on Atom, now also supported on Ryzen so maybe we'll see it on the desktop, too), SHA becomes faster than blake2 and you should use that instead.)
If at any point you find yourself in a situation where your hash being computed too fast poses a security risk, that should be a HUGE warning. Hashes should be fast, cryptographic or otherwise. If you need a "slow hash" you are probably looking for a derivation algorithm and not a hash and should be looking at scrypt, bcrypt, or even pbkdf2.
[...] When using 128-bits, the x86 and x64 versions do not produce the same values [...]
which will make it unsuitable for cross-platform applications. I was talking about a usecase where you could also choose CRC32 from a security standpoint but want more collision resistance. How does blake2 performance compare to MD5?
-Austin, Murmur author.
that makes it actually a viable alternative to MD5