Entries Tagged "history of computing"
Page 1 of 1
Lots of them weren’t very good:
BSD co-inventor Dennis Ritchie, for instance, used “dmac” (his middle name was MacAlistair); Stephen R. Bourne, creator of the Bourne shell command line interpreter, chose “bourne”; Eric Schmidt, an early developer of Unix software and now the executive chairman of Google parent company Alphabet, relied on “wendy!!!” (the name of his wife); and Stuart Feldman, author of Unix automation tool make and the first Fortran compiler, used “axolotl” (the name of a Mexican salamander).
Weakest of all was the password for Unix contributor Brian W. Kernighan: “/.,/.,” representing a three-character string repeated twice using adjacent keys on a QWERTY keyboard. (None of the passwords included the quotation marks.)
I don’t remember any of my early passwords, but they probably weren’t much better.
Really good article about the women who worked at Bletchley Park during World War II, breaking German Enigma-encrypted messages.
EDITED TO ADD (7/13): There’s also a book: The Debs of Blechley Park and Other Stories, by Michael Smith.
Gene Spafford writes about the history of Practical Unix Security.
From the CIA archives: Orrin Clotworthy, “Some Far-out Thoughts on Computers,” Studies in Intelligence v. 6 (1962).
EDITED TO ADD (4/12): A transcript of the original, scanned article.
The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today’s global economy remains dependent upon them.
While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.
Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.
The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.
Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which “known” security problems have not always been addressed by all vendors. In many cases vendors have implemented quick “fixes” to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.
As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.
Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.
There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.
This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.
Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.
Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.
Sidebar photo of Bruce Schneier by Joe MacInnis.