cschneid

There are several areas of space, designated by security level.

* In "High Sec" - you can shoot whoever you want. When you shoot somebody without the right to (ie, they stole from you, you can shoot them), then you have a few seconds (up to ~30) before an invincible NPC navy shows up and blaps you. If you escape, it's a game exploit and is bannable. Not that a few seconds is plenty of time to kill an unsuspecting player (and that does happen and can be profitable, even after losing your ship).

After killing somebody in high sec, your global security status gets decremented. If it gets low enough non-invincible navies will follow you around to try and kill you when you show up in safe space. This is more annoying than anything, and you just have to be careful and keep moving.

* Low Sec: You can shoot anybody, and no navies will stop you. At certain spots, "gate guns" will help out the agressors.

* Null Sec: Anything goes, shoot who you want, do what you want. This is where player controlled alliances live (if you remember reading about Goonswarm and similarly large organizations).

-------------------

It's a relatively complex system, but then again, everything in eve is complex. But fun and deep. The devs are really good about setting rules, and then allowing you to do anything you want inside those rules.

For example, a standard rule of thumb for freighter pilots is to only carry about 1 billion in-game currency worth of goods at a time. Reason? Because it costs about that much worth of ships to blow you up before concord (invincible navy) shows up and kills a group trying to gank your ship. This is just standard knowledge about what is "safe". Which really just means "what would make this unprofitable for people to do to me".

It's about trust. The transaction hits the network immediately. Then a miner puts it in a block as soon as right away, or as slow as... several days (if you put a transaction fee, you'll move to the frontish of the line). Once its in one block, every subsequent block is a vote for its authenticity.

So, if I accept a bitcoin right away, I open myself up to a fairly trivial double-spend attack. If I wait for one confirmation, it's harder, but still sorta maybe doable. If I wait for several (1-2hours), it's near impossible.

Compare with taking cash which may be phony, or a CC which is easily charge-backable, and the business's risk is ... close enough to the same.

No, chef/puppet/etc are configuration management tools. They automate the manual typing of server setup commands, and then verify that the system stays that way.

They are not security tools. So you're on your own on what to actually tell the tools to do. "Install chef" is not a security tip. It's a repeatability tip, so you can get your system up to a known state repeatedly.

For the security side of things, you're back to figuring out what the right steps are, no matter how they're installed.

Re pepper: It's a STRONG password. It turns '12345' into 64 random characters + '12345'. Meaning that you can't brute force against a dictionary, unless you have that pepper value. Which is only stored on the production system. This turns a well-known attack vector of "developer loses a data dump" into something that won't expose passwords.

Re hash: yeah, use a strong hash function. Never advocated otherwise.

Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.

You're right. Throwing shit at the wall can screw things up, and you must still be using a proper full-strength hash, and not just throw crypto primitives at it.

What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach.

What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump.

So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'.

And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem.

That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production.

So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.

IMO, you should be doing both. People should use strong bcrypted passwords, with a salt, then ALSO a 'secret' pepper value (long value stored in app code). This adds additional security in the case of a db-only dump being released, and doesn't harm the strength or a full code+db release at all either.

Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but instead makes it another thing to figure out by an attacker. At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.

Security is about depth, not putting 100% of your trust in a single algorithm. Even if that algorithm is well trusted. It's simply not an either/or.

Well, for this specific issue, it was an executive branch decision that allowed, and now doesn't allow unlocking. Laws are often just "hey, executive, do this", and the executive figures it out (see also: EPA, FTC and lots more).

Damnit, I'm busy fixing the devise issue!

Thanks. Is there a firewall level rule we can use to block requests (in addition to updating rails itself). We have a ton of apps to update, so a catchall rule would be very helpful.

Is there any more info about the severity of this attack? Is this a drop-everything issue? What are the vulnerable endpoints (reading between the lines implies password resets?).

My girlfriend teaches high school. Another teacher there teaches a class sponsored by a local community college.

The curriculum is strict, and the teacher needs a masters to qualify. And then the kids end up with real college credit.

One thing I'd suggest is to learn a vastly different language. If you use ruby all day, learning python probably won't give you the type of insight that learning C would. Or learning a lisp.

So much is looking at things in a different way, and a quick way to do that is by picking something across the metaphorical language town, rather than the language next door.

I'm happy that Nathan is sharing his experience here. It's an interesting project.

My development advice would be to get buildable, deployable (and deployed!) copies of the app early. A new developer's skill often peters out around the edges of the process, so working through those gotchas and hiccups early will pay off when it comes time to launch.

What have you spent money on so far? 500 bucks out the door before development starts seems pretty large, unless I'm missing some consulting time, or tools?

Note the comment about Yaml parsing in 1.1 era rails apps. You'll want to at least look into what your app is doing.

That is correct. The latest 3.1.10, or latest 3.2 series have this update. See the top of the linked notice:

Versions Affected: ALL versions Not affected: NONE Fixed Versions: 3.2.11, 3.1.10, 3.0.19, 2.3.15

Name.com has been my default registrar for a while, and is pretty decent. Recently while renewing a domain, the anonymous registration stuff didn't apply right (paid for 2 years, got 13 months instead. no biggie). Their support fixed it over email in a few minutes, and I was on my way.

I'd recommend.

