skysight-inc/HackerNews huggingface dataset:
Something has to be said for the uniformity of syntax. The lisp reader macro is used throughout the language; I have never used this syntax before (I prefer to explicitly make objects, that way I know if the call succeeded right away) but grepped the PURI sources to see if it had a reader-macro, and sure enough it did. If there was no uniformity, I would have waited for a blog post to tell me something exists.

You are complaining a Lisp URL needs to be quoted to distinguish it from other input tokens; how would you feel when you have more than one URL, say 10, on the screen and all of them are being echo'ed in a debug backtrace without visual aid or syntax highlighting? How about if you forget to delimit one with a space (oops, now you have a syntactically valid URL that's broken; the type checker wont help you verify URLs)

Plus you can "merge" Lisp URLs, forming absolute URLs from a base URL and appending paths to it or building query parameters in an elegant fashion.
The test only counts if an even amount of impressions is given. The viewers aren't given a choice between ad A and B, they have a choice between A (or B) and nothing. I don't think the author explained this well enough. Obviously (to everyone here) the test is inconclusive if one ad is shown much more than the other.
If the conclusions of this study are validated, the food industry is going to be hit by a wave of class-action lawsuits that'll make cigarette litigation look like an amicable chit-chat.

If I was in the market I'd be shorting Archer Daniels Midland and a whole bunch of end-product companies starting with Coke and Pepsi. And when you consider how much of the meat industry has switched to feeding cattle on corn instead of grass...yikes. It may take a few years, but governments beset by rising medical care costs (many of which are obesity-related) are inevitably going to try for some recovery.
I agree completely -- 5 days ago my bike commute took me through 6 inches of snow. The day after, -25°F (-31.6°C) windchills. Your body gets used to the cold if you bike every day as winter sets in. There really is nothing like putting on the thermal underwear + face mask and pedaling home. Keeps one's spirits up during these short winter days.
Salts are usually stored in two components; one is in the database and unique per row, to prevent cracking multiple rows at once. The other component is in a config file in the server -- it adds a constant number of bytes to the input for any brute force attempt.

If an attacker can achieve a root login to your server, then they can read your config file, but they can also just change the login form to email them passwords. For this reason, most password defense is aimed at the assumption that the attacker gained access to the database server, but not the webserver. Historically, this has proven to be a safe assumption.
Damn - a 16% efficiency gain! You're hired!
Both of those links are not proof of any lax security at 37signals. The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) You can read more about that in the comments on that blog.

[ignore] The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time.

Okay, issue was with the lack of a secure channel. Point taken. That was a mistake.

[Removed section on procedures and mistakes, as non-relavent.]

(Disclosure: I use ruby on rails)
Ah... so that's how coconuts migrate. There is no string, or birds.
as douglas adams put it, "a common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
What intrigues me the most is how a sea creature like the octopus can take advantage of an element that's not even from its domain.
There's more than a few accounts of a poor mapping between old and new privacy settings (mine weren't what I'd imagine FB would have picked given I had extremely conservative settings). It seems most folks think there's no problem or that they're evil. I happen to think they just botched it - is that not succinctly conveyed in my comment?
I think that the salient detail is this:

t = Time.now.to_i
1000000.times {Digest::SHA1.hexdigest("ugh8&eat")}
puts (Time.now.to_i - t).to_s
=>3

Sure, 120ms is a bit long, but I think it would be beneficial to security to require more than 3µs.

Edit: I match my parent's problem with 32M checks taking 12 years with my personal computer taking 132.86 seconds to calculate 32M SHA1s.
Tarantino's "Basterdized" History
My guess is that its due to VIM being easier to learn than emacs? But thats just a guess I've never tried emacs.
The instance always runs at market rate. You set a _maximum_ price but are charged less than that if the market rate is lower. So there's no sense in doing such a reactive system when amazon does it for you.
Does this include a config file salt as well?
It's uploading the same log file every 30 seconds to my S3 bucket, so I suspect they're still working out the kinks :)

That said, the documentation on the datafeed stuff is annoyingly sparse - the format is reasonably self-documenting, but I wish they'd commit to it somewhere.
I was really hoping this involved a laser cutting machine.
Every time I bring this up, which is often because it is, apparently, all I ever talk about here, people misconstrue what I'm saying as some kind of argument against "salted" hashes.

It is true that not even bothing to randomize your hashes is worse than doing so. But when we're talking about degrees of grave badness, I stop being super interested in the conversation.

