<![CDATA[[SecurityRatty] tag: academic]]> http://securityratty.com/tag/academic Tue, 27 May 2008 18:45:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Dead Possum Patrol Aided by NYC Wireless Network]]> http://securityratty.com/article/5a95b3f7c00f05c86aaf0e2ae4310dbd http://securityratty.com/article/5a95b3f7c00f05c86aaf0e2ae4310dbd I'm going for the sensational in the headline, but it's part of the story's intro, too: The New York Times reports on some early uses of the city's $500m wireless network designed for non-public uses. The network uses UMTS over licensed spectrum specifically devoted the city's municipal and public safety purposes.

One of the projects leaders uses terms that should warm every New Yorker's heart, if he or she knew what they meant. IT head Paul Cosgrave says the system will overcome silos, an often disparaging term for the separation of resources across groups that can only expensively be overcome. It's the government and business equivalent of the academic problem of a lack of cross-discipline focus.

One of the first applications allows sanitation workforce managers a frighteningly precise amount of knowledge about routes, activities, and behavior of trucks in their territory. Let's hope that's not misused! Efficiency is one thing; micro-management is another.

Another project is testing wireless water-meter reading. The city hopes to spend $90 per meter for the upgrade and shed part of a $12.2m contract with Con Edison that covers 850,000 units. What should be useful about this is that problems can be detected by monitoring waterflow patterns, which in turn allows the often huge problems that take months to notice (occurring underground or in basements where rivers formerly flowed) to be stopped before they turn into multi-million-dollar problems for property owners or the city. Anytime anything happens in Manhattan, it's a multi-million dollar problem.

]]> Fri, 27 Jun 2008 15:54:02 +0000 network city city hopes 500m wireless network frighteningly precise amount head paul cosgrave sanitation workforce managers overcome public safety purposes Dead Possum Patrol Aided by NYC Wireless Network <![CDATA[Backdoording Cyber Jihadist Ebooks for Surveillance Purposes]]> http://securityratty.com/article/aeea8b0a7f192cc968531f573ed672a4 http://securityratty.com/article/aeea8b0a7f192cc968531f573ed672a4 It appears that cyber jihadists are striking back at the academic and intelligence community, by binding their propaganda Ebooks with malware, then distributing them across different forums, thanks to a recently analyzed Ebook entitled "The Al-Qaeda network's timely entrance in Palestine" distributed by the Global Islamic Media Front - hat tip to Warintel.

If it were posted by a newly joined forum member, it would have logically raises the suspicion that it's in fact intelligence agencies spreading malware infected Ebooks around cyber jihadist forums, but it's since this one in particular is being distributed by what looks like a hardcore cyber jihadist, it brings the discussion to a whole new level.

What are they trying to achive? Abuse the already established trust of their readers and cyber jihadist supporters in order to snoop on their Internet activities, or it's the academic and intelligence community they are trying to monitor? In times when botnets can be rented and created on demand, they seem to be more interested in infecting their enemies. Moreover, I suspect that prior to the forum posting, private messages and emails were automatically sent to notify members whose number of posts at the forum greate outpace those of average observers, perhaps the target in such an attack.

The malware is detected by 9 out of 33 antivirus scanners as Trojan.Midgare.gra. Consider reading a previous post on "Terror on the Internet - Conflict of Interest" as well as through the related posts summarizing all the cyber jihadist research I've conducted so far.
]]> Wed, 25 Jun 2008 13:06:38 +0000 ebooks intelligence community cyber jihadist forums forums cyber jihadist research internet malware hardcore cyber jihadist forum Backdoording Cyber Jihadist Ebooks for Surveillance Purposes <![CDATA[Will Idiocy Ever End?]]> http://securityratty.com/article/7a7383b72d02885cfc7f7edc37372687 http://securityratty.com/article/7a7383b72d02885cfc7f7edc37372687 FIRST2008 and a typical conference discussion over beer has turned - again! - to academic security research.

I lamented and ranted and rambled about it (here, here, here), but I am still shocked. I come from academic background myself and it is unthinkable to me that a research physicist today will write a thesis on 2nd Law of Newton or will set to prove that objects tend to fall down while dropped. Or that they, in fact, "fall up."

However, that is the type of stuff I see in academic security papers that I occasionally get to review. Based on our FIRST conversation, other people who happen to retain ties to academia are reporting the same: research work that confuses "phishing" with "fast flux networks" (thanks Jose), inventing a new intrusion detection "paradigm, " and all sorts of other bizarre crap continues to be cooked and submitted to publications.

