skysight-inc/HackerNews huggingface dataset:
Yeah, thanks, I should have tossed it in here. The current one is good too: http://www.cringely.com/2009/05/the-sequel-dilemma/

(I think it was submitted by someone else who doesn't believe in ... erm ... 'fortified' headlines, and promptly drowned in the waves of this week's WSJ/etc news - not that this one has swum any distance ;-)
> People who haven't lived long enough to reproduce have no impact on that figure.

They impact it indirectly. Say you have a tribe with 12 men and 12 women. 11 men die (before they can reproduce.) Then the next generation has 1 father and 12 mothers. One could say that the men's deaths caused more people to have the same father. So having a lot of men die before reproducing increases the strength of the effect, under the assumption that women will usually reproduce regardless.

Obviously the root cause is that men can bear more offspring, that much is obvious.
One of the most common ways for data to be stolen is from the inside. Having 500,000 user accounts with plain text passwords is a valuable commodity, all it takes is a pissed off employee and a SELECT email, username, password FROM users INTO OUTFILE '/tmp/users.txt'. Odds are you'd have access to tens of thousands of email addresses and from then on it's easy enough to crack tons of other accounts.
Electric shocks that were damaging would defeat the purpose of the experiment. It required a comparison between dogs that had some control over the shocks and those that didn't (though both received exactly the same shocks). If both dogs were harmed, it would be harder to differentiate the harm due to the randomness.

Of course you may doubt their reporting of their own experiments. We only have their word for it that they conducted the experiments at all.
I'm glad Django stores all the passwords as a sha1 hash.

This is better than storing plaintext passwords, but it still makes a brute-force attack very cheap. Use a well designed key derivation function which is expensive to attack. (And come to BSDCan'09 next week to hear me talk about this!)
A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem.

This is called "key strengthening" and was proposed by Abadi et al. in 1997. It works, but it's not as secure as key stretching using a well designed key derivation function.
I don't buy that argument. When someone clicks "I forgot my password", you e-mail them a one-time link to log in to their account. They click it, and they're in. That's easier than checking your e-mail and then typing a password.

Not to mention that 37signals accounts are paid for - so there's a much higher incentive for people who forget their password to go through the flow to recover that account - otherwise they'll be wasting their money!
If you routinely forget your password it doesn't really matter if you always get a new/different password, now does it?

edit: not that this is the best way to go (see other comments) but it's still miles better than what they have now, with minimal intrusion for their users.
Anyone know if 37signals still allow people to XSS their own Basecamp accounts? http://forum.37signals.com/basecamp/forums/5/topics/3155
Some people feel rather bitter about DB2's luck:
http://www.cringely.com/2009/04/sunset/comment-page-1/#comme...

Robert Young's posts (the ones I linked) merely note it's a different species - but I suppose both rhinos and hippos are rather effective at trampling things ...
Considering the universe of beginners (B), and the subset who are visual thinkers (V), then unless |V|/|B| >= 0.5, then no.

More data is needed.
Django uses a salted hash - each password is stored with a random hash code unique to that password, e.g.:

sha1$0ae33$b8a9502237851f302170e1bb207d4eb3f36d9a31

The 0ae33 is different for each stored password, and is used as part of the SHA1 hash. This means you have to brute force each account separately - you can't just use a pre-generated SHA1 lookup table.

It sounds like you know your stuff though - if there's anything we could do to make this secure (while not depending on any libraries other than the Python standard library) please share!
Internet Traffic Periodicities and Oscillations: A Brief Review
99% of the time, if you own the mail spool behind an account on a web application, you own the account, because of password reset.
I doubt that this is a mistake in the sense of an unintentional oversight, but a deliberate design decision, albeit a poor one. They might have taken the KISS principle too far this time, at the expense of security.
That's still not secure, because SHA1 is very fast. To get "secure" from that, you need to iterate the function several thousand times, or use bcrypt.
The banal brazenness of telescammers
How much should you pay an executive in a startup company?
Correct, the blog post is assuming the password is stored in plain text, when he doesn't even have hard evidence about it.

Two way encryption would be an explanation to this, so I am waiting on what 37s' answer to this blog post.

It's sad people quickly come to conclusions when only hearing one side of the story.
Yes, Clojure is less effective than other Lisps. And Symbolics Genera remains my standard of comparison. You cannot un-create it. The standard of comparison for a technology will always be everything previously achieved by mankind, rather than what is available on the market today.

Bu I will try to explain my real objections.

"Beauty is the first test: there is no permanent place in the world for ugly mathematics." (G. H. Hardy)

I was drawn into programming at an early age because it seemed beautiful and allowed me to run wild with creative ideas. Thus I insist on systems with a purely minimal amount of accidental complexity - so as to leave the most room in my head for the ideas I am trying to put into practice. I have zero interest in "programming as construction work" - implementing the ideas of others, or for that matter doing anything which isn't in some important sense original. Thus I want my programming environment to resemble pure mathematics, where absolutely nothing is present for which there is not an ironclad and inevitable logical reason, where everything is open to question, and the answer is never "because the drunken intern wrote it that way five years ago."

Most of the "practical problems" programmers supposedly "solve" shouldn't even exist. They are created through the idiocy of other programmers. In particular, I am talking about any situation where the output of one program requires "glue" to match the input requirements of another; or any situation where formats are converted; and many other cases. If the moronic mistakes of the past four decades were undone, most of the people who are calling themselves programmers would have to find honest work.

Screw "practicality." Programmers are the proverbial firemen who start fires when they aren't at the station-house, and gloriously put them out, hailed as heroes every time.

Clojure will never be beautiful because it promotes the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal more Lisp, with turtles all the way down. Its claim to the name Lisp is in an important sense fraudulent. I rest my case.
The Man Who Made the Postcard Says "Telephonic Conversation" is What's Next
"If the server can decode it so can anyone who has access to the server."

Semantics.

Any type of security made by humans is breakable by humans.

Your reasoning is flawed.
You mean like FedEx and several banks?

I don't love this design decision --- ok, no, wait, I hate this design decision --- but don't make it out to be something it isn't. The 37s team knows how to do "secure" password storage (that's every other Rails plugin ever written). They chose this because they thought it would make their customers lives easier.
Of course not, but if one does make a generalization based on this small sample as the person I was replying to did, one's generalization should agree with the data.
From a security standpoint, there is no difference between storing the password in plain text, and storing it encrypted with the keys on the server to decrypt it. It's like saying that having an unlocked safe is not the same thing as having a locked safe with the keys left in the lock. Why should the OP make the distinction?
Cheap Ways to Upgrade Your Laptop
"Embarassing security flaw"? Come on. We audit several major web applications every week --- things that are far more sensitive than 37s, like banking, trading, and pension --- and we see sites store plaintext passwords all the time. I've never seen any vendor's security report write someone up for this. If it did get written up, it'd be "Severity: Low", along with "enabling weak SSL ciphers" and "exposed server version information".