If, for reasons passing my understanding, you are attached to the idea of using straight SHA1 to hash passwords, iterate SHA1 1000 times. That takes 2 extra lines of code (the opening and closing of the for loop) and significantly improves your security.
That misses out on efficiency. Good work that takes an inordinate amount of time can indicate high standards but not the ability to get things done (which I would consider an attribute of a good programmer).
Completely agree, this article has it all wrong.

"Originally the unit wasn’t selling well at all. So Apple dropped the price a few weeks after it launched, pissing off the early adopters of course. Why? Because me and Steve Ballmer were correct."

Matt Maroon and Ballmer were both Wrong. The reason the apple was so expensive at first was to create hype and make people want it. And it worked.

Steve Jobs had already written his apology letter about the price before the early adopters bought the thing. This was all planned. The iPhone's price was part of the appeal.
Linux compose key: http://news.ycombinator.com/item?id=962683
The $10/gal gasoline is probably a close second.
Trusting Nature as the Climate Referee
RockYou was a widget company - they probably still have usernames and passwords for myspace users.
For those using .NET there is a built-in implementation of PBKDF2, it's called called Rfc2898DeriveBytes:

http://msdn.microsoft.com/en-us/library/system.security.cryp...

I did not find a bcrypt/scrypt implementation in standard .NET and I would be reluctant to use third-party security code I googled up somewhere.
There are lots of ideas which are beneficial, but not particularly useful. For example, requiring passwords to be at least 120 characters would (in theory) make passwords more difficult to compromise, but in practice users are just going to type "password" 15 times.

Increasing the digest time prevents an attacker with simultaneous access to the server and database from cracking very weak passwords, but at the cost of tripling or quadrupling how much time each request takes. There are some cases where this could be useful -- for example, running a dissident website in an authoritarian country -- but it's user-hostile to implement it anywhere else.
Awesome, now instead of merely having no idea where a link on Twitter is taking me, I can be left in the dark by links from many other top websites as well! And to think this entire "space" could have been avoided by Twitter not counting URLs against message length.