When will this end? Why can't you people tackle REAL problems? Or at least useful and hard classic problems? Or, at the very least, learn WTF is going on the real world of operational security before you do ANYTHING? The maybe you stop saying things like "in general, IDS is considered to be a security tool" as if it was some kind of Zen wisdom (a quote from a pathetic excuse for a paper that I reviewed recently...)
About me: http://www.chuvakin.org
]]> Wed, 25 Jun 2008 02:15:00 +0000 research academic security research people people tackle real bizarre crap continues typical conference discussion research physicist academic security papers fast flux networks Will Idiocy Ever End? <![CDATA[The Arizona Office of the Auditor General finds plenty of holes]]> http://securityratty.com/article/7c68cfbfdcec6acecbe25fdbae0ec186 http://securityratty.com/article/7c68cfbfdcec6acecbe25fdbae0ec186 Security Breach

Date Reported:
6/19/08

Organization:
The Arizona Board of Regents

Contractor/Consultant/Branch:
Arizona State University
University of Arizona
Northern Arizona University

Victims:
Students, faculty and staff

Number Affected:
"more than 10,000"

Types of Data:
Names, Social Security numbers, student identification numbers, addresses, phone numbers, e-mail addresses and user accounts

Breach Description:
"The Office of the Auditor General has conducted a performance audit of information technology security at Arizona State University (ASU), the University of Arizona (UA), and Northern Arizona University (NAU) pursuant to Arizona Revised Statutes (A.R.S.) §41-2958."  "ASU’s, UA’s, and NAU's Web-based applications are vulnerable. Auditors were able to gain unauthorized access to sensitive information, such as social security numbers, and could have modified or deleted important university information."

Reference URL:
Arizona Office of the Auditor General's report titled "Arizona’s Universities—Information Technology Security"
The Arizona Daily Star

Report Credit:
Arizona Office of the Auditor General

Response:
From the online sources cited above:

The Office of the Auditor General has conducted a performance audit of information technology security at Arizona State University (ASU), the University of Arizona (UA), and Northern Arizona University (NAU) pursuant to Arizona Revised Statutes (A.R.S.)
§41-2958.

Information technology (IT) security practices are important for Arizona's universities to protect large amounts of sensitive and confidential information that are stored on their computer systems, including information for more than 122,000 students and nearly 25,000 faculty and staff.

Universities in general are attractive targets for computer hackers because universities traditionally have a strong culture of academic freedom that values open access to information and a free exchange of ideas.

University IT security problems are occurring more often through weaknesses in computer programs called Web-based applications.

The Arizona universities combined use at least 205 significant Web-based applications for educational and administrative purposes, such as curriculum and course management, documenting personal information for admissions and financial aid, and processing financial, payroll, and other transactions, such as purchasing parking permits.

ASU’s, UA’s, and NAU's Web-based applications are vulnerable.

Auditors were able to gain unauthorized access to sensitive information, such as social security numbers, and could have modified or deleted important university information.

Auditors were able to gain this access by exploiting some critical and commonly found weaknesses that exist in many of the universities' Web-based applications.

Security weaknesses in one Web-based application allowed auditors to access a database and obtain more than 10,000 records with names and social security numbers.

Auditors also obtained other records that contained student identification numbers, addresses, phone numbers, and e-mail addresses.

Auditors also had the ability to modify and delete this information.

In two other applications, auditors were able to exploit a security weakness that would have allowed them to take over a large number of user accounts, including accounts with high-level access.

In many applications, auditors discovered a security flaw that would allow an attacker to take over user accounts and install malicious software.

Auditors did not attempt to identify every flaw that may exist because the testing was designed to determine what the impact could be if certain identified vulnerabilities were successfully exploited.

To better protect the information processed through their Web-based applications,
ASU, UA, and NAU need to:

  • Conduct regular security assessments of Web-based applications. The universities first need to determine how many Web-based applications they have and then make provisions to regularly update their lists of applications.  They then need to develop and implement procedures for regularly conducting security reviews of their critical Web-based applications.
[Evan] Even though it seems like it’s the same story in company after company, I am still amazed by how many organizations don't know what or how many applications that have (not to mention servers, clients, routers, switches, wireless access points, etc.)!  Its pretty hard to secure something if you don't know it exists, and just because you don't know it exists does not mean you are not responsible for it.

  • Develop a university-wide policy and associated procedures for updating Web servers, which are computers that host Web-based applications. Software vulnerabilities are constantly being discovered and publicized, and the universities need to develop or enhance: (1) procedures for identifying vulnerabilities relevant to their Web servers, (2) a timeline for reacting to notifications of newly discovered Web server vulnerabilities, and (3) a process for determining whether to apply a software update, establish another control to address the Web server vulnerability, or accept the risk of not updating the software.
  • Ensure that security is built into the process for developing Web-based applications. According to ASU, UA, and NAU officials, none of them have university-wide security standards for developing applications. According to an IT best practice, building security into the development process is more cost-effective and secure than applying it afterwards.
  • Provide training to application developers so that they are aware of common Web-based application vulnerabilities and methodologies that can be used to avoid them. None of the universities have a training program that is mandatory for all users and geared toward an individual's role within the university.