I'm not trying to be an apologist here, but "someone is wrong on the Internet" if they are saying that storing passwords badly is a major vulnerability.
Question Answering Engines Take Off as IBM Sets Sights On Jeopardy, Wolfram Alpha
Grid Computing on the Azure Cloud Computing Platform, Part 1
Good point as well. The problem is that too many exec thinks that they do not need domain expertise because they can "rent" it.
You're assuming the keys are the only way to get into the safe. There you go again with flawed reasoning.

What if I drill into the safe and open it in a different manner?

ANY type of security has it's weaknesses. The only way is to add layers of security to make it harder to crack.
The print version has everything on one page: http://spectrum.ieee.org/print/8747
Really? We're going to downmod the most active security professional on HN? A guy who's built a 25+ person company on the basis of analyzing web applications for security? FFS, did we learn nothing from yesterday's expert kerfuffle?

If Thomas says it's not really a big deal in practice, then it's not really a big deal in practice.
Sounds good to me..
We'd pay for a ruby 1.8.7 interpreter that could run Rails even 2x as fast at Justin.tv.
Yea maybe I am bit biased about my opinion because I understood probability easier using visual examples, but people who I have interacted with mostly also understand things easier in the visual form. So I think it maybe _the_ best method to teach probability because it will reach out to a majority of people, ofcourse, there might be people who might understand it better if explained in a different way, but that maybe a minority, so all the different methods can be tried out in school.

One more thing I would like to add is that everyone has a biased opinion of things based on their perception of the world and that's why I think there should be debates. Generalizing from examples and experiences is a natural method developed during evolution.

If a kid touches a hot plate and experiences pain, I think it is perfectly valid that it should generalize that to all other hot plates. :)
You may be right about the 2900, but I think that one of the 2900 books ("Bit-slice Microprocessor Design" by Mick and Brick) could be considered very influential to a certain generation of older digital designer.

Thanks for bringing this up--I'll need to add a copy to my library now!
Motorola ZN300
Motorola ZN300 is a true blue camera phone and has been designed in a fashion to provide excellent photo clicking features in conjunction with other mobile communication and multimedia features. It has 3 megapixel camera.
How to use an iPhone to Fly R/C Airplanes and Helicopters
Embarrassing as in known to everybody who builds web apps for a living and very easy to fix, and yet this way.
That's true, but in addition they are showing tweets that were published post making the account private. I have verified this with a friend who has their updated locked. I am not following them but can still use search to see what they are saying every day.
http://news.ycombinator.com/item?id=589677