This idea has been floated before: http://www.freakonomics.com/2010/11/18/freakonomics-radio-co...

Basically just taking all the interest from the loans, and splitting it up as payouts in a lottery among everybody who has money saved.

When my paypal was broken into - it was immediately used to order from a EU based usenet provider.

Paypal reversed it for me, but I wonder how much of this is fraud related?

Options are really cool since they are so well named. They really do give you a ton of options to adjust your risk to exactly what you want.

On one hand, you can have infinite risk strategies, on the other, you can lock in a stock price almost exactly, with little market risk. And then everything in between (ie, you can easily build something that's like: "I think this stock will go up a few bucks, but nothing crazy", or maybe: "I'm worried about a horrible plunge, but a minor decline is fine, I'll buy a put out of the money and have coverage for the plunge".)

And really, it's fairly simple, a lot of the stuff I said about "time value" and such was related to how you value options, not the actual complexity of the thing itself. "How much is this worth" is always tricky, even for something as easy to understand as a bond.

Organized markets, and bubbles, and derivatives are all old. And they aren't inherently bad either.

You have to look at futures & options as a way to sell or buy risk. If you're willing to pay somebody, they'll take your risk away. And the other way, if you want to take on some risk in exchange for money, you can do that.

(note, that last thing sounds scary, but how about this: sell a put [ie, promise to buy a stock at a certain price] right near where you want to buy the stock anyway [with a traditional limit order]. If it gets to below that level, you get 'assigned' the stock, which you wanted anyway, at the price you wanted anyway. If it doesn't hit that, then you wouldn't have bought the stock anyway. The counterparty gets insurance against their stock dropping. You take on the "risk" of it dropping, but you've set yourself up so that it works out for everybody involved).

(note that last strategy doesn't work if the stock temporarily dips, then pops back up. You probably won't get assigned in that situation, where a limit order would have triggered. That risk is what you get in exchange for getting paid for selling the put).

Downside is obviously the 100% loss you'd take on the $400.

Assumption you're making: That FB is overvalued currently, and has 15% to fall (it's at 20 now, and you are saying it will go down by $3 by the 18th [tomorrow!!!])

I'm not sure where that $0.48 is coming from in your comment. At expiration (when an option has no time value), a put should be worth StrikePrice - StockPrice. So if Strike is $17, and stock is... say... $15, the option will be worth $2 ($200 since each option actually controls 100 shares). That math changes with the stock price, so I'm not sure what you're talkinga bout with $0.48...

Also note that spreads at the low end of options will eat you alive. Specifically you should expect to pay upwards of $10 or even $15 to get anybody to fill you on those options. The $4 amount is highly unlikely to get filled, especially at the qty you are talking about.

Basically, this is a bad idea, and will just lose you $400.

I use the 1password pronounceable strings. Still plenty random, but you can say it over the phone to a customer service person if you ever do need.

Coffee also apparently prevents prostate cancer to some degree too: http://www.webmd.com/prostate-cancer/news/20110517/coffee-ma...

For your own safety, go make some now.

Re: pepper - The devise plugin for Rails uses it. The idea is that the attacker must now steal both the app code AND database, which are often on separate servers.

Just make their life harder.

"Cracking" in this sense is brute forcing. SHA1 is fast, and people use bad passwords. The combination means that you can run through lots and lots of bad passwords very quickly. I checked my linked in password I have stored in 1password, and it is 20+ chars with special characters and numbers. That won't be "cracked" in any meaningful sense, so I don't even worry about it.

You are correct that there's currently no way to go from a hash to a value that hashes to it in SHA1 (AFAIK, IANYNSA [I am not your NSA]).

Remember salts don't need to be secret to do their job. The goal is to change the algorithm slightly (by adding additional input) for each user. That means you can't mass-precompute (rainbow tables), and just look up what matches, you have to break each user individually.

Your reasoning about how salts work is correct.

There's also something called a pepper which is another additional bit of input data, that is only stored in the app code (fixed for entire app). So an attacker who only manages to get a database dump would need to guess yet another chunk of data (making it near impossible). So a well-seasoned hash would be SLOW_HASH(pepper+salt+password).

Security is all about layers. Each layer protects a bit more, or prevents things from being easy for the attacker.

Edit: Don't do this yourself. Know it for the theory part - but then just use a well-vetted library to do it.

Steps I used to setup a linode service to do IPv6 hosting:

(running apache, running passenger for ruby)

1) ifconfig to get my already assigned ipv6 address

2) Setup my DNS AAAA record to point to it (for both www and blank).

3) There is no step 3. I could see ipv6 from work and home with no extra work.

I used this extension to check for ipv6 status:

https://chrome.google.com/webstore/detail/hfkjfjdafcickoihmm...

I bought a clothes steamer a while back (Jiffy Steamer), and I was pleasantly surprised that it had a full circuit diagram and component list included in the instruction book. I can take that sucker apart, fix things, and put it back together.

(well, maybe not me, but somebody could).

I am willing to buy more products like that. Where do I find them?

Different compilers will generate different compiled code, even on identical input (ie, clang vs. GCC). So the binary will be different.

tmux keys all remap pretty nicely. The recent tmux book to come out is pretty decent as an intro primer to tmux, getting you going pretty quick