All three Arizona universities have taken some key steps toward developing an overall
IT security approach; however, additional work is needed.

Creating information security staffs--Over the past few years, ASU, UA, and NAU have established and filled information security officer (ISO) positions and made these ISOs responsible for information security efforts university-wide.  Until the ISOs were hired, the universities have not had any staff whose sole responsibility included directing and coordinating all aspects of information security across the university.
[Evan] Typically, this position is more effective if it reports directly to an executive such as CEO, President, etc.  Information security is not an IT problem, and often times there is a conflict of interest if an ISO reports up through the IT organization.

Developing information security programs--The universities are at varying stages in developing formal programs to guide their information security efforts, but none have yet developed all the standards or procedures needed to support a complete information security program. The universities are in the beginning stages of implementing their information security programs, in part because the ISO positions are relatively new.

[Evan] The report goes on to address specific findings and recommendations for all three of the schools.  In my opinion, the report is very well-written and definitely worth your reading time!

Commentary:
I didn't provide much commentary on the Auditor General's report because it really speaks for itself.  It was a good read (for a security guy anyway).  Kudos to the Arizona legislature for funding the audit, Kudos to the Auditor General on the findings, the report, and the excellent recommendations, and Kudos to the schools for their agreements and plans for improvement.  I feel a little giddy and I'm not really sure why.

Is anyone planning to notify the people whose information was found to be vulnerable to attack and exploit?  I would be surprised if the auditors were the first to find these chinks in the armor.

I highly recommend reading the report.

Past Breaches:
Unknown

]]> Mon, 23 Jun 2008 08:28:27 +0000 information information security officer personal information information security staffs confidential information information security university information sensitive information sensitive The Arizona Office of the Auditor General finds plenty of holes <![CDATA[University of Florida student information online for years]]> http://securityratty.com/article/70535b81354ea161a0135979f7d38509 http://securityratty.com/article/70535b81354ea161a0135979f7d38509 Security Breach

Date Reported:
6/11/08

Organization:
University of Florida

Contractor/Consultant/Branch:
Office for Academic Support and Institutional Services

Victims:
Students

Number Affected:
"more than 11,300"

Types of Data:
"names, addresses and Social Security numbers"

Breach Description:
"GAINESVILLE, Fla. - University of Florida officials today mailed letters of notification to more than 11,300 current and former students regarding a privacy breach that resulted in names, addresses and Social Security numbers being posted online that may have been accessible to the public."

Reference URL:
University of Florida
Miami Herald
Inside UF
United Press International

Report Credit:
University of Florida

Response:
From the online sources cited above:

GAINESVILLE, Fla. - University of Florida officials today mailed letters of notification to more than 11,300 current and former students regarding a privacy breach that resulted in names, addresses and Social Security numbers being posted online that may have been accessible to the public.
[Evan] Not "may have been".  The information was accessible to the public and was not even protected by a password.

The student information was actively used from 2003 through 2005 and remained posted until it was recently discovered during a routine audit of UF systems.
[Evan] If I am reading this right, this means that some of the personal information was available publicly for ~5 years!

School officials emphasized that the site would not have been easy to find and they do not believe it was accessed by anyone outside the school.
[Evan] There is no security through obscurity.

"The risk of someone outside actually finding this information and using it inappropriately is very low," - Steve Orlando, UF Spokesman
[Evan] I wonder how Mr. Orlando came to the conclusion that the risk of disclosure and misuse is "very low".  As I understand, the server was publicly accessible, presumably via the internet.  If so, was the site indexed by search engines like Google, Yahoo, and Microsoft?  It is much easier to find information through a search index because folder structure is much less relevant.  The fact that this information was available for 3-5 years adds to the risk too.  I only know what I read and based on this and experience, I wouldn't classify this as a "very low" risk situation.  Either way, the risk was increased due to poor information security practice and was not necessary.

"We've done computer forensics, and we don't have any evidence that anybody accessed this information," he added.
[Evan] This indicates poor logging and monitoring which are both essential detective controls (in most situations).  Information security personnel (or admins) should be empowered to reconstruct events.

