afreak

This was discussed on HN a while back and comes up quite often:

https://news.ycombinator.com/item?id=10905643

http://www.universetoday.com/15403/how-long-would-it-take-to...

>However, despite these advantages in fuel-efficiency and specific impulse, the most sophisticated NTP concept has a maximum specific impulse of 5000 seconds (50 kN·s/kg). Using nuclear engines driven by fission or fusion, NASA scientists estimate it would could take a spaceship only 90 days to get to Mars when the planet was at “opposition” – i.e. as close as 55,000,000 km from Earth.

> But adjusted for a one-way journey to Proxima Centauri, a nuclear rocket would still take centuries to accelerate to the point where it was flying a fraction of the speed of light. It would then require several decades of travel time, followed by many more centuries of deceleration before reaching it destination. All told, were still talking about 1000 years before it reaches its destination. Good for interplanetary missions, not so good for interstellar ones.

There's talk of other drive systems being able to pull it off but this is the only one that actually has been tested but never built to scale.

If you're in a situation where you're needing to rely on hashing a user's password for every action, your application has far worse problems than what password storage method is in play. Moving from your current password storage method that is inadequate to one that would be better also takes into account that you haven't done something completely wrong with session states.

[edit]

I misread the poster I was responding to assuming that they meant that the user was re-authenticating on each request. My thought process was that if they're storing credentials in a cookie in lieu of a session ID then that needed to be addressed first before even going down the avenue of correcting password storage.

Intel Xeon E5-1620 3.6 GHz: SHA: 8.16 seconds, SHA256: 11.01 seconds, MD5: 8.7 seconds

AMD FX-8320 3.5 GHz: SHA: 10.63 seconds, SHA256: 13.49 seconds, MD5: 10.06 second

Intel Celeron N2840 2.2 GHz: SHA: 32.4 seconds, SHA256: 39.75 seconds, MD5: 28.95 seconds

Intel Pentium M 1.7 GHz: SHA: 37.98 seconds, SHA256: 48.12 seconds, MD5: 34.49 seconds

SHA512 isn't going to make it much better.

http://www.pxdojo.net/2015/08/what-i-learned-from-cracking-4...

The author of this piece was doing about 156 hashes per second and after just over five days, he had only gone through and cracked 4,000 account passwords--we're talking 0.0001% of Ashley Madison's supposed userbase here. To run just over the 14,000,000 passwords from RockYou.txt on every single user account from AM, it would take up to at least two billion years.

SHA and MD5 can be calculated entirely in a CPU's registers without having to rely on RAM. Bcrypt for example requires the use of a matrix as part of its calculation, slowing down the process. A GPU has so few channels from the processor to memory that it cannot be effectively done in parallel.

All one has to do with Bcrypt is just adjust the difficulty and any advances in GPU technology or whatever can be nullified.

https://canar.io (mine)

https://haveibeenpwned.com/

Mine lets you free-form search whereas HaveIBeenPwned is there for searching just e-mail addresses.

If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication.

This should be the takeaway from this article.

The point of donating money to the author of the piece is to encourage them to continue writing this epic story. Giving them Bitcoin is akin to leaving a tip to your server where the tip appears to be currency but rather instead is a Chick tract with the suggestion that you'll pray for their soul.

And tell me, how does one cut out the middleman when they convert their Bitcoin earnings to US dollars or whatever currency they prefer?

It is not the responsibility of a network service provider to protect the assets of a customer. If you're given a network link and an allocation of IP addresses, it is your responsibility to use them wisely and securely.

> Or maybe universities and organizations could teach their employees to handle network security better.

This is more sane thinking.

$ cat payload.ps |netcat -q 0 $printer_ip 9100

This is what was originally posted:

https://storify.com/weev/a-small-experiment-in

To travel from Vancouver to the next principal Canadian city (Calgary), it requires 900 KM of driving and there's only really one metropolitan area of sorts between the two, meaning that you're going to be setting up cell towers that handle only so much traffic in a day.

As a result, to get service where you end up with just traffic shaping once you go beyond 6 GB (beyond that there is no real limit really), you need to go with a carrier that only services the larger cities. So in my case, my carrier services just Vancouver, Edmonton, Calgary, Toronto, and Ottawa, which are fairly dense areas with a combined population of 18 million or so, or just about half of the country's population. Once I leave the city, I have to piggyback on to other carriers however.

Hence why mobile carriers suck in Canada because the bigger carriers do not want to eat into their fairly large profit margins. They can afford to offer such plans, but they simply don't want to.

For the record, I pay $40 CAD/month ($30 USD or 27 EUR) for unlimited North American calling and text plus the "unlimited" data use.

Spotify accounts for 2 GB of traffic per month on my phone and some plans are barely affordable when you want more than that--fortunately I can do up to 6 GB before I am traffic shaped, but that isn't the say the same for all carriers in this country.

Generally I recommend that if you think that your password has been exposed that you just reset your password as if you have to ask that question then you might want to reconsider your password reuse.

(I am the creator of Canario)

Every app that runs on your systems with enough privileges can dump the memory and extract information via that.

http://www.cbc.ca/news/technology/faq-the-issues-around-muzz...