skysight-inc/HackerNews huggingface dataset:
I've always found the use of $ when referring to Microsoft to be really really childish, and weird when I see people here, who are presumably mature adults, doing the same.
37signals lost a bunch of plaintext passwords? When did that happen?
Using Dropbox to Backup a Dedicated Linux Server
My answer to this question is effective but very self-serving.
That very same deep focus technique in video games makes me nauseous on an hd tv. I wonder if it will be more or less puke-worthy in 3d. I'll report back on friday.
If loads of false negatives are okay, here's a simple heuristic: I don't think I've ever seen a Haskeller who wasn't plenty smart.
Super article. The only thing it left out was the fact that the unreal 3d engine is now freely available for non-commercial use.
For some good reading on the subject, check out Ray Peat's article "Glycemia, starch, and sugar in context" at http://raypeat.com/articles/articles/glycemia.shtml.

While not specifically about sugars, the Weston Price book is a good read about traditional diets as well: http://www.amazon.com/Nutrition-Physical-Degeneration-Weston....
Does using a unique salt for each user help here? Is there a non-obvious reason why that approach is bad?
Building a More Efficient Ruby Interpreter
I'll take your word for it that biking in California is glorious.

However, biking in the rainy, cold, northern Europe is anything but glorious. Yes, it's very nice in the summer, it's the remaining 9 months that are bad. Let's just say that the overwhelming majority of the people I see biking in Copenhagen don't seem to enjoy it very much. I bet the majority of them would really want a car instead, but chose not to get one because of the very high price due to the extra tax.
What's the plumber equivalent of storing passwords in plaintext, the things where if you heard that a plumber did X, you would be in complete shock at their negligence?
correlation is not causation (joke)
I doubt that. They're led by probably the strongest Rails team anywhere, and they (DHH + team) wrote books on avoiding what RockYou just did.

EDIT: I'm specifically referring to DHH's "Agile Web Development With Rails", Chapter 11, Administration
I commute on a bike that's several levels below a cheap $300 Walmart one -- and it's glorious. Every day, I get to work in a better mood than when I left home. I defy anyone who drives to work to make the same claim honestly.
What's wrong with using a salted hash? Assuming a competent implementation, it should be computationally infeasible to brute-force any digests in less than a few billion years using current models of computation.

I'm particularly curious about how using (for example) BCrypt will prevent brute-forcing "12345", "password", or any of the other simple strings many people use.
In practice, how much of this article is about informing business folk and how much is about patting ourselves on the back?
Ask HN: Take a Look At My Site - HockeyBias.com
I have created a hockey news aggregation site that is laid out in a manner very similar to the Drudge Report with a bit of Scripting News influence as well.

Any feedback on design & usability would be much appreciated.

The url is:

www.hockeybias.com
Train our runtimes to detect and reject attempts to store user passwords in plaintext?
The "salt" --- which, so far as I can tell, is a term used almost never in academic crypto research --- defeats one very effective exotic attack: the "rainbow table", where an attacker builds a database of perfect hash :: string correspondances.

But too many people forget that before the popular Windows cracking tools were released, passwords were cracked exclusively by tools like JtR, which simply contain highly optimized loops for brute forcing passwords. "Salts" do nothing to slow this attack down, because they add insignificant time (really, none) to a single hash iteration.

Hashes like MD5, SHA1, and even SHA256 are designed to be fast. To succeed, they need to be able to handle multi-gigabit per-packet hash rates. They are designed explicitly both to be fast on general-purpose hardware and to be straightforward to optimize in purpose-built hardware. This is a bad, bad property for a password hash.

BCrypt is "optimized" to be slow - tuneably slow. SCrypt improves on BCrypt by being both slow on general purpose hardware and resistant to simple hardware speedups. PBKDF and "stretched" SHA1 are very simple contructions that are weaker than BCrypt and SCrypt but more buzzword compliant. All of them make it difficult to recover hundreds of thousands of passwords from a database dump.

See:

http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
The fact that they live within biking distance of where they want to go has nothing to do with it....
The salt is used for the original encryption, after which the plaintext is thrown away, then when you need to compare what the user enters next time, you use the same salt with the password entered every time.

http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Edit: On second thought, I might have misread the question, perhaps you're intending to store the unique salt for each user, although that seems impractical to me since it would have to be just as obtainable as the password database.
It happened (storing in plaintext, not losing the actual passwords): http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with...

We've covered 37signals poor approach to security before: http://news.ycombinator.com/item?id=804257

It's my understanding that they've since reformed.

I'd be interested in what books you think they've written that provide credible security advice. Blind "fanboyism" (if I may invent a word) is a bad thing.
If I were in it for the money (i.e. if I were a major studio), that would not be a good sign.
I think the correct answer is 'hire tptacek' :)
What do you think about halting password puzzles?