"But because we can't say that with absolute certainty, we're going through with the notification out of an abundance of caution," Orlando said.
[Evan] I am NOT a fan of the "abundance of caution" claims that seem more popular in breach notifications lately.  Organizations would be best advised to use an "abundance of caution" in the prevention and early detection of breaches by applying sound information security principles.

Since 2005, the site has been "dormant but accessible," said university spokesman Steve Orlando. "It was just sitting there."

The information has been removed and is no longer available online or elsewhere in the UF systems.

The breach occurred when former student employees of the Office for Academic Support and Institutional Service, or OASIS, program created online records of students participating in the program.

The student employees posted the information online so that they could work with it from remote locations, but they did not install security measures to keep others from accessing it as well
[Evan] I have so many questions and arguments.  Were the students aware of the risks?  If not, then there is probably an information security training and awareness problem.  Why was it necessary to include Social Security numbers in the records?  Why were the seemingly untrained students allowed to post the information without being stopped or detected?  I have many more questions, but I am starting to confuse myself now.

The university sent letters of notification to about 11,300 students whose information is believed to have been potentially compromised.
[Evan] Here's my take on the word "compromised".  If an organization cannot provide reasonable assurance that the information has not been subject to unauthorized disclosure, modification, or destruction, then the information has been "compromised". 

University officials were unable to find contact information for about 570, so they are asking students who were enrolled in CLAS from 2003 to 2005 and did not receive a letter but who believe their information may have been compromised to call UF’s Privacy Office Hotline at 866-876-HIPA and provide the requested information.

Anyone who thinks he or she may be one of the 570 people who were not notified is urged to go to privacy.ufl.edu and read the information posted there before calling the privacy hotline.

"This would certainly appear to be the largest privacy breach we've had," Orlando said.

We're in the process of strengthening some of those policies regarding what information can be posted and what security measures should be in place
[Evan] Good start.

Victim Reaction:
"Why would it be necessary to use a Social Security number instead of something else?" asked Reixach, pointing out that students were given ID numbers. "It's just silly".

"It's negligence on their part, especially if anyone has been affected with identity theft,"

Johann Arias, a spring CLAS graduate, had not heard about the breach Wednesday and said UF should be doing more to notify those affected.

"They always make information very prominent when you have a hold or owe them money," Arias said.

Commentary:
This is a case where poorly trained students are granted access or obtained access to confidential information and posted the information to an unsecured location which went undetected for years.  Bad all around. 

Past Breaches:
May, 2008 - University of Florida doctor loses job over breach
November, 2007 - University of Florida student info online

]]> Thu, 12 Jun 2008 06:41:30 +0000 information information online personal information information security confidential information information security personnel student information security measures install security measures University of Florida student information online for years <![CDATA[6,200 people notified of ETSU stolen computer]]> http://securityratty.com/article/911451a0e1146a7f545fba6f01a7a460 http://securityratty.com/article/911451a0e1146a7f545fba6f01a7a460 Security Breach

Date Reported:
6/7/08

Organization:
East Tennessee State University

Contractor/Consultant/Branch:
None

Victims:
"students, alumni and staff"

Number Affected:
6,200

Types of Data:
"personal information"

Breach Description:
"JOHNSON CITY, Tenn. - East Tennessee State University has sent a letter to 6,200 people whose identities could be compromised by the theft of a desktop computer."

Reference URL:
Knoxville News Sentinel
News Channel 11

Report Credit:
Knoxville News Sentinel

Response:
From the online sources cited above:

JOHNSON CITY, Tenn. - East Tennessee State University has sent a letter to 6,200 people whose identities could be compromised by the theft of a desktop computer.
[Evan] If an organization is going to allow confidential information to be stored on client computers, then the organization must properly control physical security or provide mitigating controls.  Servers are typically stored in climate controlled and physically secured rooms employing enhanced controls such as security cards, biometrics, locked racks, CCTV, etc.  If these controls are not present at the client computer, then mitigating controls need to be designed and implemented to counter physical theft.  One of the best controls to counter physical theft is encryption.  Of course it could be decided that allowing confidential information storage on a client computer poses an unacceptable risk, but this would require some risk management.

someone broke into a locked office and locked suite last month and stole a computer containing private information like social security numbers

there was no sign of forced entry, though the room was locked and a big screen tv was also stolen
[Evan] No forced entry causes me to think that someone did not "break into" the locked office.

the computer is password protected and files cannot be easily accessed
[Evan]  Oops, this is not true.  In most cases, these files ARE easily accessed.

there is a small possibility that the information could be compromised
[Evan] Based on my last comment, this one should be corrected.

