Slashdot Mirror

theodp writes: To paraphrase the J. Geils Band, Maddie Zug's high school computer science homework is the centerfold. In a Washington Post op-ed, Zug, a student at the top-ranked Thomas Jefferson High School for Science and Technology, argues that a centerfold does not belong in the classroom. "I first saw a picture of Playboy magazine's Miss November 1972 a year ago as a junior at TJ," Zug explains. "My artificial intelligence teacher told our class to search Google for Lena Soderberg (not the full image, though!) and use her picture to test our latest coding assignment...Soderberg has a history with computer science. In the 1970s, male programmers at the University of Southern California needed to test their image-processing algorithm. They scanned what they had handy: the centerfold of a Playboy magazine. Before long, the image became a convention in industry and academia." (Wikipedia has a nice background, too.)

theodp writes "The Motley Fool reports that the Data Scientists at LinkedIn have been playing with their Big Data, ranking schools based on how successful recent grads have been at landing desirable software development jobs. Here's their Top 25: CMU, Caltech, Cornell, MIT, Princeton, Berkeley, Univ. of Washington, Duke, Michigan, Stanford, UCLA, Illinois, UT Austin, Brown, UCSD, Harvard, Rice, Penn, Univ. of Arizona, Harvey Mudd, UT Dallas, San Jose State, USC, Washington University, RIT. There's also a shorter list for the best schools for software developers at startups, which draws a dozen schools from the previously mentioned schools, and adds Columbia, Univ. of Virginia, and Univ. of Maryland College Park. If you're in a position to actually hire new graduates, how much do you care about applicants' alma maters?

mbrubeck writes "After almost two years of development, the free cross-platform sound editor Audacity has released a new stable version for Linux, Mac OS X, and Windows. Audacity 1.2 has major improvements including professional-quality dithering and resampling, and new pitch- and speed-changing effects. Our previous stable release was announced on Slashdot in June 2002. More recently, Audacity was presented at this year's CodeCon in San Francisco."

An anonymous reader writes "The Bar-Monkey is a bar built around a 486 running linux that can dispense an 8 ounce mixed drink in under 10 seconds. It uses a Matrix Orbital Serial LCD panel with a keypad built into the bar surface for user input. Three Harvey Mudd College students built the bar in their spare time last semester. The bar holds 16 ingredients with which it can currently mix 188 drinks stored in its drink database. Total project cost: $235."

Matthew Priestley has taken a break from slaving for the man to write us a piece where he takes on the convential wisdom that Security through Obscurity isn't secure at all, and tries to argue that sometimes it is. Click the link below to read it. Lots of interesting stuff and some good examples. Its worth a read. The following was written by Slashdot Reader Matthew Priestley Obscurity as Security Disclaimer: The author of this paper works for Microsoft, but his opinions may not be those of Microsoft. In fact, they aren't. The author hereby declares that nobody important is even aware of his existence and that the closest he has ever come to plotting with Bill Gates on the Master Plan was when they used adjacent urinals this one time. The author did not peek.

0 Introduction With the popularity of the open-source mindset, a general contempt has drizzled upon all forms of obscurity. The concept of security through obscurity (STO) in particu lar has been decimated. Security through obscurity, which relies on the ignorance of attackers rather than the strength of defenders, is dead in all but practic e. The victory of the opposing full disclosure approach is so complete that proposed ta ctics die at the mere hint they are a form of STO.

This paper suggests security through obscurity can and does work in certain strictly limited ways, and should not be eliminated unthinkingly from the admin's arsenal. It further implies that the boundaries between STO and 'real' security are blurry and deserve evaluation. However, this paper in no way proposes obscurity as a method for keeping secrets in the long term.

1 Full disclosure does not apply to instantiated data Instantiated data - the data used by specific instances of an algorithm - do not fall within the scope of full disclosure. Were this not so, then even the simplest password would violate the ban on security through obscurity. Passwords are secrets known only to their creators, and password entry is commonly obscured, as in the case of the 'shadow' login of UNIX. While the login protocol may be open, passwords themselves are a form of STO, with obscurity localized in the password string.

