gmazzola

Ironically, I was very careful with my choice of "virus vs. virii" when I wrote that message. I looked up the Wikipedia article for Plural of Virus ( http://en.wikipedia.org/wiki/Plural_of_virus ), and noted the sentence "In reference to a computer virus, the plural is often believed to be virii...".

As an amateur Latin geek myself, I agree that "viruses" is proper from a grammar standpoint, but I sided with Wikipedia because I was using computer terminology.

Indeed. I figured this particular piece of news would interest both types of hackers, as it contains technical details you wouldn't expect from a standard defacement. It's rather similar to the urge to rubberneck at a car crash: it's both horrific and exciting at the same time.

If my assumption is incorrect and no one is interested, I will humbly tuck my metaphoric tail between my legs and refrain from posting such things again.

Page as it appeared on June 5, 2009 12:15AM EDT: http://pastebin.com/f751e9f5b

The post is a little low on details concerning the actual exploit used, but there's pretty massive carnage. Let's hope the admins have offsite backups.

For those who don't know of Astalavista, it was a popular website for "hackers" with relatively low-quality content. It started in 1994, and was one of the first search engines for computer security information. It hosted software exploits, and quickly degenerated into a forum for sharing software cracks, spyware, and virii.

Being a security-related website, you'd expect the owners to be a little more careful, which is why this is interesting.

Internships are generally for University students, but it's not a completely strict rule. I worked with a going-on-thirty intern, a graduate student with a wife and a kid! You'll definitely get some odd looks as a non-student, but there's nothing stopping you.

However, given that, I would shy away from the intern route. It is a step backwards in terms of respect and resumé building, and you have enough seniority to set your goals higher than an intern.

I would seek out a full-time job doing some interesting work. Amazon might be a good pick: they have a lot of interesting problems there, and they're looking for solid talent. I had an interview with them for an internship a while back, but ultimately declined the offer for a better position.

Also, don't reject anything that's non-webbish. I know the Web 2.0 / AJAX / Social shopping cart siren is appealing, but there are a lot of cool problems being solved in big established companies too.

If the password hashing scheme is secure (bcrypt, as tptacek repeatedly recommends) dictionary attacks become non-trivial and slow. It's still possible to brute force the database, of course, but the time required makes the attack less profitable.

I would thus argue that a secure hashing schema is significantly better. This is assuming the programmer uses bcrypt in the first place, which is a questionable assumption: even popular projects like phpBB use MD5 for password hashing. (The fools.)

If MD5 is used then I would wholeheartedly agree with you: I've used http://milw0rm.com 's MD5 hash breaking service plenty of times to know why I shouldn't use that algorithm in my own code. (One of my old passwords is in the database, but I'm not telling you which one.)

From a theoretical security perspective, it's a terrible idea to store passwords in plaintext, but again there's a difference between theory and practice as you've stated. If your auditing can reduce/eliminate unauthorized out-of-band database access, then in practice storing plaintext passwords isn't a huge problem.

However, there's another practical aspect to consider: the password security of users. A perfect example from a month ago is a Christian dating website called Singles.org. The 4chan crowd discovered that if you replaced your user ID on the "profile edit" page with another user ID, you could edit another person's profile. The page also helpfully displayed the registered e-mail address and password, in plaintext.

Now, this is terrible programming on multiple levels, so you might want to discount my anecdote, but the attack vector isn't my main point.

The 4chan crowd, ravenous beasts that they were, attempted to use the Singles.org password to log into the victim's e-mail account. And their Facebook account. And their PayPal account. You can imagine the chaos they caused.

The user base had terrible password security, so easily around 20% of the accounts had the same password across multiple websites. I don't think it's an uncommon statistic: sadly, even I as a security-conscious person have used the same password more than once.

Our efforts should be to secure an application against all attack vectors, but hashing passwords is a veritable last defense to prevent an attack from spreading on to other websites.

Regardless of how an application is exploited, it's a safe assumption that the users' poor password security could spread the attack further. I would thus claim that plaintext passwords be at least a "medium" security issue.

It could have been worse, fortunately. The attacker broke into a Twitter admin's Yahoo account, and used that information to gain access to the Twitter admin CP. Very little was compromised. You can see screenshots of the Control Panel here: http://www.businessinsider.com/what-twitter-looks-like-for-t...

