What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
You shouldn't be bothered, since it isn't. Which is a problem.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works (like a web app that doesn't die when your wifi does).
That's not the issue, at all. This new stuff could be excellent, yes. But if it is developed without keeping security in mind, it is worthless -- worse than worthless, it is harmful -- in the context of the web. If you don't tackle these (some rather obvious, some somewhat tricky) problems now, rest assured, attackers will tackle them. Successfully.
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level. All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Interesting analysis. I don't agree with it. Security being important in the browser does not stem from the feeling that it should be "more secure" than your regular client-server app. It stems from the fact that you do not trust the server to feed you valid data. Browsers get a lot of crap thrown at them during a regular browsing session; you cannot, by the very nature of it, assume to trust every website linked from everywhere else. As such, since you cannot trust your input, you should assume that it is malicious. This is why security in the browser is important. It's not just the interaction between your browser and Google Mail that's interesting -- it's the interaction between your browser, Google Mail, and the other website you have open at the moment, whose author you do not know. So yes, security-by-default is a lot more important in a browser designed to browse lots and lots of untrusted content without that leading to a local system compromise.
And yes, by that very nature, many browsers have some measures that make them considerably more secure for running webapps and the like than executing native code would be. The design is to not let ECMAscript and other such supplied code screw with your system or other sites you may also be visiting now, have visited in the past, or will visit in the future. This is valuable.
Local storage is an interesting feature. I don't think I will like 95% of the applications it will be used for, but the other 5% might become some truly stunning stuff. So long as those 95 other % don't really, really screw it up.
The flipside of the sandbox-model we currently have with browsers is that many "web-coders" never really bother to look at the implications of security. A lot of ECMAscript out there is absolutely atrocious security-wise, and security concepts on the server side are, apparently, really really hard to grasp for many people. If you give these people more features that can cause greater harm and do not properly put sandboxing into the design, you'll end up with a lot of vulnerable, unprotected code. Right now you "just" deal with Cross-Site-Scripting, server-side SQL injection, etc. -- just imagine how much fun it'll be when you have to deal with local SQL injection, local cross-site-scripting, and the ad you just loaded off of the Slashdot adserver fetching all your site-local storage to their servers -- including all the mail you recently viewed. It'll happen.
Maybe a security deposit to participate. Requirement for participants to show a government-issued picture id, have someone validate it for admittance, and take a picture of the ID and the person before allowing them in.
Have a check-in station at the door. Every participant is going to provide the serial numbers of each piece of electronics they bring in, and your event staff will place a difficult-to-counterfeit RFID tag on each properly checked piece.
Next, watch people not come to your party. It turns out they don't LIKE being treated as criminals. It turns out that serial numbers of stuff is not that easy to figure out, and no other party will require it. It turns out that RFID tags and -equipment are kinda pricey and do jack shit for stuff that's in bags or backpacks (say... a laptop). Want to stripsearch participants too ? Put every bag through airport-security like scanners ?
They will sign an agreement agreeing to a special checkout process before being allowed to leave.
Anyone who does not cooperate with special checkout process properly forfeits their deposit.
Unless that deposit is > the price of the stuff you are about to steal... Big whoopdiwoop. Nobody is gonna post a $2000 security-deposit. Cleaning deposits are probably a good idea though.
The checkout procedure is to inspect all bags, luggage, etc, and any equipment they are carrying.
Any electronic device that does not have a tamper-resistant RFID sticker on it is forfeit, until the database of serial numbers can be examined to determine the owner.
At this point, you are just asking for a jam at the checkout lines. You'll need dozens of people manning them at any party exceeding 300 people to get at least a semblance of movement. Stuff will go wrong, your gear WILL break at the most misopportune times, power of the database machine will go out for some reason or other, etc, people WILL want to get (the fuck) out to catch their train/bus/mommy riding them home, etc.
You simply can't search all bags and crates of stuff. You can check some of the big stuff, and usually your budget will not be enough to cover lots and lots of glitzy equipment.
If the owner is found to be another participant, or the serial number on the equipment has been tampered with, the police are called.
If the item was not properly checked in, then the person is allowed to leave with it.
Have plenty of security cameras (both visible and hidden)
Let's keep in mind the OP asked about a lanparty for 60 people. I would assume those 60 people don't want to pay $150 each just so you can buy lots and lots of security cameras. They also might not love the idea of being filmed while sleeping.
Make sure there is no place to dispose of a RFID tag illicitly removed.
What, "don't provide trashcans" ? At a LAN-Party ? Are you nuts ?
Provide participants some method of locking up their equipment; I.E. cable locks, or some kind of locker/lock box, each participant gets a key to.
This is a good idea (tm). Check in your equipment when you go away/go to sleep, check it out again when you come back.
OTOH, uber-security may actually result in attempts at thievery, just to prove it can be done ("now it's a challenge").
It not just results in such attempts, it'll also result in pissed-off guests (long, long waiting times, being treated like a criminal, etc.), lots of blown money on the semblance of security -- which can still be beaten by a determined criminal (RFIDs have to be removable, and there is really nothing preventing you from removing RFIDs in a dimly lit hall of hundreds of people or in the "privacy" of your clan/guild/etc. There are lots of places to hide stuff. Usually you'll HAVE to have fire-exits open, even if they are not a designated exit.
I regularly run LAN parties at my school and very few things ever go missing. I might come home from one short a network cable, but its not a big deal to me. I wouldn't worry too much about pricey things unless your supplying it. Its kinda obvious if someone is walking away with 2 monitors when they came in with one.
No, it's really not. Not with the stuff people bring to lanparties... Multiple machines sometimes, and crazy amounts of gear. A guy with 2 monitors is seen often enough, and a guy with 2 monitors on a cart is seen a lot to -- carrying stuff out for their friends/clans. Legitimately.
People will generally look after their own possessions. What i would worry about is the venue. If you leave a big mess after, you're responsible for it.
That's a given. With larger lanparties, plan at least one day of cleanup. With really large lanparties, at least two.
Having organized parties as large as 2000 people, there is one thing that will pretty much be true with a party of every size : You cannot possibly guarantee that there won't be any theft at all and maintain a decent party atmosphere (let alone keep inside the budget).
You should, under no circumstances, assume liability over your guests' equipment. They need to know they are responsible for their own stuff, and that you will not be held accountable if somebody steals it. If they cannot watch their equipment for the duration of the party, then that is not your fault. You can, of course, offer a "lockbox"-service -- i.e. offer to keep their hardware secured in a cage or some such which is guarded 24/7; This is pretty much the same model as wardrobe at theaters. You take their bags/hardware, issue them a ticket, and do not release the bags/hardware without that ticket. Make sure you inform yourself on what liability you are taking on (if any), possibly restrict it to a maximum value, and consider insuring yourself against theft thereof. If you do this, make absolutely sure that the station is manned 24/7 (we usually do this near the reception area). Think about policies and procedures for when somebody loses their ticket (they will.)
If you provide the network/power infrastructure (and you usually do), think a bit about how to secure it. If you rent your equipment, inquire about theft insurance. It may well be worth it, depending on what your equipment costs. The most probable time switches, routers, etc. get stolen is when everybody is packing up (at the end of the party) -- it's chaos at that point. Keep an eye on your stuff. We usually devise a monitoring system; if your switches are managed, you can keep pinging them once a second from a central station. If they don't reply two or more times, an alarm goes off (loud, obnoxious, flashy alarm, with the equipment name, number and mapped location on the screen, in red). Make sure you have people in place who can follow up on that stuff, fast. If there is only one exit, it may be easier to check for your "bigger" stuff; smaller stuff is easy to hide in bags, and searching bags is not only really, really timeconsuming, but also kills party atmosphere, potentially lands you in legal hot waters, etc.
Do not assume that people will leave via the designated exit/entrance area. You will most likely HAVE to have a secondary fire exit (or more, depending on the size of the venue). These cannot be blocked or barred. When people leave at the end, they may also use these. Equipment near there is rather high risk. Have people there.
Security "guards" (i.e. guys hired for that specific purpose) are nice for FEELING secure, but they don't actually do much. LAN-party goers don't usually end up in fistfights, and you don't want guards roughing up your guests. It doesn't, of course, hurt when some of your organizing team (you do have a team, right ?) look impressive in person:>
Security cameras don't usually have high resolutions and are easily avoided. You can make pretty nifty time-compressions of them though for the after-party videos.
If you want, you can devise a ticketing/sticker system for high-value items of your guests... I.e. when they check in, give them 3-4 stickers for their equipment and a token to be kept secure (an armband, a badge, that sort of stuff). They affix their stickers to their equipment, and on checkout, you check the stickers against the badge. If you go this road, do keep an eye on speed. Wireless handheld barcode scanners can help. If this process is too slow, your team and your guests will grow frustrated at checkout and eventually not bother with it anymore.
You mention that you do not know the people who are coming. Do you also not know who is coming ? If not, make it a requirement to sign up on your website. Throw in some nifty stuff for that (seat selection, etc.), and people will do it. That way at least you'll have some personal information to identify people with.
I would actually be rather surprised if LimeLight has direct fibre connectivity to ALL of its equipment, and likewise surprised if Akamai had no direct connectivity to any of them. At some point it's just cheaper to have your own fiber/crossconnects than to buy transit or be at the mercy of somebody else's capacity-planning -- and I'm sure they'll also have thought about how to guarantee inbound bandwidth so that possible streams do not get hindered.
Again, this is not to belittle LLNW or aggrandize Akamai. They both deliver decent products, and have huge overlap in their offerings -- and techniques.
Yes, the password could be sniffed. No, this does NOT make the whole system worthless. It very much depends on what attack-vectors you are trying to mitigate. It is perfectly sensible to use unencrypted FTP if the server is on the same, non-internet-facing switch, for instance. Plenty of hosting providers will offer you FTP space to back up your server's data, too -- and it'll never leave their network. The better ones put a secondary interface in a vlan of its own, together with the backup server.
FTP is still quite usable if you do not need encryption -- and yes, there are cases where encryption is just not needed and only unduly burdens the CPU.
It may be useful in the author's case, though -- but even there it's a risk assessment -- what's the risk of his hard disk frying and a cracker deleting his backup server's contents at the same time ? How does it compare to the cost of that backup provider ? Is the trade-off acceptable ?
But yeah, blabber on about inherently worthless stuff.
... And does not even address just a single one of the poster's questions or requirements. It seems you have a hammer, and everything must be a nail. How you got +5 Informative on that... Crikey !
Anything less is just reckless. Tell them to protect your connection or you will get another provider. Simple as that.
By the time you have had that exchange with them, you will have cost them more than you bring in, anyway.
I agree that it's possible to offer encrypted connectivity. It is a bit more work, often not available for resellers, and very often not requested by users. You are the exception (whether that's because most users have no clue what encryption is about or just don't care, I don't know.); mass webhosters do not cater to the exception. The margins are extremely low, so it's not really worth having the discussion with the customer.
Of course, most mass-webhosters will also ban you from their service if you actually decide to use the space provided, citing that you may only use it for a public website or some such bullshit, even after they promise, in writing, that you can use it for whatever the hell you like (Hello, dreamhost !). So to the OP : It may not be cheaper than going with S3, after all. Another option would be "premium" accounts at RapidShare.com (50GB) or MegaUpload.com (250gb) or other such services. Of course you wouldn't want to trust them, but using them for encrypted storage should be fine.
Look at duplicity again. (1) It is multiplatform (Python exists for Windows, as do all the supporting tools; I've successfully run it in cygwin). I'm sure you can put cygwin on a portable thumbdrive or even tailor it so you only have duplicity on there. (2) Is a given, with duplicity. Full GPG encryption and signing, FTP backend (and S3, scp, etc.) (3) Duplicity has variable volume sizes. If you set this to 5MB (hardly giant), you can get away with fetching that when updating(assuming you have the filetree-cache on your local drive; otherwise you'll have to reget that as well) and uploading a small tar with that single change. Duplicity doesn't do individual-file-backup like you may have mentioned; This is not a very good idea anyway, though. If you do not trust your hosting provider, this will give them more information to work with -- sizes of files can give a lot away; identical files are encrypted identically, too. This is a rather sizable information leak. (4), again, is a given.
If you forego the multiplatform-ness, you could use FuseFS on your Linux box and mount an encfs on top of a ftpfs and rsync to that. I did this once with a webdavfs; it works, but is slow.
The problem is FTP. It is an old deprecated protocol that is inherently insecure and even FTP w/ SSL is simply a work around to a broken problem.
You are quite correct, sir. Now, how many hosting providers do you know that do NOT offer FTP ? How many that offer different kinds of upload capabilities ? Calculate the ratio and see why this is still being used. Storage can be quite a lot cheaper if you are willing to work around the idiosyncracies of your hosting provider.
As long as you are using insecure FTP then you are officially screwed and I seriously doubt any company is making product when they know FTP has the SSL option (which is a work around but it works). The real answer to your problem is use a secure protocol like SSH which does everything you just asked for natively.
Actually it does absolutely NOTHING he needs. Remember, the operator of the backup-server is untrusted. It's not "only" the in-transit-data being sniffable that is worrisome, but also the backup service provider; be it because you fear that they might get broken into (hosting multiple customers on the same machine), or that you just cannot legally trust any third party with your highly sensitive databases of personal data (your wedding pictures ?:P)
Now because I just posted two easy answers to your dilemma, tell me why my company would write and sell complex time stamping encrypting whatchyamacallit software for FTP transfers? This question was already answered a decade or two ago.
No, it wasn't. SSH does nothing for data integrity, incremental updates, data authenticity, data secrecy, secure timestamping, etc.
Duplicity does a lot of it, and I'd like to hear why the OP thinks it does not fit this task. It has an FTP-backend, it signs & encrypts, it has variable volume sizes, etc.
Akamai does the exact same thing. Limelight is nothing special. The technique is the same. Any CDN worth its salt will have boxes colocated with major ISPs -- the more, the better.
Furthermore, why didn't it melt the internet ? Oh, that's easy. The Olympics streamed a couple million streams, total. This, in the grand scheme of things, is a nice bit of engineering, but nothing special. YouTube does more traffic than the olympics did in a week, in a day. I don't know what the bigger Apple keynotes got, but I'm sure it's up in those heights, too. I have a vague idea how much BitTorrent traffic there is on the net, and it dwarfs the olympic traffic by several orders of magnitude.
The Slashdot story is a marketing piece for LLNW. They have a decent product, to be sure, but they didn't do anything revolutionary here.
Yup, videos of Jihadists killing American Soldiers can stay up. Videos recruiting terrorists can stay up.
Of course videos that are against Jihad MUST be taken down as well.
Gotta wonder about the people at You-Tube, they really seem to hate freedom.
Blah Blah Blah. This is not about the people at Youtube, it's about copyright laws and the DMCA. They didn't take these videos down of their own accord (and neither would they take those others down unless they were against the terms of use or there was a legal requirement to).
The DMCA has long been abused to suppress free speech. Everybody knows it. Nobody cares.
IMO, therefore, even if the MBTA has no case whatsoever (almost certainly true) they are entitled to a TRO for a few days until the court can read (and almost certainly deny) their application for a permanent injunction. I don't see any major damage from having a presentation delayed for all of 72 hours either (note, if we were talking permanent injunction, it would be totally bogus -- that's a different matter entirely).
The damage is, of course, that DEFCON will be over by then. The students were robbed of their speech and presentation. So yes, the MBTA has unilaterally changed the status-quo -- there won't be a DEFCON speech about their vulnerabilities by virtue of the TRO. Of course, the information will now get much more widespread circulation, but the undergrads in this matter will never get to present their findings at this DEFCON.
Maybe im not understand the situation, but if you attempt to release information that can cause harm to a business or person or society. that speech can definitely be limited.
That is a pretty general, and pretty wrong, statement. I can voice my opinion on a business all day long, even if that harms the business. I can voice my opinion on public figures all day long, even if their polling numbers decline as a result. There are certain limitations, sure, but merely bringing an undesired effect to the affected party is not enough.
Its like calling fire in a building with no fire and someone getting hurt.
No, it's not. These students are not putting people's life in jeopardy.
It seems like in this case, if this information got mass attention there might be some way to construe harm.
There is ALWAYS some way to construe harm. The question is whether it's reasonable.
I mean I can think of allot of ways to fabricate the perception of harm, even though it is unlikely.
And this is the kicker. The MBTA is trying to sweep this under the carpet by claiming outlandish claims of public safety and harm -- when it is plain to see that this presentation poses no such threat.
Im trying to put myself in their shoes, someone or someones do not want to have to deal with this if people start mass circumventing the system...
Too freaking bad, use a more secure system. The undergrads even made suggestions as to how to go about it (which they are not obligated to), and are generally behaving responsibly enough (they are not / were not going to release the checksum algorithm or the keys they found).
money loss, reputations, and the like are surely involved.
And rightly so. You see, it's not the undergrads' fault that the system is shoddy. They did not make it shoddy, they did not do the evaluation before buying it, they were not the implementers, and they do not leave network switches unattended behnind open doors. Somebody else is doing that. The undergrads are just pointing out that somebody else is doing that. If that somebody else loses money, reputation, and the like over this incident, then it is their own fault.
it doesn't matter if it has been done before, this particular event makes stuff like this a hot topic, because people that build or manage insecure systems look really, really stupid to the professional community.
This is no reason, at all, to curtail the freedom of speech of these undergrads. Don't like the criticism ? Don't fuck up like that. If you do, take the criticism.
The whole handling of the matter reeks of incompetence, anyway. Apparently these people never heard of the Streisand-effect (seriously, how many more people now know about these weaknesses, in detail, since the MBTA began to sue ?), have never heard about court documents being on the public record (everything they submit as "evidence" is forever in the public eye), have not even researched whether the materials they are trying to suppress have already been circulated (hint: yes, they have), and likely just encouraged others to re-engineer the reverse-engineering. Those others may not be as responsible as these undergrads and release full details, including encryption keys, checksumming algorithms, ready-made software, etc.
The first rule of cybersecurity is to have physical security. This is not security by obscurity, at all. The DEFCON network is not the focus of the DEFCON conference, so no, it should not be on the front page. Cracking the DEFCON network is not the (primary) focus of the DEFCON conference so no, there should be no need or competition to -- especially since crap like that usually results in packeting instead of actually interesting attacks. You also seem to assume that a post-mortem analysis of a break-in takes a few minutes, whipping up a presentation about it takes an hour or two, and conclusive results as to how to do it better are done in time for a presentation. Talks at DEFCON take a while to prepare.
(Now, if somebody had cracked the network with a new kind of attack they just happened to be speaking about at DEFCON, that would have been interesting:-)
I could get your argument if we were talking about some olympic discipline being duped, with doping, corruption or otherwise, but fireworks are just eye candy. How it gets to your retina is quite irrelevant.
They are talking about the fireworks being fake... You know that giant scroll they rolled out ? Yeah, that was fake too. Mostly. Most of it was a cleverly operated and GIANT LED screen. The actual scroll-part of it was the canvas for the painting. You have been duped if you thought that thing was an actual scroll ! The horrors !
(and quite honestly, at the time I was watching it, I did ask myself how they filmed those fireworks safely; seems like an awful lot of risk to take...)
And by the way, doing it in CGI is also more environmentally friendly: compounds used in fireworks are not always of the most benign sort.
Not really, they actually did light the fireworks;-)
The NBC broadcast of the whole thing was extremely badly produced in other terms though. The announcers/commentators kept blabbering on about things of no importance, the 12 hour TAPE DELAYED edited version of the opening had pieces MISSING (the commercial breaks; nobody had the idea to... you know... pause... the tape), and we all know the countries were rearranged and cut in the parade. One of the very worst pieces of garbage broadcasts so far.
The BBC version was uncut, although the commentators also kept blabbering on (a bit more topical though). However, the male commentator was a tremendous... well... asshole. He kept revealing parts of the ceremony long before they would occur, therefore removing the suspense and surprise -- all in a "I know more than you, just you wait !" kind of tone.
The Australian Channel 7 version was cut a lot less than the NBC version (though some small parts were missing); the commentary was a lot more bearable than BBC and NBC; they had trouble with their audio feed for the commentators for the first 10 minutes, so that worked in their favor. Once they did inject commentary, they had some rather annoying background noise. It was one of the better broadcasts even at that, though.
I hear the CBC broadcast is supposed to have been OK; Gonna have to track down that one; There may also be a decent NZ broadcast. The German broadcast wasn't that good, but not that bad, either.
(And yeah, after having watched the BBC broadcast of the event, I wanted to get a decent quality version to enjoy -- since IMHO, the ceremonies were very enjoyable. Lots of undertones, of course, but the artistry and scale were astounding:-)
While this mechanic may have been debunked, the general capability has been confirmed after the uproar. So yeah, not so much debunked as moved somewhere else in the code.
If it's outright malware that somehow passed Apple's QC, then they'll still revoke it, will not issue further certificates to the guilty party, and since they had to sign up for the program, track the guilty party down and sue them for computer crimes in some form.
Why would they do that ? No trademark got infringed, no copyright either, and no Apple secrets were revealed. Some users got attacked, but that's hardly grounds for Apple to lift the sue-finger.
Easy for you to say, you in your armchair, you who will not get the police pounding down your door, you who will not go to jail or be otherwise subdued, you whose future may not be staked on it.
How about YOU go give their presentation ? The slides are out there.
It's clearly a first amendment issue, and when people allow things like threats from the authorities or bullshit unconstitutional court injunctions to stop them from what they want to tell the masses it only serves to justify the actions of those who would try to stop people from expressing important matters.
Therefore, take up arms and shoot down the government ? Hey, if that's what rocks your boat....
From what i can tell this isn't about public safety at all, it's more about money. If it were about public safety, they would take it seriously and work with these guys to resolve the issues.
On top of that, when these sorts of uses for RFID were being planned and discussed years ago (things like this and passports, etc) many, many people warned that this would occur...
Correct.
Someone needs to take that CD and quickly get the contents onto usenet. It's already in the public record anyway - once the cat is out of the bag it's out of the bag.
Slashdot Mirror
What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
You shouldn't be bothered, since it isn't. Which is a problem.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works (like a web app that doesn't die when your wifi does).
That's not the issue, at all. This new stuff could be excellent, yes. But if it is developed without keeping security in mind, it is worthless -- worse than worthless, it is harmful -- in the context of the web. If you don't tackle these (some rather obvious, some somewhat tricky) problems now, rest assured, attackers will tackle them. Successfully.
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Interesting analysis. I don't agree with it. Security being important in the browser does not stem from the feeling that it should be "more secure" than your regular client-server app. It stems from the fact that you do not trust the server to feed you valid data. Browsers get a lot of crap thrown at them during a regular browsing session; you cannot, by the very nature of it, assume to trust every website linked from everywhere else. As such, since you cannot trust your input, you should assume that it is malicious. This is why security in the browser is important. It's not just the interaction between your browser and Google Mail that's interesting -- it's the interaction between your browser, Google Mail, and the other website you have open at the moment, whose author you do not know.
So yes, security-by-default is a lot more important in a browser designed to browse lots and lots of untrusted content without that leading to a local system compromise.
And yes, by that very nature, many browsers have some measures that make them considerably more secure for running webapps and the like than executing native code would be. The design is to not let ECMAscript and other such supplied code screw with your system or other sites you may also be visiting now, have visited in the past, or will visit in the future. This is valuable.
Local storage is an interesting feature. I don't think I will like 95% of the applications it will be used for, but the other 5% might become some truly stunning stuff. So long as those 95 other % don't really, really screw it up.
The flipside of the sandbox-model we currently have with browsers is that many "web-coders" never really bother to look at the implications of security. A lot of ECMAscript out there is absolutely atrocious security-wise, and security concepts on the server side are, apparently, really really hard to grasp for many people. If you give these people more features that can cause greater harm and do not properly put sandboxing into the design, you'll end up with a lot of vulnerable, unprotected code. Right now you "just" deal with Cross-Site-Scripting, server-side SQL injection, etc. -- just imagine how much fun it'll be when you have to deal with local SQL injection, local cross-site-scripting, and the ad you just loaded off of the Slashdot adserver fetching all your site-local storage to their servers -- including all the mail you recently viewed. It'll happen.
Maybe a security deposit to participate. Requirement for participants to show a government-issued picture id, have someone validate it for admittance, and take a picture of the ID and the person before allowing them in.
Have a check-in station at the door. Every participant is going to provide the serial numbers of each piece of electronics they bring in, and your event staff will place a difficult-to-counterfeit RFID tag on each properly checked piece.
Next, watch people not come to your party. It turns out they don't LIKE being treated as criminals. It turns out that serial numbers of stuff is not that easy to figure out, and no other party will require it. It turns out that RFID tags and -equipment are kinda pricey and do jack shit for stuff that's in bags or backpacks (say ... a laptop). Want to stripsearch participants too ? Put every bag through airport-security like scanners ?
They will sign an agreement agreeing to a special checkout process before being allowed to leave.
Anyone who does not cooperate with special checkout process properly forfeits their deposit.
Unless that deposit is > the price of the stuff you are about to steal ... Big whoopdiwoop. Nobody is gonna post a $2000 security-deposit. Cleaning deposits are probably a good idea though.
The checkout procedure is to inspect all bags, luggage, etc, and any equipment they are carrying.
Any electronic device that does not have a tamper-resistant RFID sticker on it is forfeit, until the database of serial numbers can be examined to determine the owner.
At this point, you are just asking for a jam at the checkout lines. You'll need dozens of people manning them at any party exceeding 300 people to get at least a semblance of movement. Stuff will go wrong, your gear WILL break at the most misopportune times, power of the database machine will go out for some reason or other, etc, people WILL want to get (the fuck) out to catch their train/bus/mommy riding them home, etc.
You simply can't search all bags and crates of stuff. You can check some of the big stuff, and usually your budget will not be enough to cover lots and lots of glitzy equipment.
If the owner is found to be another participant, or the serial number on the equipment has been tampered with, the police are called.
If the item was not properly checked in, then the person is allowed to leave with it.
Have plenty of security cameras (both visible and hidden)
Let's keep in mind the OP asked about a lanparty for 60 people. I would assume those 60 people don't want to pay $150 each just so you can buy lots and lots of security cameras. They also might not love the idea of being filmed while sleeping.
Make sure there is no place to dispose of a RFID tag illicitly removed.
What, "don't provide trashcans" ? At a LAN-Party ? Are you nuts ?
Provide participants some method of locking up their equipment; I.E. cable locks, or some kind of locker/lock box, each participant gets a key to.
This is a good idea (tm). Check in your equipment when you go away/go to sleep, check it out again when you come back.
OTOH, uber-security may actually result in attempts at thievery, just to prove it can be done ("now it's a challenge").
It not just results in such attempts, it'll also result in pissed-off guests (long, long waiting times, being treated like a criminal, etc.), lots of blown money on the semblance of security -- which can still be beaten by a determined criminal (RFIDs have to be removable, and there is really nothing preventing you from removing RFIDs in a dimly lit hall of hundreds of people or in the "privacy" of your clan/guild/etc. There are lots of places to hide stuff. Usually you'll HAVE to have fire-exits open, even if they are not a designated exit.
I regularly run LAN parties at my school and very few things ever go missing. I might come home from one short a network cable, but its not a big deal to me. I wouldn't worry too much about pricey things unless your supplying it. Its kinda obvious if someone is walking away with 2 monitors when they came in with one.
No, it's really not. Not with the stuff people bring to lanparties ... Multiple machines sometimes, and crazy amounts of gear. A guy with 2 monitors is seen often enough, and a guy with 2 monitors on a cart is seen a lot to -- carrying stuff out for their friends/clans. Legitimately.
People will generally look after their own possessions. What i would worry about is the venue. If you leave a big mess after, you're responsible for it.
That's a given. With larger lanparties, plan at least one day of cleanup. With really large lanparties, at least two.
And, to put it more succinctly, not a single one of those petitions has been granted, so far.
Having organized parties as large as 2000 people, there is one thing that will pretty much be true with a party of every size : You cannot possibly guarantee that there won't be any theft at all and maintain a decent party atmosphere (let alone keep inside the budget).
You should, under no circumstances, assume liability over your guests' equipment. They need to know they are responsible for their own stuff, and that you will not be held accountable if somebody steals it. If they cannot watch their equipment for the duration of the party, then that is not your fault.
You can, of course, offer a "lockbox"-service -- i.e. offer to keep their hardware secured in a cage or some such which is guarded 24/7; This is pretty much the same model as wardrobe at theaters. You take their bags/hardware, issue them a ticket, and do not release the bags/hardware without that ticket. Make sure you inform yourself on what liability you are taking on (if any), possibly restrict it to a maximum value, and consider insuring yourself against theft thereof. If you do this, make absolutely sure that the station is manned 24/7 (we usually do this near the reception area). Think about policies and procedures for when somebody loses their ticket (they will.)
If you provide the network/power infrastructure (and you usually do), think a bit about how to secure it. If you rent your equipment, inquire about theft insurance. It may well be worth it, depending on what your equipment costs. The most probable time switches, routers, etc. get stolen is when everybody is packing up (at the end of the party) -- it's chaos at that point. Keep an eye on your stuff. We usually devise a monitoring system; if your switches are managed, you can keep pinging them once a second from a central station. If they don't reply two or more times, an alarm goes off (loud, obnoxious, flashy alarm, with the equipment name, number and mapped location on the screen, in red). Make sure you have people in place who can follow up on that stuff, fast. If there is only one exit, it may be easier to check for your "bigger" stuff; smaller stuff is easy to hide in bags, and searching bags is not only really, really timeconsuming, but also kills party atmosphere, potentially lands you in legal hot waters, etc.
Do not assume that people will leave via the designated exit/entrance area. You will most likely HAVE to have a secondary fire exit (or more, depending on the size of the venue). These cannot be blocked or barred. When people leave at the end, they may also use these. Equipment near there is rather high risk. Have people there.
Security "guards" (i.e. guys hired for that specific purpose) are nice for FEELING secure, but they don't actually do much. LAN-party goers don't usually end up in fistfights, and you don't want guards roughing up your guests. It doesn't, of course, hurt when some of your organizing team (you do have a team, right ?) look impressive in person :>
Security cameras don't usually have high resolutions and are easily avoided. You can make pretty nifty time-compressions of them though for the after-party videos.
If you want, you can devise a ticketing/sticker system for high-value items of your guests ... I.e. when they check in, give them 3-4 stickers for their equipment and a token to be kept secure (an armband, a badge, that sort of stuff). They affix their stickers to their equipment, and on checkout, you check the stickers against the badge. If you go this road, do keep an eye on speed. Wireless handheld barcode scanners can help. If this process is too slow, your team and your guests will grow frustrated at checkout and eventually not bother with it anymore.
You mention that you do not know the people who are coming. Do you also not know who is coming ? If not, make it a requirement to sign up on your website. Throw in some nifty stuff for that (seat selection, etc.), and people will do it. That way at least you'll have some personal information to identify people with.
Only if you also have a picture-perfect 3D-model of Obama's face.
No, this does not invalidate video as proof of anything. Take your hyperbole somewhere else.
I would actually be rather surprised if LimeLight has direct fibre connectivity to ALL of its equipment, and likewise surprised if Akamai had no direct connectivity to any of them. At some point it's just cheaper to have your own fiber/crossconnects than to buy transit or be at the mercy of somebody else's capacity-planning -- and I'm sure they'll also have thought about how to guarantee inbound bandwidth so that possible streams do not get hindered.
Again, this is not to belittle LLNW or aggrandize Akamai. They both deliver decent products, and have huge overlap in their offerings -- and techniques.
Your comment, likewise, is inherently worthless.
Yes, the password could be sniffed. No, this does NOT make the whole system worthless. It very much depends on what attack-vectors you are trying to mitigate. It is perfectly sensible to use unencrypted FTP if the server is on the same, non-internet-facing switch, for instance. Plenty of hosting providers will offer you FTP space to back up your server's data, too -- and it'll never leave their network. The better ones put a secondary interface in a vlan of its own, together with the backup server.
FTP is still quite usable if you do not need encryption -- and yes, there are cases where encryption is just not needed and only unduly burdens the CPU.
It may be useful in the author's case, though -- but even there it's a risk assessment -- what's the risk of his hard disk frying and a cracker deleting his backup server's contents at the same time ? How does it compare to the cost of that backup provider ? Is the trade-off acceptable ?
But yeah, blabber on about inherently worthless stuff.
... And does not even address just a single one of the poster's questions or requirements. It seems you have a hammer, and everything must be a nail. How you got +5 Informative on that ... Crikey !
Anything less is just reckless. Tell them to protect your connection or you will get another provider. Simple as that.
By the time you have had that exchange with them, you will have cost them more than you bring in, anyway.
I agree that it's possible to offer encrypted connectivity. It is a bit more work, often not available for resellers, and very often not requested by users. You are the exception (whether that's because most users have no clue what encryption is about or just don't care, I don't know.); mass webhosters do not cater to the exception. The margins are extremely low, so it's not really worth having the discussion with the customer.
Of course, most mass-webhosters will also ban you from their service if you actually decide to use the space provided, citing that you may only use it for a public website or some such bullshit, even after they promise, in writing, that you can use it for whatever the hell you like (Hello, dreamhost !). So to the OP : It may not be cheaper than going with S3, after all. Another option would be "premium" accounts at RapidShare.com (50GB) or MegaUpload.com (250gb) or other such services. Of course you wouldn't want to trust them, but using them for encrypted storage should be fine.
Look at duplicity again. (1) It is multiplatform (Python exists for Windows, as do all the supporting tools; I've successfully run it in cygwin). I'm sure you can put cygwin on a portable thumbdrive or even tailor it so you only have duplicity on there. (2) Is a given, with duplicity. Full GPG encryption and signing, FTP backend (and S3, scp, etc.) (3) Duplicity has variable volume sizes. If you set this to 5MB (hardly giant), you can get away with fetching that when updating(assuming you have the filetree-cache on your local drive; otherwise you'll have to reget that as well) and uploading a small tar with that single change. Duplicity doesn't do individual-file-backup like you may have mentioned; This is not a very good idea anyway, though. If you do not trust your hosting provider, this will give them more information to work with -- sizes of files can give a lot away; identical files are encrypted identically, too. This is a rather sizable information leak. (4), again, is a given.
If you forego the multiplatform-ness, you could use FuseFS on your Linux box and mount an encfs on top of a ftpfs and rsync to that. I did this once with a webdavfs; it works, but is slow.
The problem is FTP. It is an old deprecated protocol that is inherently insecure and even FTP w/ SSL is simply a work around to a broken problem.
You are quite correct, sir. Now, how many hosting providers do you know that do NOT offer FTP ? How many that offer different kinds of upload capabilities ? Calculate the ratio and see why this is still being used. Storage can be quite a lot cheaper if you are willing to work around the idiosyncracies of your hosting provider.
As long as you are using insecure FTP then you are officially screwed and I seriously doubt any company is making product when they know FTP has the SSL option (which is a work around but it works). The real answer to your problem is use a secure protocol like SSH which does everything you just asked for natively.
Actually it does absolutely NOTHING he needs. Remember, the operator of the backup-server is untrusted. It's not "only" the in-transit-data being sniffable that is worrisome, but also the backup service provider; be it because you fear that they might get broken into (hosting multiple customers on the same machine), or that you just cannot legally trust any third party with your highly sensitive databases of personal data (your wedding pictures ? :P)
Now because I just posted two easy answers to your dilemma, tell me why my company would write and sell complex time stamping encrypting whatchyamacallit software for FTP transfers? This question was already answered a decade or two ago.
No, it wasn't. SSH does nothing for data integrity, incremental updates, data authenticity, data secrecy, secure timestamping, etc.
Duplicity does a lot of it, and I'd like to hear why the OP thinks it does not fit this task. It has an FTP-backend, it signs & encrypts, it has variable volume sizes, etc.
Akamai does the exact same thing. Limelight is nothing special. The technique is the same. Any CDN worth its salt will have boxes colocated with major ISPs -- the more, the better.
Furthermore, why didn't it melt the internet ? Oh, that's easy. The Olympics streamed a couple million streams, total. This, in the grand scheme of things, is a nice bit of engineering, but nothing special. YouTube does more traffic than the olympics did in a week, in a day. I don't know what the bigger Apple keynotes got, but I'm sure it's up in those heights, too. I have a vague idea how much BitTorrent traffic there is on the net, and it dwarfs the olympic traffic by several orders of magnitude.
The Slashdot story is a marketing piece for LLNW. They have a decent product, to be sure, but they didn't do anything revolutionary here.
Yup, videos of Jihadists killing American Soldiers can stay up. Videos recruiting terrorists can stay up.
Of course videos that are against Jihad MUST be taken down as well.
Gotta wonder about the people at You-Tube, they really seem to hate freedom.
Blah Blah Blah. This is not about the people at Youtube, it's about copyright laws and the DMCA. They didn't take these videos down of their own accord (and neither would they take those others down unless they were against the terms of use or there was a legal requirement to).
The DMCA has long been abused to suppress free speech. Everybody knows it. Nobody cares.
IMO, therefore, even if the MBTA has no case whatsoever (almost certainly true) they are entitled to a TRO for a few days until the court can read (and almost certainly deny) their application for a permanent injunction. I don't see any major damage from having a presentation delayed for all of 72 hours either (note, if we were talking permanent injunction, it would be totally bogus -- that's a different matter entirely).
The damage is, of course, that DEFCON will be over by then. The students were robbed of their speech and presentation. So yes, the MBTA has unilaterally changed the status-quo -- there won't be a DEFCON speech about their vulnerabilities by virtue of the TRO.
Of course, the information will now get much more widespread circulation, but the undergrads in this matter will never get to present their findings at this DEFCON.
Maybe im not understand the situation, but if you attempt to release information that can cause harm to a business or person or society. that speech can definitely be limited.
That is a pretty general, and pretty wrong, statement. I can voice my opinion on a business all day long, even if that harms the business. I can voice my opinion on public figures all day long, even if their polling numbers decline as a result.
There are certain limitations, sure, but merely bringing an undesired effect to the affected party is not enough.
Its like calling fire in a building with no fire and someone getting hurt.
No, it's not. These students are not putting people's life in jeopardy.
It seems like in this case, if this information got mass attention there might be some way to construe harm.
There is ALWAYS some way to construe harm. The question is whether it's reasonable.
I mean I can think of allot of ways to fabricate the perception of harm, even though it is unlikely.
And this is the kicker. The MBTA is trying to sweep this under the carpet by claiming outlandish claims of public safety and harm -- when it is plain to see that this presentation poses no such threat.
Im trying to put myself in their shoes, someone or someones do not want to have to deal with this if people start mass circumventing the system...
Too freaking bad, use a more secure system. The undergrads even made suggestions as to how to go about it (which they are not obligated to), and are generally behaving responsibly enough (they are not / were not going to release the checksum algorithm or the keys they found).
money loss, reputations, and the like are surely involved.
And rightly so. You see, it's not the undergrads' fault that the system is shoddy. They did not make it shoddy, they did not do the evaluation before buying it, they were not the implementers, and they do not leave network switches unattended behnind open doors. Somebody else is doing that. The undergrads are just pointing out that somebody else is doing that. If that somebody else loses money, reputation, and the like over this incident, then it is their own fault.
it doesn't matter if it has been done before, this particular event makes stuff like this a hot topic, because people that build or manage insecure systems look really, really stupid to the professional community.
This is no reason, at all, to curtail the freedom of speech of these undergrads. Don't like the criticism ? Don't fuck up like that. If you do, take the criticism.
The whole handling of the matter reeks of incompetence, anyway. Apparently these people never heard of the Streisand-effect (seriously, how many more people now know about these weaknesses, in detail, since the MBTA began to sue ?), have never heard about court documents being on the public record (everything they submit as "evidence" is forever in the public eye), have not even researched whether the materials they are trying to suppress have already been circulated (hint: yes, they have), and likely just encouraged others to re-engineer the reverse-engineering. Those others may not be as responsible as these undergrads and release full details, including encryption keys, checksumming algorithms, ready-made software, etc.
A+.
Blah Blah Blah.
The first rule of cybersecurity is to have physical security. This is not security by obscurity, at all. The DEFCON network is not the focus of the DEFCON conference, so no, it should not be on the front page. Cracking the DEFCON network is not the (primary) focus of the DEFCON conference so no, there should be no need or competition to -- especially since crap like that usually results in packeting instead of actually interesting attacks. You also seem to assume that a post-mortem analysis of a break-in takes a few minutes, whipping up a presentation about it takes an hour or two, and conclusive results as to how to do it better are done in time for a presentation. Talks at DEFCON take a while to prepare.
(Now, if somebody had cracked the network with a new kind of attack they just happened to be speaking about at DEFCON, that would have been interesting :-)
I could get your argument if we were talking about some olympic discipline being duped, with doping, corruption or otherwise, but fireworks are just eye candy. How it gets to your retina is quite irrelevant.
They are talking about the fireworks being fake ... You know that giant scroll they rolled out ? Yeah, that was fake too. Mostly. Most of it was a cleverly operated and GIANT LED screen. The actual scroll-part of it was the canvas for the painting. You have been duped if you thought that thing was an actual scroll ! The horrors !
(and quite honestly, at the time I was watching it, I did ask myself how they filmed those fireworks safely; seems like an awful lot of risk to take ...)
And by the way, doing it in CGI is also more environmentally friendly: compounds used in fireworks are not always of the most benign sort.
Not really, they actually did light the fireworks ;-)
The NBC broadcast of the whole thing was extremely badly produced in other terms though. The announcers/commentators kept blabbering on about things of no importance, the 12 hour TAPE DELAYED edited version of the opening had pieces MISSING (the commercial breaks; nobody had the idea to ... you know ... pause ... the tape), and we all know the countries were rearranged and cut in the parade. One of the very worst pieces of garbage broadcasts so far.
The BBC version was uncut, although the commentators also kept blabbering on (a bit more topical though). However, the male commentator was a tremendous ... well ... asshole. He kept revealing parts of the ceremony long before they would occur, therefore removing the suspense and surprise -- all in a "I know more than you, just you wait !" kind of tone.
The Australian Channel 7 version was cut a lot less than the NBC version (though some small parts were missing); the commentary was a lot more bearable than BBC and NBC; they had trouble with their audio feed for the commentators for the first 10 minutes, so that worked in their favor. Once they did inject commentary, they had some rather annoying background noise. It was one of the better broadcasts even at that, though.
I hear the CBC broadcast is supposed to have been OK; Gonna have to track down that one; There may also be a decent NZ broadcast. The German broadcast wasn't that good, but not that bad, either.
(And yeah, after having watched the BBC broadcast of the event, I wanted to get a decent quality version to enjoy -- since IMHO, the ceremonies were very enjoyable. Lots of undertones, of course, but the artistry and scale were astounding :-)
While this mechanic may have been debunked, the general capability has been confirmed after the uproar. So yeah, not so much debunked as moved somewhere else in the code.
If it's outright malware that somehow passed Apple's QC, then they'll still revoke it, will not issue further certificates to the guilty party, and since they had to sign up for the program, track the guilty party down and sue them for computer crimes in some form.
Why would they do that ? No trademark got infringed, no copyright either, and no Apple secrets were revealed. Some users got attacked, but that's hardly grounds for Apple to lift the sue-finger.
Not even close. $640 should do it, though.
They need to give their presentation regardless.
Easy for you to say, you in your armchair, you who will not get the police pounding down your door, you who will not go to jail or be otherwise subdued, you whose future may not be staked on it. How about YOU go give their presentation ? The slides are out there.
It's clearly a first amendment issue, and when people allow things like threats from the authorities or bullshit unconstitutional court injunctions to stop them from what they want to tell the masses it only serves to justify the actions of those who would try to stop people from expressing important matters.
Therefore, take up arms and shoot down the government ? Hey, if that's what rocks your boat ....
From what i can tell this isn't about public safety at all, it's more about money. If it were about public safety, they would take it seriously and work with these guys to resolve the issues. On top of that, when these sorts of uses for RFID were being planned and discussed years ago (things like this and passports, etc) many, many people warned that this would occur...
Correct.
Someone needs to take that CD and quickly get the contents onto usenet. It's already in the public record anyway - once the cat is out of the bag it's out of the bag.
It's already published on the net.
Right, assuming that none of the viewers buy none of the advertisers' products.
Naive.
Somebody is paying. You may not give the IOC your bucks directly, but you SURE AS HELL are paying for it.