Instantiated data are exempt from full disclosure because the risk from their failure is limited. When a script cracks a password, the damage done to the secure system extends only as far as that password's scope. The cracker cannot use the compromised string to gain power directly in another system, even if that system runs the same password protocol. Nor can anything be inferred about the value of one password merely from the value of another with equal or lower permissions.

A similar example of instantiated data obscurity is the private key that forms the basis of asymmetric cryptography. So obscure is this information that it is rare for even the owner to be familiar with its precise value. But such obscurity is a necessary element of modern security schemes. Strong security does not eliminate obscurity - rather, it localizes obscurity to instantiated data. The phrase in cryptology, 'carry all security in the key' might be better phrased 'carry all obscurity in the key'.

2 Full disclosure does not apply to time-limited secrets Secrets that expire after a short lifetime can be protected by a wider array of techniques than long-standing secrets. The defense of information that will be irrelevant in a matter of hours or days may not warrant fully peer-reviewed security. Consider the famous Navajo code-talkers of World War II. Among the Americans coordinating the at tack against Japanese-held islands in the Pacific were a number of Navajo Indians, who spoke a slangy version of the complex Navajo tongue. Commands from HQ were issued through these code-talkers, who encrypted and decrypted with an alacrity that belittled the automated methods of the day. This is an excellent example of time-limited security through obscurity. Secret languages are excellent security in the short-term, but however cryptic Navajo may be, it is a code subject to human betrayal. Use of Navajo against the Japanese much beyond the 3-year window of the war would have been unwise. But because the secrets of American strategy in the Pacific were irrelevant after the conclusion of the fighting, the long-term weakness of obscure Navajo as a security measure was unimportant.

3 Obscurity serves as a tripwire Perhaps the classic example of wrongheaded STO is the administrator who modifies his web server to listen on a nonstandard port - thereby confusing attackers, as the theory goes. Considering the degree to which tasks such as port scanning can be automated, the naivete of this defense seems plain. The cracker might be forced to check all 64512 unreserved ports, but eventually the concealed web server will be found. This appears to be a weakness of STO, but if manipulated correctly, it is in fact a great strength. Imagine that our same admin had also invoked a tripwire script and set it to listen on one or more unused ports. When the tripwire is probed with a SYN packet from a cracker trying to locate the web server, instantly the system goes to full alert. The packet is logged and the admin's pager sounds like an alarm.

Such tripwire approaches work because they do not expect obscurity to keep information hidden. Rather, they obscure information as a ploy to force invaders into showing their hand. Because the obscured implementation differs on each system, crackers must resort to guess-check scanning before attacks can commence. But tripwires are deployed throughout the system, anticipating this very move. Running an automated kit suddenly becomes a risky proposition, and even talented crackers must gamble on, for example, whether 'root' is really the name of the primary account or merely a hotline to the authorities.

Lighthearted implementations of this approach are a staple in the popular "Indiana Jones" films. In one scene, Jones is confronted with a hallway of lettered tiles, all seemingly alike. To cross safely he must step only on those tiles with letters corresponding to the secret word 'Jehovah'. The penalty for a misstep is to crash through the floor and plummet into a gaping pit. Attackers not privy to the password would find an exhaustive search less than optimal in this case. When traps are mingled with genuine data, STO can be a powerful disincentive. Such measures do not make a given machine resistant to breach in the long term, any more than medieval moats could ultimately protect their castles. But like moats, tripwire obscurity provides a critical buffer against attackers, allowing defenders room to breathe.

4 Asymmetric cryptography exhibits traits of STO Despite the notion that asymmetric cryptography such as RSA is 'real' security, in some aspects these methods resemble STO. Indeed, this entire class of cryptography is founded on the hopeful guess that a certain mathematical problem is intractable. The back door into cryptographic methods that rely on multiplying primes is, quite simply, to develop a swift means of factoring those multiples. This NP-time problem must be solved before a private key can b e derived from its corresponding public key, and the notorious difficulty of NP problems leads some supporters to characterize asymmetric cryptography as 'prova bly secure'. This is far from the case - there is uncertainty among mathematicia ns as to whether this problem will even prove non-trivial once approached from t he right angle. Startling progress has been made in solving similar 'impossible' problems using innovative ploys - for example, DNA computers can now solve the Traveling Salesman problem in linear time. Given that asymmetric encryption is used widely in the world's e-commerce infrastructure, the repercussions when this piece of obscurity is cracked are disturbing to contemplate.

