colonelxc

Williams is a (highly ranked) private liberal arts school[1]. That alone will significantly bias the results of this data. I'm sure a good chunk of those people chose Williams just so they could have a prestigious school to get their undergrad degree from for their application into law school.

[1] http://en.wikipedia.org/wiki/Williams_College

Not the OP, but it seems that my comcast IP stays pretty stable (for months on end). Also, I know that namecheap (and possibly others), provide a dynamic dns type api to update their nameservers if your ip does change.

Certainly you wouldn't want to host something too important on your home network, the odd mumble server or webpage shouldn't be too big of a problem.

  > If you are using PHP also bare in mind that a common default is for all sessions to be written to /tmp which is world read and writeable. So if others have access to your server they can steal or destroy sessions easily.

I'm slightly confused by this, within the context of this article. Yes, /tmp is readable and writable by all, but that doesn't mean that everything in it is readable or writable to other people. The sessions that PHP creates will be owned by the webserver user (nobody/www-data/something else), and shouldn't be readable or writable by other users.

This is still a problem with shared hosting, where you might have multiple websites running on the same server. One shared host would be able to read another's sessions, because they are all running under the webserver's user. This[1] suggests overriding the session_set_save_handler and writing to a resource that only you control, such as your DB.

[1] http://phpsec.org/projects/guide/5.html