Those who received the letter are asked to notify one of the three major credit bureaus and place a fraud alert on their files.

University Provost and Vice President for Academic Affairs Bert C. Bach said ETSU has set up a Web site with procedures for preventing or dealing with identity theft.
[Evan] I scoured the ETSU web site and couldn't find any information relating to this breach.  I wonder if the Web site that Mr. Bach refers to is a secure site and not accessible from the public internet.

Bach said the missing computer was stolen from a secured area on May 17.

ETSU officials are investigating.

Commentary:
I couldn't find much information about this breach other than that which was provided in the two short news reports.  When there is little detail, Evan speculates.

Past Breaches:
Unknown

]]> Mon, 09 Jun 2008 10:45:27 +0000 computer etsu information personal information client computer poses client computer confidential information desktop computer theft 6,200 people notified of ETSU stolen computer <![CDATA[University of South Carolina Moore School of Business breach]]> http://securityratty.com/article/337e47e0083fbc5d019fe4ba710c6c76 http://securityratty.com/article/337e47e0083fbc5d019fe4ba710c6c76 Security Breach

Date Reported:
6/9/08

Organization:
University of South Carolina

Contractor/Consultant/Branch:
Moore School of Business

Victims:
"faculty, staff and students"

Number Affected:
~7,000

Types of Data:
"some personally identifiable data"

Breach Description:
"The University of South Carolina is warning about 7,000 faculty, staff and students that some of their personal information was on a desktop computer stolen from an office at the business school."

Reference URL:
The State

Report Credit:
The State

Response:
From the online source cited above:

The University of South Carolina is warning about 7,000 faculty, staff and students that some of their personal information was on a desktop computer stolen from an office at the business school.

Monday evening, May 26th, 2008 computer hardware containing data files was stolen from the Dean’s Office

"Among the items was a desktop computer belonging to Deputy Dean Dr. Scott Koerwer,"
[Evan] I am semi-sure that a business case could be made to allow Dr. Scott access to confidential information, but there should be NO business case allowing for the storage of this information on the desktop computer he uses.  I also doubt that he needs access to Social Security numbers.

"As a result of the computer being stolen, we feel it is possible that some personally identifiable data could have been compromised."

There is a possibility that some personal information such as social security numbers, annual pay, and term of service at the University may have been compromised.

As soon as the unauthorized access was discovered (May 27, 2008), USC initiated its incident handling procedures, which includes notification of affected individuals.
[Evan] I am glad to read that USC has incident handling procedures.  Many organizations do not.

university officials have no evidence anyone's personal information was accessed
[Evan] It's probably too soon for evidence.

"We feel the responsible thing for us to do is to notify those persons whose data was contained in the computer, and advise them of the fact, and share with them some useful steps they may want to take for additional protection,"

the university is notifying about 130 faculty and staff at the Moore School, and just under 7,000 students who took business courses in the last academic year

the university’s Division of Law Enforcement and Safety and Office of Information Technology are investigating the matter

The Moore School of Business has taken precautions to minimize future security risks.
[Evan] Like what?  Anybody can make a statement like this.  People should be provided with some details.  Details that don't give away too much, but enough to instill confidence.  This statement means little to me.

Deputy Dean Koerwer circulated a letter to students dated June 6 that suggested some steps they might take to protect themselves from identity theft.

Guidance regarding the burglary, including answers to frequently asked questions that we anticipate on identity protection, identity theft, and precautionary measures is available at the University’s website: www.sc.edu/identity/index.shtml

We deeply regret any inconvenience or concern that this incident may cause. We assure you that the University, along with the Dean’s Office, is working diligently to prevent this type of incident from recurring.

Please know that the university faculty and staff are committed to protecting all personal information.

Commentary:
This is a physical, administrative and potentially logical information security breach.  There is no information provided about what physical controls were present to prevent an intruder from stealing the desktop computer, so it is difficult to comment.  There is little information provided around the administrative controls in place, but we can imply some things.  Due to the fact that the school did not state that the storage of confidential information on client computers is prohibited, maybe we can assume that it is permitted.  There was no mention of encryption, so I question whether or not this is a logical control that may have been lacking.

Information security is a holistic discipline and the controls I mention above are a very, very small part of the big picture.

Past Breaches:
September, 2007 - University of South Carolina Mistake Leads to Breach of 3,199 Records

]]> Mon, 09 Jun 2008 09:38:01 +0000 school university information personal information business business school university officials computer moore school University of South Carolina Moore School of Business breach <![CDATA[PCI Compliance: Learning from the U.S. Air Force]]> http://securityratty.com/article/a514023426703b08ce05ea1bcc5902d7 http://securityratty.com/article/a514023426703b08ce05ea1bcc5902d7 SC Magazine has an interesting piece on PCI compliance (section 6.6) and the author maps it against the US Airforce’s response to web breaches.