http://crypto.stanford.edu/~xb/security07/index.html
That first paragraph is a funny statement, since every Unix security book ever written explains how to use Crack, a tool written before I even got into high school, to rip through Unix salted passwords. I don't think it even bears arguing.

The second point is valid but not particularly meaningful. You could also try "12345" and "password" over the network using the login page as an oracle, given a list of usernames.

But with SHA1, you can feasibly do large combinations of phonemes with numbers and punctuation across millions of accounts. People with passwords like "ugh8&eat" will lose their accounts.

You can tune BCrypt so that just "12345", by itself, is too painful to run across 32MM rows to be worth a PR stunt.
Also this, similar take on the horror of backups gone wrong: http://www.penny-arcade.com/comic/2005/8/10/

Don't blindly rely on your partner to do it... Trust, but verify.
I think anything ending in "KDF" gives me warm fuzzies, and that whatever you code in already has a library for BCrypt.
Riad Alkantara website - Fes and Meknes
I know OP means well, but this post provides far more data about his own experience than anything that can be reliably used by the reader.

What he calls "indicators", I call "co-factors". They may or may not accompany a given programmer, and they predict nothing.

Generally speaking, good programmers are intelligent and do care about their work, but his positive indicators are much more a matter of personal preference than the quality of their work.

For each good programmer OP can identify who programs as a hobby, will talk your ear off, started programming before university, or has knowledge of a lots of technologies, I can cite a counterexample.

Similarly, I can also identify many good programmers who possess some of OP's "negative indicators" like having a day job, enjoying a single technology, not wanting to talk shop, or enjoying other activities.

There is one sure-fire way to identify a good programmer: their work. In fact, it is by definition the way that we should evaluate programmers. It is the great equalizer, and with web technology, exposed for all to see.

It really is as simple as cause and effect: good programmers produce good work; bad programmers don't. Anything else, including OP's positive and negative indicators, is just a detail.
How about: Install a drain without a vent.

Why do you want to know?

Edit: I picked this example carefully. Someone who knowns nothing about plumbing will not be shocked at this, having no idea what it is (until it's explained to them). Just like someone who is not a programmer will have no idea what the problem with plain text password is (until it's explained to them).

PS. A drain without a vent (or at least an anti-siphoning device) can be life threatening.
I Am Not A Cryptographer, so take this with a grain of salt. Using a unique salt for each user "helps", but is still insecure. The problem is that hash functions such as SHA or MD5 are designed to be very fast. This means that even with unique salts it is still fairly trivial to try a large number of passwords on a large number of users and crack many or them.

The parent poster has the right idea. For passwords, use bcrypt, scrypt, PBKDF, or a stretched hash.
Names do not matter, only thoughts are important.

I wish HN would randomly create and rotate usernames making sure nobody has the same username twice (at least not across multiple posts).

"anonymous772", "registered9873" is better than "JacobAldridge".
Repeat, sort of: http://news.ycombinator.com/item?id=994797
If you had actually bothered to read the article, you would have found out that it's the other way around. White people have less pigment to maximize the amount of vitamin D that can be synthesized given the little sunlight they receive.
Saving The Day: Abu Dhabi rescues Dubai after all
"salting" also prevents brute-forcing. Assuming a bare-basics implementation (20-char salt in config file, 20-char salt per user, prepended to the password), the only way an attacker can brute-force passwords in a reasonable timeframe is to compromise the server itself. At that point, it would be just as easy to make the login form mail him passwords.

Merely choosing a slower digest doessn't help, because the digest would have to be extremely slow (minutes or hours per password) to prevent somebody from running it against "password", "12345", etc for every row in the table. And that's the only kind of attack worth preventing -- if somebody can brute-force a 20-character alpha-num-symbol password in realtime, your choice of digest algorithm is irrelevant.
I think the web is full of SQL vulnerabilities because lots of people do not understand that there is a problem with using user submitted data without some kind of tested sensitization method calls that are not homebrew. In all reality they should be using stored procs with named parameters dynamic sql queries are usually hard to do right(depends on the language, php makes it hard).

If you use a stored procedure for user auth and the input comes in as x'; drop table users;-- the system will not drop the tables because the parameters get auto quoted.
"Agile Web Development With Rails", Chapter 11, Administration
Just beware blackberry users. Their email clients suck donkey dong. Some newer clients can handle basic html formatting (tables et.al.) though they still can't wrap text in a pleasing way.

I got burned by this earlier in the year when I made the mistake of assuming business people would be able to read html-formatted email (and they were all on BB)