Apparently, that thread has comments from crosstwine developer.
On the contrary, it's a big deal to me because it's my password and I judge that it's being stored in an insecure manner. I really appreciate Thomas's expertise, but since my data is at risk as a customer, my opinion is really the one that counts.
Do you believe there is any good reason for a site to store passwords in plaintext?
Or use scrypt, which is far more secure than bcrypt. :-)
Do you have any evidence of this? They said two years ago that they were going to change it...what makes you think it's not just a case of them being lazy?
"This is why I generally forbid the use of the word 'just' when people are making feature requests."

Agreed! Keeping "just" out of conversations involving feature requests is amazingly hard to do, but in my experience it works.

Laying down that rule does a surprisingly good job of making people aware of when they're getting ahead of themselves, and jumping out of their area of expertise when asking you to do something. "Can't you just ..." teeth grate
Thanks for your reply. I agree with you that speaking abstracting "permanent/temporary" is an instance of "general/specific". To be precise: temporary is an instance of specific, over time. Categorizing an explanation as temporary means that it is contained within a specific (and short) period of time. (I also agree that concrete categories can often be helpful in practice even if they aren't strictly necessary in theory.) That's what I think you meant in your comment above.

But that isn't what I meant. My confusion is how to apply it - how to actually categorize concrete explanations in practice? The example again "gems are always a pain" seems to be generalizing over gems, and not over time. Therefore, it would be a better example of general rather than permanent. A better example might be "this gem/Windows/linux/PC never works! It always messes up, every single time I use it." My difficulty is that (it seems to me) that every example can be recast in either form, because different events in a person's life occur at different times - to generalize over events is to generalize over time; and to generalize over time is to generalize over different events.

It occurs to me that an explanation might be neutral along some of these dimensions - an explanation might not be explicitly permanent, nor explicitly temporary. Or one might have a default, and say "if it isn't explicitly temporary, then it's permanent". eg, "they're just jealous because I'm smart" doesn't mention time, so by default it is permanent. Or, there could be a continuum along a dimension, corresponding to the size of the set generalized over: only this one instance---similar events---absolutely everything (and similar for the permanence/temporary dimension).

It might seem that I'm picking on your example, as not an ideal one to illustrate permanent/temporary (which was its purpose). I am. But I make the same kind of error (assuming it is one). And it seems to me that categorizing something as more strongly along the general/specific dimension, or more strongly along the permanent/temporary dimension seems arbitrary, and one can do it just as one feels - there's no principle behind it. Perhaps it is still useful, even without a principle behind it, but I'm uncomfortable with this.

Summary: I don't know how to classify an explanation as "permanent/temporary" or "general/specific" in practice. [answered in replies]

Or maybe I just too much :-). But it was important to me to lay this out clearly. [I haven't yet read your other reply that you mention - now read]
Whilst doing hashed passwords is a no-brainer and it solves process problems like employees emailing passwords to people (who maybe impersonators) I don't think it solves all the problems with password security.

Unless you have a strong password policy, john the ripper can often find several passwords (out of 100+) in literally a few seconds by doing dictionary attack, variants and common terms. I would say that someone's hashed password should be well protected as a unencrypted one would be even inside an organization.
"Pathetic." is a bit excessive...
The fact that this is a common mistake doesn't make it any less serious. I don't do security audits, but if I did I would certainly point out this sort of mistake -- because even if it doesn't affect this site's security very much, it certainly has an impact on their customers' security thanks to the reuse of passwords.
Yes, but with password reset you don't also own every other account the user has where they reused the same password.
Instead of trusting every single provider of a service you use to safekeep your password, why not just use unique passwords for each service? I mean, really, you can't put the blame on each of the service providers if you choose to use the same password everywhere. That, if anything, is an embarrassing newbie mistake.

I have a repeatable method of coming up with a unique password for each service. I don't have to remember each unique password, only my method for producing a password.

Because my method is arbitrary rather than mathematic, I don't think anyone can figure it out even if given sample of passwords (I've challenged several who claim to be able to do so "easily"). And while my method is arbitrary, it's comprised of a few rules I know very well, which leads me to actually remember each unique password fairly well.

Don't outsource the job of safekeeping your password to every single vendor out there. Do it yourself.
No.

I'm actually bizarrely fixated on this topic; go to "searchyc.com" and search for "bcrypt" and follow the threads. It is, apparently, all I ever talk about.

I'm not defending the feature. I'm just saying:

* Lots of companies have this feature.

* Among them are FedEx and several banks.

* If you wrote a security report for Basecamp and included this problem at all, it would be "Severity: Low". I'd write it up. But I wouldn't say "Severity: Critical", because I would get my ass kicked by my clients and partners.