It has been interesting to follow the trend through the years back to where we started. In the beginning we had http://foo.com/bar.cgi?p=123. Then there was a big movement to bring context to URLs and we got http://foo.com/2005/01/01/my-post/. Now even Google and Facebook are determined to bring us full circle to our inferior origins. It'd be funny if it weren't so sad.
The config salt isn't present in my post -- I'm assuming a database breach, like that which usually occurs. The digest does include a config salt, of course -- this isn't the '70s.
The indigestible fats are demonstrably non-absorbable, so they are less likely to have subtle, sinister side-effects of which we are not yet aware. (By demonstrably, I mean they are easily detected, both by the consumer of said fats, and by lab tests looking for steatorrhea: http://www.annals.org/content/132/4/279.2.full ).

There are risks, and they are fairly well-characterized: you risk malabsorption of fat-soluble vitamins (K,A,D,E).

The fructose issue is far more terrifying, both because (a) it is absorbed, and (b) the epidemiology and biochemistry are plausible.

You know a product is bad for you when it has to put out commercials claiming that it's no worse for you than sugar...
What are the temperatures like in your area? If I biked to work, at least 6 months out of the year I'd arrive a dripping, sweaty mess.
The Strong Free Will Theorem [pdf]
It's traditional to also including a testing row, revealing the password (along with the digest), so that people can verify that their cracking code works.
Some people look younger but looks do catch up to age, at least it felt like that for me on my late 30's. And—I know he lives still—the idea of Michael J. Fox came to mind as counter-example.
>>biking in the rainy, cold, northern Europe is anything but glorious.

Let us not exaggerate. Biking in northern Europe is OK -- if the roads are ploughed, you have the right clothes and winter tyres (2 * 60 Euro for my bike, shudder. Damn thieves.)

The "right clothes" is admittedly a bit much this week, when it is below minus 10 Celsius. Sigh, maybe I should look for a job down south, in warm and sunny Copenhagen.

>>I bet the majority of them would really want a car instead

I bike because I need the exercise. I won't get a car until I live so I get enough exercise anyway.
Yes. Analysts come up with crazy ideas for products Apple is "building" all the time. Ultimately, they get like 95% accuracy, simply because they've thrown so much against the wall that they're bound to hit.

Or they mention it, and say "it's gonna come this Tuesday" every Tuesday for half a decade. They were talking about the iPhone since 2002, and it came out in 2007. They're talking about this tablet like it's coming in Jan. 2010, but they've said "next month" two or three times a year since 2005.
I’ve Seen Things You People Wouldn’t Belive… « The Angry Drunk
We can do this for you at the click of a button at 360voltage:
http://360voltage.com/blog/2009/09/ab-split-testing-out-of-d...
(For Free)

</self promotion>
If your webserver machines are so secure, why put them in the database at all? Just store the passwords on disk there, rsync the password file across all machines and you're set.

I kid, but I really think you and tptacek just have different standards. tptacek's is higher.
The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption.

Using symmetric encryption to encrypt passwords in a database would not be smart. Where are you going to keep the key? If the hacker gets the dbase, then they've probably got the key as well.

There's no point in dancing around this issue. The only acceptable way to store passwords is a slow one way hash. If you get your password in plaintext, the security is lax.

The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time.

The bad part about the second link isn't that the vulnerability happened, its that 37signals had no infrastructure in place for security researchers to report problems. Of course vulnerabilities are going to happen. It's a certainty. But you need to have a system in place for the good guys to report problems. I'm not aware of any informed person that criticized them for the actual vulnerability. If you read the link I provided, you'll notice this quote:

"It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them."

They've got a communication channel now: http://37signals.com/security-response.
I agree with you, in that you're saying it's silly for RockYou to assume their customer's passwords are unique to their service, but I vehemently disagree with your unstated assumption--that 99.99% of other communities aren't just as likely to have users pick dumb passwords.

I don't mean this to come off as ad hominem, because I don't think it was your intention to leave the opposite side of the argument open and I think you personally understand the issue. I just think that we shouldn't have a mentality of "aww, we need to take special care of these unsavvy users." Not having basic levels of security in place for any user-base is simply unacceptable.
[Updated: You're not using SHA1, you're using keyed SHA1 with a secret random key. Presumably it's long, because you made your per-password salt ludicrously long, because you don't really understand how salts work. Note that every "read any file the web app can" vulnerability on your system is now "recover tens of thousands of passwords". It would be extra funny if you hashed your config file salt second instead of first, but I'll leave it up to the experts on your team to figure out why that is.].

It takes 5us on this system to do one SHA1 calculation. You're not using ASCII "digits" (if you were, I'd know, because brute forcing all the 4-digit numeric strings took less than a second); you meant characters. There are ~130MM 4-digit character combinations in standard ASCII.

Maybe I'm misunderstanding something about this challenge, but, if I'm not, post the code you used to generate this comment so I don't waste my time attacking a salt that is secretly Base64'd, and in 10 hours, you can mail your check to Amnesty International.
What do you think about the Whirlpool hashing algorithm?
I'm not misconstruing your argument as against salted hashes, but as downplaying the advantages of using a unique salt over an install-specific salt (not sure that's the best term, but I'm referring to the type of salt you might find in a config.py file).

Let me put it this way: give me a database of 32 million username/password_hash combinations and the hash(password) function used and I can give you a valid username/password combination fairly quickly. Even if the hash function takes 10 seconds, because chances are one of those 32 million users has used "password" as a password, and it will only take me 10 seconds to compute the hash and find out which ones did.

If instead you give me 32 million username/password_hash/salt combinations, and the hash(password, salt) function used, just to list the users who have the password "password" will take 10 years.
I subscribe to the Build Stuff school of programmer evaluation. Why do you hire a programmer? So you can have him build stuff. Has he built stuff? Then he can probably build stuff. If he hasn't build stuff, he might be able to build stuff, but it is a better idea to have somebody else pay to figure out whether he can build stuff or not.
Analyze what you read, never assume it’s the truth
For a while, I was really into fishkeeping and really wanted to get an octopus as a pet. They are supposedly really smart and quickly learn new tasks (like the opening of a jar).

The problem with having them in a small tank is that they are amazing escape artists and can slip through the smallest of holes. Also as a downer, they typically live only 12-18mos and they can't be bred in captivity, so I eventually gave up the idea.
There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.)

