jgeralnik

You can use http://hnnotify.com/ to get a notification.

Yeah. That's supposed to be giga.

The systems we use now use salts. If they don't they are doing it seriously wrong.

See Jonathan Pollard for example:

http://en.wikipedia.org/wiki/Jonathan_Pollard#Sentencing_and...

Finally got the silly regex. To align poor_style in vim with the tabularize plugin:

:Tab /\S\s\zs[ ]\S*

Explanation: \S\s* finds a non whitespace character followed by as many whitespace characters as possible. This brings us to the beginning of the variable name. We then use \zs which says that the "found" area should only begin here.

Since we want the * in block_style to be attached to the indented word but not before the variable name, we match either * or space followed by a non-whitespace character to symbolize the beginning of the word. End result:

  void poor_style()
  {
    up_front                declarations;
    also                    encourage;
    this_ridiculous        *block_style;
    that_is                 a_royal_pain;
    to                      maintain;
    because_some_long_type  inevitably;
    screws_it               up;
  }

Direct link to the video: http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_36...

or http://www.rebelliouspixels.com/downloads/Buffy_vs_Edward_36...

  the first Gulf War in Iraq was won because a Lisp application took care that US soldiers had everything from toilet paper, ammunition to gasoline

The word because means that if there was no Lisp application the war would not have been won. This is almost certainly false, even if the Lisp application did make things easier.

Just because supposedly a piece of software performing a critical purpose was written in lisp does not mean lisp won the war.

If the software wasn't written in lisp, it would have been written in any other language.

And if the software wasn't written at all there would have been hundreds of people doing the software's work manually instead.

Did the software help? Probably. It's likely there would have been more screw ups if there was no software. But it takes a big leap to credit the software with winning the war.

Not necessarily anything to do with YC; the vulnerability was discovered and posted on twitter shortly after last week's vulnerability.

Of course it's not considered a smart idea. That's why this was fixed. It was a (critical) bug.

That's how this vulnerability came to light. After finding out about the last vulnerability, there was a huge amount of interest in seeing if parameters could be exploited, leading to a number of people simultaneously discovering this flaw.

If you wait a couple of weeks you are much more likely to get an answer. Since all rails apps were vulnerable, most people who know how to execute arbitrary code are keeping silent for now.

Yes, it's just

  :r!howdoi python regex

:r! executes a command and inserts its standard output below the cursor

But you also have to store the index at which the image occurs, and the index is bigger than the gains from the compression.

This is similar to the argument that since pi is (probably) normal, any sequence of characters appears in it and we can simply use indexes into pi instead of storing numbers.

The problem is that given a file of size X, that sequence of X bytes probably only occurs at more than 2^X places into pi.

Obviously you can create a machine which already has the original file on it, and have your "decompressor" simply print out that file.

I think that it was an unwritten requirement that it would work on Goldman's computer, and I think even people who say that Patrick's technique was legit would agree with that.

The file is not really random, though, since Mike generated it and had time to make sure it was a "good" file before sending it on.

That is, if the file was truly random, it would have a chance of 1/(2^X) of being all 0, where X is the size of the file. But since Mike would reject that file, the chance is actually 0.

Same for all files with easily exploitable patterns - for example, I am sure that Goldman checked that the file could not be compressed with gzip before sending it.

So the EV is probably not positive, even if there is a small chance that a random file of size X can be compressed.

That doesn't help, because at the end of the day we are running on a specific os and machine. And given that machine, there exists a file of size X which it is not possible to compress because of the pigeon hole principle.

No.

Let's say you have a file of size X. You want to write a program of size Y which will decompress an X-Y-1 sized file back to the original program. Does such a program and file exist for every file of size X?

Using the pigeon hole principle, we can see that it does not. There are 2^X files of size X, but only 2^(X-1) inputs of length Y+X-Y-1. Therefore, not every file can be compressed this way. It doesn't matter what your decompressor is written in or how, you still can't do it.

The problem is in the assumption that the inverse derivative exists, which is true for most functions in the real world but not for all (non-smooth) mathematical functions.