From SC Magazine:

In the spring of 2005, someone broke into a web application for the Assignment Management System of the United States Air Force, and stole 33,000 records. As data breaches go — judged by numbers alone — this is a drop in the bucket. But judging by extent of loss, the breach was expansive. The hackers stole the names, career information, birth dates, social security numbers, marital status, number of children and academic records of 33,000 Air Force Officers. Three years later, no one knows where the data went.

In June of this year, Section 6.6 of the PCI Data Security Standards (DSS) becomes mandatory. Online merchants that process credit card payments must either conduct a code review for their applications or install an application-layer firewall. The standard offers a choice, but there really isn’t any choice at all.

Read on.

Article Link

]]> Wed, 04 Jun 2008 20:12:46 +0000 air force air force officers pci compliance assignment management system records data data breaches academic records online merchants PCI Compliance: Learning from the U.S. Air Force <![CDATA[J-PAKE: From Dining Cryptographers to Jugglers]]> http://securityratty.com/article/5711bc23c0cf0bd0754ba94dcb9b97cb http://securityratty.com/article/5711bc23c0cf0bd0754ba94dcb9b97cb Password Authenticated Key Exchange (PAKE) is one of the central topics in cryptography. It aims to address a practical security problem: how to establish secure communication between two parties solely based on their shared password without requiring a Public Key Infrastructure (PKI).

The solution to the above problem is very useful in practice — in fact, so useful that it spawns a lot “fights” over patents. Many techniques were patented, including the well-known Encrypted Key Exchange (EKE) and Simple Password Exponential Key Exchange (SPEKE). A secondary problem is technical; both the EKE and SPEKE protocols have subtle but worrying technical limitations (see the paper for details).

At the 16th Workshop on Security Protocols held in April 2008, Cambridge, UK, I presented a new solution (joint work with Peter Ryan) called Password Authenticated Key Exchange by Juggling (or J-PAKE). The essence of the protocol design inherits from the earlier work on solving the Dining Cryptographers problem; we adapted the same juggling technique to the two-party case to solve the PAKE problem. To our best knowledge, this design is significantly different from all past PAKE solutions.

Intuitively, the J-PAKE protocol works like a juggling game between two people — if we regard a public key as a “ball”. In round one, each person throws two ephemeral public keys (”balls”) to each other. In round 2, each person combines the available public keys and the password to form a new public key, and throws the new “ball” to each other.

After round 2, the two parties can securely compute a common session key, if they supplied the same passwords. Otherwise, the protocol leaks nothing more than: “the supplied passwords at two sides are not the same”. In other words, one can prove his knowledge of the password without revealing it. A Java implementation of the protocol on a MacBook Pro laptop shows that the total computation time at each side is merely 75 ms.

We hope this protocol is of usefulness to security engineers. For example, compared with SSL/TLS, J-PAKE is potentially much more resistant against phishing attacks, not to mention that it is PKI-free. Since this protocol is the result of an academic research project, we didn’t — and have no intention to — patent it. As explained in the paper, J-PAKE even has technical advantages over the patented EKE and SPEKE in terms of security, with comparable efficiency. It has been submitted as a follow-up to the future extension of IEEE P1363.2.

We believe the PAKE research is important and has strong practical relevance. This post is to facilitate discussions on this subject. The paper can be viewed here. Any comments or questions are welcome.

]]> Thu, 29 May 2008 16:31:05 +0000 pake past pake solutions pake research j-pake protocol j-pake protocol protocol design inherits security practical security J-PAKE: From Dining Cryptographers to Jugglers <![CDATA[Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008)]]> http://securityratty.com/article/52942044add67bfabfce0e3b310191f5 http://securityratty.com/article/52942044add67bfabfce0e3b310191f5 IEEE Web 2.0 Security and Privacy Workshop. I figured I'd learn a few things, and also make sure that no new exploits were announced against my employer, and/or make sure we weren't the only examples people gave of problems.

I was pretty successful on goal #1, not 100% successful on goal #2.

This post is mostly brain dump of notes about the talks followed by a few things of architectural interest that I think were discussed enough at the workshop. A quick preview - the first half of the conference was spent talking about general security holes in Web-1.0 that we still haven't solved technically/architecturally/culturally. With that in mind its hard to see how we're going to have much success with Web-2.0 security.