One telling argument against STO is that it promotes a false sense of security, leading admins into complacency. But the complexity of asymmetric cryptography, combined with reports of its infallibility, can produce much the same effect. Co nsider this social-engineering exploit of digital signing. Using a tool such as m akecert, the cracker generates a root certificate with the name 'Verisign Class 1 Primary CA' and uses it to sign an end-entity certificate with the subject 'CN=Rob Malda, E=malda@slashdot.org' (CT:Please don't. I'm used to posers pretending to be me in Quake, but not on email ;) The cracker then sends the email to an enemy, using a client that does not validate e-mail addresses and spoofing the return address friendly name. The inexpert recipient, thinking all is in order and knowing that digital signatures never lie, trusts the root certificate and hence forth carries on a conversation with a false CmdrTaco. Only scrutiny of the headers will reveal the mail is actually going to a different address. The widely made claim that public-key cryptography is 'real' security and completely unrelated to 'false' STO delivers a more powerful illusion of security than anything an XOR'd password file can provide.

Even brute-force cryptanalysis has parallels in STO. Suppose we wish to conceal the passwords for a number of Swedish bank accounts. We resolve to write them to a secret location on our hard drive, perhaps a few unused bytes in a file sector. Only we, who know the lucky offset, can read the data. This form of concealment is a typical case of secruity through obscurity. The integrity of our secret depends on the ignorance of the cracker, and a trial of all 2^n possible locatio ns compromises the system. But in what way is this fundamentally different from the 'genuine' security of n-bit encryption? To break this form of security, 2^n keys are generated and tried agains t the cipher text until the result is a plain body. Is the difference between this 'true' security and the 'false' STO merely than n is considerably larger in encryption than in the case of hard drives? But this implies that our real error lay, not in reliance upon obscurity, but in having a hard drive of insufficient size!

5 Conclusions Security in the absence of obscurity is not strictly possible, but good systems both localize and advertise their points of obscurity. When the admin is fully a ware of the obscurity in a system, tripwires and instantiated data can provide a useful complement to more rigorous security techniques. Obscurity cannot keep information safe or concealed for long, but it can make attacks risky and destroy the effectiveness of automatic kits. These benefits should not be dismissed as an article of faith.

Crocodile wrote in to say that x11amp 0.9 alpha2 is out for those of you MP3 junkies out there. Remember that article awhile back about the pictures from Pi? JHoyt sent us a link to a script fu script that will do it. Neato. Infinite background possibilities. Jeff Davis sent us a link to Beowulf Underground, a new news site for those interested in news revolving around Beowulf Linux Clusters. From the random Slashdot Mainstream References box, we've got a bit Stephen Horne sent at ABC News article on the Windows Refunds. Yippee. Now that the boring old serious stuff is out of the way, let's take a break.

Ok, that's enough. Now some funny stuff to help end your day on a good note. The Cunctator sent us link that can only be described as the hamster dance. GloiDemon sent us a link to DrZaius.com, a new humor site. How can you resist Dr Zaius? Phil Gregory sent us a link to a Segfaultstory called the Gospel of Tux. Check it out. Rishi Hemrajani sent us a link to a book that everyone should own. I think we posted this a few months ago, but it warrants a rerun.

Leif Hardison wrote in to say that hardware.doa.org is is sponsoring a contest for the most inovative case designs. Peter Renshaw wrote in to tell us about the ICQ GNU Project which aims (surprise!) to produce an open source ICQ proggie. Mike Rust wrote in to tell us that SNES9x 1.0 for DOS been released. It supports transparency and SuperFX emulation and all kinds of neat stuff. Linux Port should be Coming. Joshua Fouts wrote in to plug The Online Journal is following the proceedings involving Kevin Mitnick's trial in detail. They also have an article about Chris Lamprecht. Both are pretty interesting. Lastly Michael Dillon sent us a link to an interesting article on 4 phases of Linux acceptance.