101–110 of 113 posts
Earlier quoted context omitted.
What's caused the price to rise so much the past few months?
erethium yes, but other factors too: 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
I wonder what happens to all of the old cards that are replaced every generation? Would be nice to snag a couple of those off of eBay.
They're there and unbelievably cheap. Just wait for the inevitable death of GPU mining again.
Earlier quoted context omitted.
Semi-sorta. It did involve flooding huge amounts of Quebec, so there are consequences and greenhouse gas emissions due to rotting trees, but it's a different sort of equation.
If you compare X vs 1/10,000th X then the emissions from the second option are effectively meaningless.
Earlier quoted context omitted.
If you compare X vs 1/10,000th X then the emissions from the second option are effectively meaningless.
Ah, apparently it's a much more significant factor in warmer climates: https://www.internationalrivers.org/campaigns/reservoir-emis...
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.
Earlier quoted context omitted.
As a non-infosec guy, could someone shed more light on the implications for end users? 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 serv…
I'm personally convinced 8 chars is now too short to be safe, and I suspect real attacks are generally much faster than 8 hours for a password of that length. Using 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…
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.
Earlier quoted context omitted.
Password managers are good but long passwords and password managers are better. If we are assuming MD5 then yes an 8 character password is not secure if someone is targeting you as it would take 10 hours to crack. If someone has a entire database of users let's say 50,000 users all with 8 character passwords then that would take 57 years to crack every password, so you may or may not be in the unlucky few that are at…
That 57 years is assuming they're storing their passwords MD5 hashed, with a salt (hah, i'm sure they thought of that if they're using MD5), and using the least efficient method possible to crack the passwords.
bcrypt: 21kH/s scrypt: 750kH/s 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.
The notion of scrypt being "memory hard" is from 2009. This is when GPU just started supporting 1GiB of RAM [1] 256MiB and 512MiB models were still common place. The 1080Ti supports 11x that [2] its a far cry to buy a GPU that doesn't support at least 4GiB. 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 512M…
In 2010 I built an 8-GPU machine[1] (4 dual-GPU AMD HD5970) and wrote an MD5 bruteforcer (then faster than hashcat), doing 28.6 then 33.1 billion passwd hashes/sec with a software optimization: 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…
> incidentally posting this machine on HN is how I got pointed to Bitcoin thanks to the reply of a HN user :) Mining in 2010 with such a machine. That must have yielded a considerable ROI.
Earlier quoted context omitted.
Slightly tangential but: 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.
I've never had file associations working with 7z on any machine. :/
Earlier quoted context omitted.
> 4) Use very strong passwords everywhere (i.e. long randomly generated). You can also go the route of using passwords like: MyEmailIsFromGmail! or HackerNews?MoreLikeSlackerNews
Note that HackerNews?MoreLikeSlackerNews has much less entropy than j-9yh`qw#j54-JIR$