Small correction, not the ration of the energy to the entropy but the derivate of the energy by the entropy - that is, the rate at which the energy increases as the entropy increases.

(Of course, it's slightly more confusing since it's actually the inverse of the temperature that's defined as dS/dE, which is the rate at which the entropy increases as the energy increases, a much more understandable definition. And as the physics professor who taught this to a room of students from various departments said of the transition from

  1/T = dS/dE

to

  T = dE/dS

"The mathematicians in the crowd will be in an uproar now. But we can do stuff like that in physics")

Relevant xkcd: http://xkcd.com/320/

Not connected to github, but look at https://github.com/robots.txt, specifically the first 2 lines.

To be fair, it does escape characters and verify with a regex that the data is actually JSON before eval-ing it.

  joey@j-comp:~$ locate todo.txt
  /usr/share/vim/vim73/doc/todo.txt

Does that count?

He does market his software, and practices everything he preaches on his own software too. But let's look at some numbers.

Let's say that Patrick's techniques can increase profits by 10% compared to an "unoptimized" website. If the bingo card business is worth $X0,000, by selling his own products on optimized webpages Patrick makes an extra $X,000.

If instead Patrick consults for a company that does $X0,000,000 his techniques are now worth $X,000,000. If he gets a percentage of those new profits, he is doing much better than if he had sold more of his own product.

Since creating a business which does $X0,000,000 in sales is hard, Patrick can make better use of his time by finding those existing companies and offering his services that by selling more of his (comparatively low value) product himself.

Unless you make less money writing the book than you would consulting.

Yes, the content is already produced. But putting it all together in a book format still takes time. You need to go over old articles, choose the ones to go in, edit and rewrite where necessary, figure out what order to put things in, add new content, deal with the publisher, figure out typesetting things, etc.

If that process takes him two weeks and earns him $5k but his consulting rate is $5k per week then writing the book costs him $5k in potential income. In that case, writing the book is actually leaving money on the table.

> Similar to Linkedin with 6.5m, we have a real-world case study.

Except that Linkedin's passwords weren't salted.

> When you say "entire password space" you're implying that there's a hard upper limit on the complexity of a user's password

That's why I said "where the password space could be a dictionary attack or a brute force of passwords up to length 10 of letters, digits, and symbols". I don't actually mean the whole key space, just whatever the attacker chooses to target.

> So our expectation is that the easiest 500,000 accounts will be cracked in the first 5.2 seconds by an attacker with a single GPU

OK, I concede that point that in this case the salt is not helping so much, at least for users using the 10000 most common passwords. For the few hundred thousand users users whose password lies in a larger key space (but still in the range of bruteforce), the salt still protects them.

Getting back to your original point

> Modern password cracking has all-but obsoleted both of these reasons [for having a salt]

Let's look at a better hash function - bcrypt. In this case hashing passwords is still slow enough (by design - you can slow it down to whatever you want) that rainbow tables would again be useful - to compute the hash of 10000 passwords with a difficulty such that each hash takes 1 cpu-second to compute will take almost 3 hours. Adding salts makes this a per user operation instead of a global one.

Almost. The result could be something else if it's in the code in the middle. It just won't ever get to whatever's after that return B.

I have a database of 1 million users. Regardless of what hashing algorithm I am using, if there is no salt I just need to hash the entire password space once, where the password space could be a dictionary attack or a brute force of passwords up to length 10 of letters, digits, and symbols. If there is a salt, it means that after hashing the entire key space I only have the password for 1 user rather than all of them. It means attackers must use targeted attacks and slows them down by a factor of # of users. Rather than having all my passwords in a day, an attacker gets access to one user's password per day (over the course of a million days). (Still not a good thing to happen)

This is as strong as SHA-1 plus a salt, which is much stronger than SHA-1 without a salt(but still not a good way to store passwords). The salt does not need to be random, merely unique. Since salts are stored in plaintext in the database next to the hashed password, the assumption is that an attacker has those as well.