The rest of this debate, have at it. I agree. BURN THE WITCHES.
FDA warns dieters: Stop Hydroxycut use immediately: WRAL.com
It's frustrating that search includes deleted tweets. It's depressingly often for me that a Twitter search results page has at least one duplicate result because someone posted twice to fix a typo.
This point of view looks a bit like taking the "blue pill" to me. It might make you happier (in the "ignorance is bliss" sense) but I doubt it will make you more succesful. If you attribute all your faults to bad luck and all your success to being smart, great etc., you are not going to improve yourself much, after all we learn a lot from our mistakes. I have to say, though, that I haven't read the book, i just checked in internet to see what it is about.
I'm going to have a hard time arguing that it isn't a mistake given my track record on the site.

My only argument here is that, mistake or not --- it's definitely a mistake --- it's not a "serious security vulnerability", at least not as the industry understands them.
Note that I might not be "the most active security professional on HN", but am certainly "the security professional most active on HN". There's a big difference. ;)

Note: I don't know who this "kubrick" person is, because he won't tell us, but "CISO of a financial institution or not", he's wrong about the OWASP Top 10.

Neither "broken authentication" nor "poor encryption" "top vulnerabilities" discuss password encryption. "Storing plaintext passwords" is not an OWASP Top 10 flaw.

"A7 Broken Authentication and Session Management" is a proxy for session fixation, and the catch-all category for things like "cookies that store the bit that tells the app whether you're the admin. It mentions passwords repeatedly without ever recommending they be encrypted; in fact, by talking about "Question and Answer" features, it tacitly acknowledges the practice.

"A8 Insecure Cryptographic Storage" means "don't invent your own crypto", and now also "don't use MD5". It mentions passwords zero times; the only thing it says need to be encrypted are credit cards. This makes sense, because if it said anything else, no real-world web app would pass muster.

Having said all that, I wouldn't put much stock in the OWASP Top 10 either. It's the most popular list of web flaws, but it isn't the most complete, nor is it the most coherent. It's not like there's science behind it.
As with a lot of mind hacking (aka self-help), the key is to apply it to oneself, not to others. Turns out people don't like being hacked (get out of my mind!) And to apply it to ones operational thinking, not to how one expresses oneself.

But a discussion of how to apply it to ones own thinking can be a helpful preparatory exercise. In that spirit, and with apologies to the parties involved (the OP is obviously having a joke anyway):

Definition of "optimism": good things are explained as personal, general and permanent; and bad things are explained as impersonal, specific and temporary.

(1) Why is everything written by a Ruby programmer so damn long-winded?

This is describing a bad thing (long-windedness). "Everything" is general. "Ruby programmer" is impersonal wrt to the speaker (it's personal wrt those programmers as a class, but impersonal wrt Reg - but I don't think these are relevant)."Everything" is also permanent, as it includes every time an essay is written, and there is no explicit limit to when such essays will cease being written (not the interminableness of any individual essay). An optimistic explanation for a bad would be impersonal, specific and temporary - this one is impersonal, but it's general and permanent. So it's mostly, but not completely pessimistic. A more pessimistic version is:

- Why am I always so slow at reading everything?"

(2) I'm always interested in the thoughts of other programmers. This article is a bit longer than I have time for at the moment. Would anyone care to summarise?

This is also about something bad ("longer than I have time for"). "I" is personal wrt to the speaker ("I don't have time"; in contrast, the article is only "a bit longer" - the problem is mine, not the articles). "At the moment" is temporary. "This article" is specific. An optimistic explanation for a bad would be impersonal, specific and temporary - this one is personal, specific and temporary, so it is mostly, but not completely optimistic. This definition of optimistic isn't the same as "nice", "kind" or "positive". A more optimistic version is:

- This article is too long to read right now

( The other sentences aren't part of the explanation (and maybe aren't explanations at all?), but anyway, the preface is about a good thing and is personal, general, permanent; the epilogue is an action step about a good thing, and is impersonal, permanent, specific. )
My favorite part of this story is actually where the author admits that he categorically loathes any music that doesn't have a catchy hook and someone singing words he can follow.

A pet peeve of mine has always been how _everyone_ claims to like music. When there are people who dislike ice cream, people who dislike movies, people who dislike sports, people who dislike dancing...why is it that you never meet anyone who will admit to disliking music? That always annoyed me as a musician who's met many people who can't possibly actually enjoy music considering their listening tastes. Yet, because of social pressure, these people will never publicly admit to disliking music.

So it's refreshing to hear from someone who admits to feeling zero affection for music. There are people who admit this about visual art. People who say this about drama. But it's rare to meet someone who will admit this about music,