I've worked at a very large (60,000+ employee) company, so perhaps my background clouds my judgment somewhat, but I think requirements documents are quite helpful. The Software Functional Specification that was handed to me provided a good background to the problem space.

When I wrote the Software Design Specification (100 pages, oof...), I easily solved 2/3 of the bugs before I touched a single line of C code. I was surprised, since I didn't think I would enjoy the documentation process, but it really helped. I designed my module using English and pseudo-code, sent the spec around for comments, and when the spec was approved it was a (somewhat) simple matter of conveying a solid design into C.

Meetings still suck and should be minimized, but documentation is really essential. I always glance at the Design Spec for a feature before going into the code, since it gives you some solid background as to what exact problem they were trying to solve.

Sadly, this is outside my area of expertise. I will nonetheless attempt to answer your question, but please take my words with a grain of salt.

Before we even begin delving into true RNGs, it is worthwhile to consider if we're over-engineering the problem. Is a PRNG "good enough" for the task at hand? In most cases, it is. A well-seeded PRNG, such as the ones present in modern-day Operating Systems, are suitable for most tasks not involving National Security.

However, if you have a genuine need for a true RNG, a computer algorithm certainly won't be generating it. Computers are by nature deterministic, and thus are very poor at behaving unpredictably. Thus, like with all good problems, we are forced to enter the realm of physics.

The fundamental problem is, who will be observing the source of randomness? To my knowledge, there isn't a physical source of randomness that is observable to everybody. (I did some quick googling to confirm my suspicions, but if you're planning on using my words to do anything useful, please confirm my statement!). Thus, as I see it, you have several options:

1) Your idea, where all parties derive a true random number from physics and publically sum everyone's numbers together. Your qualifiers (2) through (4) hold, but (1) is difficult. In this case, a certain number of rogue nodes will be able to manipulate the computation. I remember a Professor of mine, who does research in this field, stating the minimum number of truthful nodes needed in a distributed computation is (2/3)n + 1, but again confirm this number for yourself.

My point here is, using the public-summing method, you are faced with the difficult problem of determining if a node is attempting to manipulate the system. While a provable solution has been found, after decades of research across the globe, my Professor still is working on the problem, thus demonstrating it is not an easy task.

2) Have a single computer (say, random.org) that is observing a true RNG, and publicizes the result for all to see. Of course you'd use asymmetric crypto so that all parties can prove that they've received the correct number.

Again, your qualifiers (2) through (4) pass, but (1) presents a different problem. We're back to where we started: do you trust random.org?

However, it's an easier task to make an authority trustable than a peer in a distributed computation. We trust Verisign to be a certificate authority, because we believe their security practices are half-decent, and they can be audited. (Every year all CA's are independently audited by WebTrust.org using pretty strict criteria.)

The same could be done for random.org: why not require certification and frequent auditing of their RNG equipment?

The other nice thing about RNGs is that you can audit them yourself, given enough time and expertise. When viewed correctly, poor RNGs will have distinct patterns visible to the eye (example: http://www.cs.hku.hk/cisc/projects/va/index.htm ).

The crux of my argument is: I don't know of a true RNG, that upon observation by multiple parties, all will receive the same random number. My instinct and my research says that none exist, but I would love to be proven wrong. Crypto experts, correct me!

If you'd like more information, Wikipedia is always invaluable: http://en.wikipedia.org/wiki/Hardware_random_number_generato...

I'm sorry if this response is off-topic, but your last question piqued my curiosity so I would like to answer it.

There is an authoritative source of random numbers. In 1955, The RAND Corporation (a Cold War-era think tank) published a wonderful book entitled "A Million Random Digits with 100,000 Normal Deviates". Amazon.com has a copy of it, including some amusing reviews: http://www.amazon.com/Million-Random-Digits-Normal-Deviates/... .

For a good source of truly random numbers accessible from an API, I personally use http://random.org . They use atmospheric noise to create random numbers, which ultimately boils down to the true randomness that is Quantum Mechanics. It's not suitable for high-security applications -- I could do some network trickery and redirect your API request to my server that always returns 1.0 -- but it's better than the PRNGs on modern computers.