So, is there any less sensitivity (security-wise) regarding the key, instead of the password?
Sounds like relying more on a gas tax would have been the better way to go. Distortionary taxes really need to be careful they are distortionary in the desired way.
A Turbulent Year In Video Games
What Matters Now (Seth Godin et al)
The difference between Denmark and the US is that the US would never implement cycle infrastructure that could possibly increase travel times for cars. Denmark is willing to reduce the convenience of roads for motor vehicles, and that makes for a vastly better cycling experience. (Actually, cycling is fine in the US, but you have to be brave when you are just starting out. Copenhagen has designed in features that makes the roads very newbie-cyclist-friendly, so people don't get scared off the first time they ride on the street.)

Anyway, if the US ever wants to see cycling adopted by the average person and not only people who have already made the decision to commit, we need to: reduce the speed-limit in city centers to 20mph; have bicycle-only light timings; and start selling bicycles that are useful, not just "cool looking".

My guess is that this will not happen in my lifetime.
I think it is designed to be fast and is therefore not a good password hash.
Ask HN: Too much copyright VS abolishment of intellectual property?
I just found a company devoted to stopping, or at least finding, plagiarism on the web.

Here's their page about plagiarism:
http://www.copyscape.com/plagiarism.php

And some testimonials from a rather wide variety of well-known "clients" :
http://www.copyscape.com/press.php

Being both a producer and a consumer of web content, I've often found myself caught between freely distributing things that I produce and adhering my name and copyright to those things.

I understand the motivation to protect the ideas or intellectual products one produces for either credit or profit, but I also see the folly of trying to actually stop the dispersal of information or data which people want (DRM, for example).

Your thoughts?
Well, besides the damage of not having access to the computer system. It's not as sensational as you make it sound. For example, an armed robber occupying your house for an evening who leaves with nothing and does not shoot or stab anyone can similarly be described, but he also would not escape the consequences of his actions.
> sucrose is half glucose, half sucrose

That's glucose and fructose
"Salts" have been password-specific since Ken Thompson invented them in the '70s. We're not talking about different approaches: the approach you're talking about is unsafe.

The attack you're talking about --- searching for a radically reduced set of passwords --- is so fundamental to password security that you don't need any crypto to do it. Just open 50 concurrent connections to the login page and rip through the user list. At the same time, with the default BCrypt cost factor, just doing the password 'password' takes 1000 hours against a 32MM row data set.
1.5 years in jail without a trail is a travesty.
Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me).

The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.
Yes, but that's only because 2007's iPhones literally had the processing power of 2002's computers, and they were pretty slow at running a stripped down OS X. Not to mention that OS X got significantly faster between 2002 and 2007. On the same hardware, 10.5 (what the iPhone's OS is a branch of) would be a good bit faster than the version 10.1 that was available when Gruber wrote his article.

And let's not forget that the article was written back in the days before flash-based iPods, so the only way to get storage on it was via hard-drive. I mean, we're talking back in the day before iPods had USB connectors, and 2 years before the iPod Photo
Lots more web app flaws allow you to read arbitrary files than allow you to get a shell on the app server. There are cases where SQL Injection by itself is sufficient to get the contents of files. I think that's what bothers me most about using SHA1(k, nonce, password) as a hash.

Well, that and the obnoxious trick question.
To steal a line, nutrition is younger than it seems. We screwed it up fundamentally. This is just another example.

This study contradicts the glycemic index theory which claims glucose, specifically rice and potatoes, are the worst carbohydrates sources because they're high-GI. Truth is, we're better adapted to glucose. The body converts all carbohydrates (except fiber) sources to glucose, and then to glycogen. There's a reason blood sugar is glucose. The body prefers it.

Fructose - Glucose Study Showdown [1]
(a)13.9% increase in LDL cholesterol but doubled Apoprotein B (b) 44.9% increase in small LDL

[1] Dr. Davis is a cardiologist that has reversed atherosclerotic plaque in thousands of patients. He recommends a diet where most calories come from fat. Here's his analysis of studies relating fructose to heart disease: http://heartscanblog.blogspot.com/search/label/Fructose
The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.

Given your history of quality and logical posts, I pretty much knew the comment wasn't directed towards me. I just wanted to go on record to be sure. I'm sorry as well, I should have just let it fly.

Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me).

They're launching unified accounts soon for all services (you have to pick a new user name and password if I remember correctly). Perhaps this is when they'll roll out the password security? Seems like a logical time to me.
"... How do venture funds not do better technical due diligence(or any at all)? ... How do we make sure companies don't do dumb things like this? ..."

Because it's not seen by "management" or "VC's" as a priority. Extra programming is seen as a time and monetary cost, not a necessity. One company I worked for used plain-text for customer passwords and mandated Microsoft technology in the same breath. When I talked to the lead tech, I got a shrug. Not because of lack of technical smarts but politically tied hands from management. When I contacted the MBA minted CEO I got a blunt - "it's not a problem, don't worry about it".

A physical loss is perceived more
tangible than something ephemeral.

Things did happen when people walking off the street stole "stuff" from the office. Swipe cards were quickly introduced. I'd broached such arrangements before the incident but that wasn't seen as a problem either.
Ongoing · The End of the Golden Age?