The old chestnut about "assume" making an "ass of you and me" is true :-(
This article is much better than Wired's.

It also has some inconsistencies, the New Yorker said is was Space 2001 not Star Wars that inspired him to create films.
Bit.ly Goes Pro, Tells Goo.gl To Suck.it
Octopuses (or my preferred octopodes :) are so amazing. I never get tired of watching videos of them mimic (see prawn's comment), escape from boxes ( http://www.youtube.com/watch?v=9-azBDt0kik ), and camouflage themselves ( http://www.youtube.com/watch?v=7NQUqR_YpsA ). Can't wait until I can buy clothes with chromatophores.
A long time ago it was proven than a number of different abstract notions of computers could all solve the same set of problems.

We now have a number of different ways of articulating abstractions in source code. I suspect there is a mechanical way to transform a design using ADT's to a design using OO with the same dependency graph. We need to characterize the canonical abstraction in the same way we characterize a turing machine.
Actually selective sync doesn't fully handle this case. With selective sync you could choose not to sync down certain files to the computer, but then they aren't accessible at all. With ZumoDrive, the files are accessible but "deflated", meaning they take up no space but will stream and cache on the computer when accessed.
I'm guessing tree5 is talking about "Agile Web Development With Rails," in which the authors do give examples of creating hashed passwords with a unique salt and running a SHA1 digest. The book also talks about preventing plain text passwords from showing up in log files from form submissions.

From what I understand however, AWDWR is only tangentially related to 37signals.
If you can't understand the significance of these two results (and this is with the default cost factor for BCrypt), you're just arguing to hear yourself talk.

t1 = Time.now.to_i
100.times { BCrypt::Password.create("ugh8&eat") }
puts Time.now.to_i - t1
=> 12

t1 = Time.now.to_i
100.times { Digest::SHA1.hexdigest("ugh8&eat") }
puts Time.now.to_i - t1
=> 0

I could raise the number of iterations to bring SHA1 above the measurement floor, but I don't want to lock my computer up with pointless BCrypt cycles.
^ people like
Agreed. Often the worst part of my day job is having to worry about what might confuse or frustrate co-workers.
Funny, funnies, funny joke
Here's the sample code they give in that chapter:

def self.encrypted_password(password, salt)
string_to_hash = password + "wibble" + salt # 'wibble' makes it harder to guess
Digest::SHA1.hexdigest(string_to_hash)
end

They are using SHA1 with a salt, the exact method that security experts recommend against when storing passwords: http://news.ycombinator.com/item?id=995645. And obviously they didn't even use this insecure method internally.

EDIT: tptacek makes a good point. I haven't quite been fair. 37signals did what most companies never do when confronted with a security issue: they quickly acknowledged the problem, fixed it based on the suggestions of the security researchers, and moved on.
There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest.

And, like I say every time this comes up, FedEx and several banks also store plaintext passwords.

37signals no longer stores easily attacked passwords.
There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest.

I was intellectually honest. I explicitly said they didn't actually lose them.

37signals no longer stores easily attacked passwords.

I was under the impression that this was true as well. However I just checked and I got my Backpack password emailed to me in plain text. So at least the Backpack application is still incorrect.
Thanks for your comment..

"Finding a co-founder is not something you do by moving cross country and randomly bumping into people."

True - but it would get me near like-minded people where there are a lot of meetups for entrepreneurs and more resources.
I said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it.

For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' is a delimiter between the fields.

algo | user_salt | digest
----------------------------------------------------------------------
sha1 | lyhsus1eizh815xz69pv | d418a6088847d6f2e5b0e3d2ecf2e300454a0885

If you (or, anybody) can determine the original password from this database row, I will mail you a check for a thousand dollars.
The news here is that our "justice" system can throw you in jail without a trial for a year and half for a crime that resulted in no damage to anyone and not even a loss of data.
Just something I noticed:

"If your potential programmer didn’t do any programming before university, and all his experience starts when she got her first job, she’s probably not a good programmer."

This is the only time he uses the female pronoun anywhere in his post, and he uses it to describe a programmer that started in college and isn't any good.

Conscious or not, it's somewhat accurate; female cs majors are less likely to have prior experience with programming going into college.
Unintended consequences. :(
I think the guy has a monkey on his back. But I agree with him about emails being both profitable and the importance of making the end users experience a smooth one.
Have you taken a look at how much it would cost to repaint your office beige when you needed to? It could be worth it in the productivity gain department to paint your offices interesting colors and then contract out when you need the bigger space. Though don't skimp on the chairs to paint the office.
Even biking in California can be tough. I gave it up because drivers are so unfriendly and I don't like feeling sweaty when I get to work.
I'm not shocked. As I just wrote on my Posterous, RockYou has consistently shown themselves to be just amazingly stupid. I've had the misfortune of dealing with these morons for over a year now. This is far less bad (since I use Roboform) than the time they CC'ed me in with thousands of people on a Merry Christmas email.
Aside from the quality of the article, there seems to be a lesson about speculatively changing one's basic diets to things that appear to be safer. Fructose was promoted as a substance which didn't have the high glycemic index of sucrose. Low and behold the final results seem to be worse.

The effects of the indigestible fats that still taste appealing probably won't be know for a bit but they could be scary. Who knows what final results will occur with other speculative alterations of the diet (fortunately, calorie restriction is very small fad).
It seems whenever taxes are used to direct human behavior there are always unintended consequences.
It was mostly a play on the title that I found humorous, since it clearly meant to imply they were one or the other but you could negate both with one word.

But I do truly believe that Facebook is neither too.
It's highly interesting for the entire movie industry, because it's an experience you currently have to go to the cinemas to get, you can't get it from buying some cheap consumer electronics and downloading something off the internet.

If Cameron has made something that makes 3D integral to the cinema experience instead of just something that feels tacked-on and not necessary, that can definitely change cinema forever, whether we like it or not. :-)
Facebook publishes user updates to twitter this week
Lead pipes?
Using these numbers, it would take your computer roughly 12 years to check 32M passwords against that string. That's a long time, but feasible (with additional power), and more specialized systems can bring it within reach.

In contrast, assuming a 40-character (20 in config, 20 in database) alphanumeric salt, an attacker would have to perform 704423425546998022968330264616370176 digests per row to check 32M passwords.

Unless you believe that is an insufficient barrier, implementing BCrypt is merely degrading the user experience (12-second logins? come on) for no real improvement.
We know what to do with the waste: burn it up in nuclear reactors. Much of what's called "waste" is really just partially-processed fuel, and the only two reasons it isn't viewed that way are, first, proliferation fear and, second, it was convenient for all the major groups involved to spread FUD about the terrible dangers of nuclear waste.
Your Twitter one is too long :) I think it should be tw.tr
Here you go: http://en.wikipedia.org/wiki/MIME#Alternative
No offense but "queried" them is a little loaded as well. Can't imagine these dissidents displayed their, name and address in the open. So "queried" is more like, "turning in the IP address and the time-stamp" at the request of the Chinese government. And I don't really buy the "we have no idea why the Chinese govt. would want these" possible excuse from Google.

Never-mind their active participation in blocking information and issues relating to Tibet and thus contributing to the problem.

Well, I expected to get down-voted on HN for even alluding that Google would do something wrong, and for not worshiping Sergey & Larry. This is definetly Google fanboy country.

"Hail Almighty Google!" -- there, fixed it now. Let the points roll in.
trying new things is great. it's also extremely different, or rather limited, than what is needed for a start up. that is, you need A LOT more than the desire and experience of toying with new things.

toying is part of the inventor spirit and different projects need different things. one project might be ok with one of the mockups architects make. another project might need the life sized building. and so on in between, changing as the project grows.
His computer is taking 12 seconds for 100 iterations.
The time spent checking the password would be more like 120 ms, totally in the order of a decently fast http request.
If the attacker can get the list of password hashes, what's stopping him from getting your salts too?

You're basically just splitting the passwords into two components--two-factor security--except that two-factor security requires two separate concepts, not simply requiring two passwords.
Wait a sec, something is wrong here. I suspect the title is misleading. RockYou has maybe a couple thousand developers tops using their services. They might have 32 million Facebook customers, but those don't have passwords. They're Facebook app users.

Facebook does not permit developers to store private info without special permissions, which I've never seen apps of their ilk ask for. So while this hacker could maybe see what digital birthday card was sent to whom, that's probably about the extent of the damage.
I certainly get why a slower hash would curb brute force attacks, but when I'm talking about unique salts, slowing down the hash is not the purpose I have in mind.

If you have a table of 32 million hashed passwords with no salt (or they have the same salt and you know what it is), you can try a bunch of combinations, take the resulting hash, and look it up in the hashed password database. If you try the password "foobar" and any user has the password "foobar", you've found a username/password pair. Because there are 32 million potential matches, your chances are pretty good of eventually finding a bunch of matches by iterating over a bunch of potential passwords.

On the other hand, if you have a table of 32 million hashed passwords and salt combinations, where the salts are unique, you have to check the hash of "foobar" in combination with every user's salt before you can say that no user has the password "foobar". This is 32 million times slower, which is a significant difference regardless of the speed of the hashing algorithm.

If you want to brute force a particular user's password, the unique hash doesn't matter, but if you want to maximize the number of username/password pairs you can get, it seems to me like it would.
So "protocols" are basically operations that can be performed on a data type? I don't get it.