I think there is a bug in the 'off' function (though I haven't had the chance to run it yet).

    # Read from the array, and remove files from /etc/hosts
    for site in $*; do
        sed -i '' "/127.0.0.1 $host/d" $hosts
    done

it should be $site instead of $host (the latter is never referenced elsewhere in the file)

That is not what this is.

These are benchmarks on running applications on the same piece of hardware, after compiling with two different compilers.

I think that one of the reasons it is not implemented is because it is a problem that isn't purely technical in nature. So you want to lock people's accounts to prevent brute forcing? There are still a bunch of decisions (both business and technical) before you can move forward.

  1. User support.  How willing are you to deal with increased need for customer support when they start locking themselves out of their accounts after a dozen failed attempts?
  2. How do you keep track of the number of failed attempts?  Another column in your database?  I don't run any big websites, but it seems to me that if an attacker can cause a write to your DB for every POST he can throw at you, your website performance will suffer.
  3. If it takes a dozen (or a hundred (or a thousand)) failed logins to lock an account, it would be trivial for an attacker to lock users out of their accounts, DOSing your site in a different way.
  4. Ok, so we block IP addresses instead of accounts?  Now we have to deal with issues of shared or easily changed IP addresses (or botnets that can afford to have hundreds of thousands of IPs blacklisted from a site and still keep brute forcing).

A lot of these issues are surmountable, but not until you do some basic threat modeling to decide what you want to protect against.

Maybe you decide to focus on preventing from attackers coming from one IP from slamming your site, so you keep an in-memory table of number of recent failed logins and perform temporary bans. It wont protect against botnets, but hopefully you are paying attention to what is happening on your site, and can make changes if that becomes an issue.

> yet most password security guidelines still warn against what they consider brute-forceable passwords.

Your password should be hard to brute force, regardless of whether or not the site protects itself from brute forced logins. The other big danger is that someone hacks the site and gets a dump of password hashes. Then, it doesn't matter what anti-brute force techniques the website is using if the attacker can perform an offline brute force attack against your hashes.

Hashing would make this technique less useful, but not necessarily useless. For instance, if there is no salt involved, and the hashing algorithm is known (or guessable), you can still make some use of the information leaked.

The difference is that you are not being leaked information about the password, but about the hash of the password. One problem with trying to brute force an authentication over the internet is that it is slow and potentially noticeable by the server admin (then you get cut off). If you exploited a timing attack from a comparison between raw md5's or sha1's of a password, then you can use the leaked information to focus your brute force. Basically, you could use a rainbow table to help you pick what passwords to try next, getting a lot more bang for your buck. In this way you can use the combination of offline brute forcing to generate possible hashes, and the timing attack to select which passwords to actually send.

Now an unknown salt would still ruin your day, just like it is designed to make life difficult for rainbow tables in the first place.

Most code executed on my box comes from package managers, which often use code signing to make sure you're getting the right code. Other than that, we often have to depend on the reputation of the project, otherwise we would be stuck reading code all day, instead of getting work done.

The difference here is that this is not some long standing and reputable project, but instead just something that was randomly thrown up github.

tl;dr - I trust the Mozilla Foundation more than I trust jtwaleson

georgieporgie:

It appears you have been hellbanned (as of this comment: https://news.ycombinator.com/item?id=4026814 ). You might be able to appeal it by emailing pg, or just create a new account.

I don't know anything about this breach, but I did find this[1]. It doesn't really have much more data, but it does include a link to a ca.gov site hosting a sample letter (which probably looks nearly identical to yours).

As far as the credit watching goes, it is not uncommon. I know of a college that lost a bunch of student information did the same thing. Basically the school (or company in this case) in question pays one of the credit institutions to give everyone affected a year of credit monitoring service. I don't know if it actually helps the company in terms of liability, but at least it is a positive PR decision.

I'm not sure why they don't suggest cancelling the card. Maybe someone like AmEx is afraid of people leaving them completely instead of just getting a new card? Feel free to call AmEx and get a new card. Can't hurt, right?

And finally, no, security breaches like this usually are not made public. Actually, it is suspected that most breaches are not reported to anyone at all. For companies that do decide to comply with disclosure laws, they send out letters like this, but usually only to the potentially affected customers (not publicly). When you see something like this in the news, it is either the rare case that the company did announce something publicly, or the more common case where someone like you receives a letter, then runs to the nearest high traffic blogger/news source to report the story. As you can see on http://datalossdb.org, there are multiple incidents being reported every day.

Good luck!

[1] http://datalossdb.org/incidents/6752-amex-notified-company-t...

Let me guess: HTC Thunderbolt?

I have one too, with unlimited data. It seems they are only killing the plans when people upgrade to new phones, which would give us some extra time before our next upgrade.

That said, I am interested in how much these shared plans will cost. I would be much more likely to buy a tablet with data capabilities if I could just include it in my regular plan (knowing verizon, probably with an extra 5-10 dollar per device fee). Otherwise, I would just get something with just wifi, which does limit the usefulness.

I'm not sure who you are referring to when you say "they", but there is an Android IDE for building android apps already on the Play store:

https://play.google.com/store/apps/details?id=com.aide.ui...

I've only done some simple hello world type programs, but I was impressed.

If you're looking for a Ubuntu preloaded laptop, you can take a look at System76 ( http://www.system76.com ). They only make Linux computers (laptop/desktop/server), though they don't sell through Amazon.

Original discussion: http://news.ycombinator.com/item?id=3810058

re: medical record sharing

I don't think it is that ridiculous really. Assuming that the policy to require a signature from the patient stands, fax seems like a pretty natural choice for sending a paper form. Alternatively, they could take the time to scan the form then email it.

Ideally, both you and I would probably prefer something completely digital (both forms and health records). Towards that goal, I think the biggest problem would be interoperability. Someone like Kaiser could (and maybe they do) use all digital things between themselves, because they can enforce a uniform software platform.

One nice thing that I've seen about some digital medical record systems is that they print out nice reports. That is a good fallback system, so that you can still fax or email simple documents around.

Even if they're not being paid much of a salary, anyone who lives in a team house doesn't have much in terms of costs (no rent or utilities, and probably most of their food is provided). What this means is that the mid-tier pro's might not be putting much money into the bank, but they also are living comfortably.

Not the author, but from the description, you can only request one check at a time. When you get the results of your current check back, you get a new token.

I'm guessing that the server got too busy to serve a request, either the last request, or any previous one, so that you broke the token chain. Another possibility could be a bug with the timing of events, such that it doesn't realize the field has changed.

The author seems to be lurking around here, maybe he'll have a better idea.

The warning is appearing for me (FF 10.0 on Ubuntu 11.10). It might have just taken time to propogate.

To be fair, for Windows and many Linux distrubutions (don't know about OS X) have signed packages, so it's not like they're grabbing any data and blindly running it.

While I too think that market segmentation as it exists for digital goods is stupid, I don't think it is done just for the money.

Different countries have different laws, different taxes, and your home country has different treaties and export control regulations that all need to be accounted for when selling to other countries. In some cases there could be markets/services that abstract some of this away, but it is not a trivial problem.

If it was trivial to do, then the only segmentation you would see would only be differentiating on price (getting the most that someone in that region would pay for it), instead of not selling it in those countries at all.

Now, the RIAA/MPAA has deep enough pockets and plenty of lawyers that they could have figured all this out for themselves already, and could have built a great online distribution system for themselves. So for them, segmentation is purely a play for money, though (hopefully) it will hurt their profits in the long run.

That depends entirely on the terms of the engagement. If this service (or others) had agreeable data retention/use terms, then the pentester and the client could include that as an acceptable use of their data.

I'm not a web developer, but hopefully I can point you in the right direction. If you're comfortable with Python, then I can point you to the popular Django[1] web framework. Though really, if you've barely used Python, then it would probably be equally easy to get started with Ruby and Ruby on Rails[2] instead. Like I said, I'm not a web developer, but I know both frameworks have lots of support and information out there, including tutorials. I highly recommend following through with some tutorials first, just to get yourself accustomed to how the platform works.

As far as your actual idea goes, I saw the keyword "privately". Now when you first start out and it is just you and your girlfriend, then privacy is easy if you two are the only ones who can access the site. Presumably other people would also want to make sure that not even you, the site administrator would be able to view their uploaded videos. That is probably going to mean encryption, and the mess that comes with it. Colin Percival has a recent blog post[3] about designing apps and services so that the users don't have to trust the developers.

In the meantime, a quick and dirty solution would be to have a Dropbox account that the two of you share, so when you place a file in the proper directory, it automatically gets synced to the other person. You could even encrypt the videos locally before putting them in the Dropbox folder. (You'll probably have to move them from the Dropbox folder to elsewhere after the sync, or you'd quickly fill up the 2GB limit for free accounts).

[1] https://www.djangoproject.com/ [2] http://rubyonrails.org/ [3] http://www.daemonology.net/blog/2012-01-19-playing-chicken-w...

The police were already announcing that people marching through the streets and blocking traffic were going to be arrested anyway, so it's not like marching silently would save them from the threat of arrest.

Speaking of errors in computer forensics:

http://wordpress.bladeforensics.com/?p=357

Hmmm, I hadn't thought about the social aspect before. Now that I think of it, I do sometimes have a hard time being social after being deep into some complicated problem.

The story about the chickens and planes was fascinating. In those cases, there obviously is something that the brain can detect that differentiates the different sets, yet is something so subtle that the conscious mind cannot readily identify it.

I'd be interested to hear if "muscle memory" like this is used in machine learning/AI type situations for things such as evaluating and tuning randomly created classifiers to identify objects, or respond to stimuli. If so, we could extract those "memories" from the computer to identify exactly what it ends up using to classify different objects, to show us the subtle differences.

I agree with you, though I think that a big reason they haven't done that is that the streamers who use justin.tv the most don't actually demand that feature (though they probably wouldn't mind it either).

I don't have any hard stats, but I think that a majority of justin.tv's traffic is gaming related. In my observations, a single gamer can produce hours of content a day, most days of a week. For these types of streamers, it is more of the exception than the rule that someone will go back to watch the stream.

In the case that there is an interesting game that people want to link to or whatnot, they do end up passing around crazy urls and mentioning time offsets. If it is a really popular thing, someone will rip it off of the site and post it to youtube.

One commonality that I see (at least for the partnered streamers) is that in between games, they will run a commercial (they have the ability to choose when commercials happen). That would be a natural point to split the video on justin.tv's side, and then you could at least directly link to a particular game. Giving the ability for streamers to title a video after it is completed would help discoverability as well.

That is not the same thing as what this article is talking about. Remote wipe has been available for some time through different methods.

What is being done here is an "enterprise" type integration, that data put on the phone is kept track of and if the phone leaves a "secure" area, then the tagged data can be automatically wiped.

This enables some different models for wiping that might be more fluid then the "nuke it from orbit" option. By tagging specific pieces of data as sensitive (and performing information flow analysis to track wherever that data gets propogated to), they can target the wiping to just the sensitive data. So before you even realize a phone is stolen, it can be securely wiped.

Another interesting use case is to automatically wipe the sensitive data whenever leaving the workplace, or perhaps some radius around work. That way, whenever you go on travel (or even just home for the day), the sensitive data is wiped, but say your contacts, personal email, and other app data could be retained, leaving it as a perfectly functional smartphone, without any of the company's data to lose.

Holes in their technique include simple attacks like turning the phone off (and pulling the SD card), but hopefully the sensitive data is also encrypted whenever it resides on disk.