I'll start by saying though that I was ever so slightly disappointed with the makeup of the attendees. Conferences and workshops held by the IEEE and ACM do generally tend towards the seriously geeky and academic side of things. You're much more likely to find papers that are suitable for journals with plenty of academic references, peer review, CS technical terms, formulas, etc. At the same time though workshops do tend towards the less academic and more practical side. It was disappointing therefore that, though the workshop focused a lot of time on things like secure mashups, social networks, and Web-2.0 security models, to the best of my knowledge very few of the players in this space were present. I didn't meet anyone from any of the really interesting mashup companies and none of the social networks were there (minus google, who was well represented). Perhaps in the future people attending and organizing workshops like these can actually get the folks at the relevant companies interested, specifically invite them, etc.

Now, onto the papers/presentations themselves:

Session 1: Authentication and Authorization

Daniel Sandler and Dan S. Wallach. <input type="password"> must die!
Daniel presented some good idea on how to move password authentication into the browser chrome to improve our defenses against javascript malware such as javascript keyloggers, etc.

While the work Daniel did was quite cool in that it doesn't require any protocol modifications, to be truly useful in implementing authentication inside browser chrome you probably need involvement from the site itself to hint, tweak, etc. Once you start doing that though, you start looking at doing stuff like cardspaces to actually get to a better architectural solution.

Ben Adida. Web Authentication by Email Address

Ben focused on usability concerns in OpenID and the idea that email addresses (or things that look like email addresses) are much better identifiers than URLs. He sketched out how to modify OpenID to use email addresses or lookalikes for authentication rather than URLs. Some of his proposals hinge on using DNS lookups for a domain to find the authentication server much like we use MX records for email. While potentially risky, DNSSEC could theoretically be used to mitigate some of the problems.

I must say I haven't kept up with OpenID as much as I'd like to, and so I'm 99% sure lots of the nuance of Ben's proposal was lost on me.

Session 2: Browser Security Models and Isolation

Collin Jackson and Adam Barth. Beware of Finer-Grained Origins

Collin Jackson presented some work he and Adam have done on how the browser security model, namely the same-origin policy, isn't nearly granular enough to handle most web applications and sites that host them.

For example:

http://cs.stanford.edu/~abarth
http://cs.stanford.edu/~cjackson

both have the same origin from the browsers point of view, but don't necessarily have the same security policy per use intent. Because the web browser can't really distinguish between them, we don't have a clean way of separating the security policies here.

Collin went on to show a multitude of problems in the same origin policy between sites, and problems in the upgrade/downgrade of security indicators in a browser. I won't rehash all of his results but suffice it to say we desperately need things like ForceHTTPS embeded in browsers in the near future to prevent some of these problems.

Kapil Singh and Wenke Lee. On the Design of a Web Browser: Lessons learned from Operating Systems

Kapil presented some research his team has been doing on modeling web browsers more like operating systems. You might have seen some related work recently as part of the OP Browser project. The idea is that the internal implementation of most browsers is pretty dicey from a security perspective. There is no clean separation between policy and mechanism. All code operates at the same privilege level. Plugins cannot be constrained in what they can do, etc.

I haven't seen any analysis yet comparing what MS did with IE7 on Vista in protected mode as compared to OP or Kapil's work. It is pretty clear that MS didn't fully segment IE7, but I wonder how close they got to ideal on the sandboxing side of things.

That said, I think our biggest problem in browser security isn't the implementation and internal segmentation. Our biggest problem is that we don't have any idea what security policies we really want to implement. Sure, having a flexible architecture under the hood makes it easier to implement flexible and finer-grained policies, but unless we have some idea what those are, perhaps we're putting the cart before the horse in terms of robust internal implementation.

Mike Ter Louw, Prithvi Bisht and V.N. Venkatakrishnan. Analysis of Hypertext Markup Isolation Techniques for XSS Prevention

My favorite presentation of the day was this one by Mike Ter Louw. Mike talked all about the multiple ideas circulating out there related to content restrictions. He showed the different failure modes for several of the proposals, showed how some of them can be rescued, and pointed towards areas that need more research.

The idea of content restrictions and server-indicated security policy that clients interpret and enforce is a really hot idea right now, and I'm hoping to catch up with Mike in the not too distant future.

Mike - if you see this, drop me a note :)

Session 3: Social Computing Privacy Issues

Adrienne Felt and David Evans. Privacy Protection for Social Networking Platform

Adrienne presented some work she's done on weaknesses in the security model of social networks and paltforms such as Facebook. She analyzed a bunch of Facebook applications to understand whether they really ought to be granted all of the rights over user data that they are. She proposed some mechanisms for limiting what types of applications get access to what data by enhancing the FBML tags to allow an application to get more data without API access. She also showed how you can solve some data sharing rules with just FBML and a few permissions extensions without resorting to full API access.

What Adrienne didn't come out and say is that in some contexts things like vetting are actually important. Most people in the social networking space and Web-2.0 space don't want to look at things like vetting, legal relationships, etc. as a model for achieving security. While a preventative model looks great on paper, solving some of the data safety/privacy concerns can really only be handled through contracts, vetting, etc. No amount of hoping developers will do the right thing and develop least-privilege applications will solve this problem.

Monica Chew, Dirk Balfanz, and Ben Laurie. (Under)mining Privacy in Social Networks

Monica presented some research on how we can inadvertently leak data from social networks by a multitude of means. While it was an interesting talk on how you can aggregate data from multiple locations to pin down more details than you ought to, since I'm not a heavy user of social networks I found myself less than interested in the general problem. If you're going to post large amounts of personal data online in multiple online sources, you're going to have people aggregating them together. There is only so much we can do to protect ourselves against that sort of aggregation.

Session 4: Mashups and Privacy

D. K. Smetters. Building Secure Mashups

D.K.'s talk was quite short on technical details and yet was one of the better talks of the day. Whereas I had a few complaints about Kapil's talk earlier in the day being a solution looking for a problem, D.K.'s talk was about the problem itself - namely - how do we actually define the security policy we're trying to achieve in the mashup space, what sorts of general rules ought to govern application behavior, security properties, etc.

This was the first talk of the day to really talk about user expectations for security, what we should generally understand to be user intent, and how to actually try and implement that in a mashup application.

Tyler Close. Web-key: Mashing with Permission

Tyler's talk may have been the most entertaining of the day, if only because of his obvious frustration with what the web has become. Tyler's main claim was that we ought to be using capability URLs to handle our authentication and authorization concerns. URLs that encode both authentication and authorization data bring us back to the original intent of the web, where the link is everything.

It was nice to see someone railing against a bit of what the web has become, but it almost felt like an original internet user lamenting the end of the end-to-end internet. A decent architectural argument, and yet one that isn't likely to yield a lot of converts. I don't think I understood a few of Tyler's points about how to prevent these URLs from leaking out and/or how to revoke access should they happen to. There are a multitude of user acceptance, behavior, and expectation questions to be answered. It was a nice twist though on how to perhaps make access-controlled content more in keeping with the spirit of the web.

Mihai Christodorescu. Private Use of Untrusted Web Servers via Opportunistic Encryption

Mihai's presentation was about how to take advantage of networked services/web-applications while proividing them with only opaque data references created with cryptography. His main example was about how to use Google's Calendar product without ever sending them your real data, and sending them only client-side encrypted data instead.

While it seems like a nice idea, and while parts of his solution were technically elegant, I think again it was a solution looking for a problem. If you're so concerned about a networked service having your data that you're willing to reverse engineer the service to make it store your individual data elements encrypted, then perhaps a networked service isn't the one for you. TYhe architectural challenges in achieving what he was able to with Google's calendar are nearly impossible with a more complicated service. And, in order to make it work you have to give up many of the feature's you'd really like from a service - full text searching, etc.

I'm guessing there are a few places where's Mihai's ideas are feasible, but its hard for me to see the value prop in building what he proposed.


Some Final Thoughts:

  • We haven't come close to solving the security problems in a Web-1.0 world
  • We don't know what the security policies really ought to look like for the web, consequently we don't know what the architecture and implementation look like either.
  • Browsers are lacking fundamental architecture and policy around security.
  • Web-2.0 only makes things worse
Apart from all of the unsolved security challenges, the biggest point that struck me from the workshop was the general belief (or I assume belief, I didn't challenge people on it) that mashups are here to stay, and that we're just going to have to back into a security model for them.

I remain unconvinced that a client-side application mashup between datasets is the only way to build new and innovative applications, and that if there were any liability concerns or even contracts that held some of these companies/services even semi-accountable, perhaps we'd have a very different architecture than we're seeing as part of the mashup space.

We're spending time and money working on specs like XDR, HTML5-access-control, and we still haven't solved some of the fundamental security problems of the web. I didn't see anything at this workshop to dissuade me from that perception either.

Its like the old saying goes - "If it ain't fixed - don't break it more". Well, ok, that isn't an old saying, but maybe a few of the people working on mashups and social networks could actually operate with that as their motto we'd make some progress on all of this.]]> Tue, 27 May 2008 18:45:00 +0000 browser browser security models browser project browser security model security models browser security security web security challenges Notes from IEEE Web 2.0 Security and Privacy Workshop (W2SP2008)