Trusted CI Webinar: JSON Web Tokens for Science: Hands on Jupyter Notebook tutorial, Monday August 26th @10am Central

SciAuth's Jim Basney and Derek Weitzel are presenting the talk, JSON Web Tokens for Science: Hands on Jupyter Notebook tutorial, on August 26th at 10am, Central time.

Please register here.

NSF cyberinfrastructure is undergoing a security transformation: a migration from X.509 user certificates to IETF-standard JSON Web Tokens (JWTs). This migration has facilitated a re-thinking of authentication and authorization among cyberinfrastructure providers: enabling federated authentication as a core capability, improving support for attribute, role, and capability-based authorization, and reducing reliance on prior identity-based authorization methods that created security and usability problems. In this webinar, members of the SciAuth project (https://sciauth.org/ - NSF award #2114989) will provide a short, hands-on tutorial for cyberinfrastructure professionals to learn about JWTs, including SciTokens (https://scitokens.org/ - NSF award #1738962). Participants will use Jupyter Notebooks to validate the security of JWTs and experiment with JWT-based authentication and authorization. Participants will gain an understanding of JWT basics suitable for understanding their security and troubleshooting any problems with their use.

Speaker Bios: 

Dr. Jim Basney is a principal research scientist in the cybersecurity group at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. He is the Director and PI of Trusted CI. Jim received his PhD in computer sciences from the University of Wisconsin-Madison.

Dr. Derek Weitzel is a research assistant professor in the School of Computing at the University of Nebraska - Lincoln. He has been providing distributed computing solutions to the national cyberinfrastructures since 2009. He is a member of the OSG’s production operations team and leads the operations of the National Research Platform. His current areas of research involve distributed data management for shared and opportunistic storage, secure credential management, and network monitoring and analytics.

---

Join Trusted CI's announcements mailing list for information about upcoming events. To submit topics or requests to present, see our call for presentations. Archived presentations are available on our site under "Past Events."

The extra Zoom setting you may not know about to control access for phone-in attendees

What if I told you, that your Zoom meeting password does not apply to users calling in by phone?

Over the past several weeks the rest of the world has found out about the Zoom video conferencing system.  In this time of crisis, it has become essential for work, school, and even play. However, people have also been finding out about the security and privacy issues related to Zoom. I'm now going to share one more with you.

Trusted CI staff have discovered that, by default, meetings that have been protected with a meeting password do not require the password for users calling in by phone. There is an extra setting to control by-phone access and we think that this extra setting may not be not known by many Zoom users. Users who call in using one of the Zoom gateway phone numbers will not normally be prompted for a password. This potentially leaves sensitive meetings vulnerable to eavesdropping. Although this issue isn't a vulnerability in Zoom, it allows the users setting up meetings to create a vulnerability in their own meetings. It is a user interface and security awareness issue.

In order to enable password protection for by-phone users, you must locate the setting "Require password for participants joining by phone" as shown below, which in some interfaces may be located in the advanced settings.

Screenshot of the extra "by phone" setting to consider to protect a meeting

A second closely related issue is that enabling this "Require password for participants by phone" setting does not immediately change the configuration of existing meetings that have already been set up. The owner of the meetings must go into each meeting configuration, edit the meeting, and then save it without making any changes to the meeting. According to our observations, this regenerates the meeting and applies a phone password to the meeting. The phone password will be automatically generated and become part of the meeting invitation. You would then share this new password and meeting invite with your meeting participants who need it.

Trusted CI's test of faking a number

A third issue to be aware of here is that phone number caller id information can be faked. Although this is not new by any means, there has been little to no warning about this in relation to using Zoom. This vulnerability isn't Zoom's fault as the flaw exists in the design of the phone system.

However, because of this, you should not use a phone number in the participants list to authenticate a participant. A malicious user could change their number to that of an authorized user to avoid detection.

During our research into these issues, we found that most of the existing documentation outside of the Zoom website itself does not mention the "Require a phone password" extra setting that must be applied. Similarly, it is not obvious that this must be done when creating a meeting and setting a password, as there is no feedback from the interface that this must be done or that your meeting will not be fully protected.

The Zoom meeting password interface, showing no indicators of an extra by-phone setting.

Several of our security colleagues were also unaware of this extra "Require a password for by-phone users" setting, suggesting that the setting is unknown to most Zoom users.

Our recommendations for Zoom, the company,  is to add some type of indication near the meeting password setting that informs users that there is an additional setting for controlling access by phone and that Zoom should inform their existing install base about these issues.  Alternatively, this option should be enabled by default.

How Trusted CI discovered the issues

On February 26th, 2020, Mark Krenz set up a meeting with a colleague on the COSMIC2 science gateway project and set a meeting password to try to protect the meeting. When the colleague called in by phone, Mark asked the user if they needed a password to get in, which to his surprise, they did not. Mark then performed further testing of the issue with the help of Trusted CI members including Andrew Adams, Shane Filus, Ishan Abhinit, and Scott Russell. It was quickly found that changing the "require password by-phone" setting did not set it on existing meetings and that the existing meetings needed to be edited and re-saved. The team above wrote up a security report to send to Zoom, which was done so on March 6th through the hackerone.com website, which acts as a gateway for submitting such reports to companies. This meant that there was then a 30 day embargo on releasing this information to the public. During this time, the COVID19 crisis began to unfold in the western countries and people started heavily using Zoom. This almost immediately led to many reports of various unwanted incidents within Zoom meetings, so called Zoombombing,  and other vulnerabilities being discovered and announced. During this time we discussed the issue internally, met with Zoom to discuss the issue, and provided our recommendations for a way forward. We also monitored the media for any signs that this was being exploited, but found no direct evidence that it was being exploited. We also looked for these recommendations in news reports that were surfacing over the past month and found none that directly mentioned this issue.

Related links:

• https://zoom.us/security
• https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/
• https://blog.zoom.us/wordpress/2020/03/27/best-practices-for-securing-your-virtual-classroom/
• https://www.nbcboston.com/news/local/fbi-warns-of-zoom-bombing-after-2-mass-schools-have-web-conferences-hijacked/2099692/
• https://www.forbes.com/sites/anthonykarcz/2020/03/29/do-these-4-things-to-keep-hackers-out-of-your-zoom-call/#149f3040486e
• https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/

CCoE Webinar August 28th 11am ET: Stronger Security for Password Authentication

UC Irvine's Stanislaw Jarecki is presenting the talk "Stronger Security for Password Authentication," on August 28th at 11am (Eastern).

Please register here. Be sure to check spam/junk folder for registration confirmation with attached calendar file.

Passwords are an infamous bottleneck of information security: The users choose them badly and then forget them, and the servers store (at best!) a table of password hashes which, in the all-too-common event that the server is hacked, allows the attacker to recover a large fraction of the passwords using the so-called Offline Dictionary Attack. At the same time, we seem to be stuck with passwords because they form the most user-friendly authentication mechanism we know. Our work in the CICI-sponsored project looks at the security vulnerabilities of current password authentication protocols, including Two-Factor authentication protocols, where the user's password is amended by the presence of an Auxiliary Authentication Device, e.g. a cell-phone capable of displaying a short one-time PIN which the user copies onto her terminal in order to authenticate to the server. We show that with modest changes to the authentication infrastructure, involving either the user's client, or the authentication server, or the Auxiliary Device software, we can make password authentication protocols which are as practical as currently used schemes but have much stroger security properties. Most importantly, the schemes we show eliminate the security vulnerability posed by the server storing password hashes, thus eliminating the possibility of the Offline Dictionary Attack in case of server compromise. In other properties, our schemes offer resistance to so-called phishing attacks and, more generally, failures in the Public Key Infrastructure, where the user misidentifies the public key of the authentication server and, which in current password authentication schemes leads to revealing the user's password to the adversary.

In this presentation we will present an overview of our work on strengthening password and two-factor schemes, published in NDSS'14, Asiacrypt'14, EuroSP'16, AsiaCCS'16, ACNS'17, ICDCS'17, as well as future directions.

More information about this presentation is on the event page.

Presentations are recorded and include time for questions with the audience.

Join CTSC's discuss mailing list for information about upcoming events. To submit topics or requests to present, see our call for presentations. Archived presentations are available on our site under "Past Events."

AARC and CTSC Collaborate on Interfederation

CTSC is starting a collaboration with the European Authentication and Authorisation for Research and Collaboration (AARC) project on use of federated identities for international science. AARC is a two year project that started May 2015. Jim Basney from CTSC joined the June 3-4 AARC kick-off meeting to begin the collaboration.

As the infrastructures for international scientific collaborations migrate from X.509 to SAML for identity management, there is a strong need for interoperability across national SAML federation boundaries. In 2014, the US InCommon federation joined eduGAIN, which connects SAML federations around the world, and now InCommon is engaging with science projects on international interfederation pilots. At the same time, the AARC project in Europe is addressing international adoption of SAML federations by research projects. This represents an opportunity to achieve critical mass around EU-US interfederation activities for science, with CTSC providing needed coordination on the US side.

Specific goals for the CTSC-AARC collaboration include:

1. Training: Develop and disseminate training materials to enable science projects to implement federated access.
2. Pilots: Facilitate US participation in interfederation pilot projects.
3. Incident Response: Establish an operational framework for security and incident response in R&E federations via the SIRTFI working group.
4. Levels of Assurance: Map requirements of cyberinfrastructure providers to an assurance framework that can be implemented in a cost-effective manner by identity federations. 

CTSC will gather input from US cyberinfrastructure (CI) projects for AARC activities, disseminate training and other AARC project outputs to US CI projects, and facilitate EU-US pilot projects.

To participate in the discussion, please join the CTSC Federated Identity Discussion List.

Analyzing authentication events

Part of CTSC's mission is to help educate the NSF community about tools and processes related to cybersecurity. For example, our software assurance team offers tutorials on static analysis tools and to test those tools, they provide benchmark datasets (code). In this article, we describe tools (Python modules) and a benchmark dataset for analyzing authentication data. However, the tools are sufficiently general that they could apply to other types of data related to cybersecurity, e.g. network traffic or more general data flows.

I recently had the pleasure of attending the SIAM Workshop on Network Science where I presented our poster on the analysis of a rather large authentication¹ dataset. The public dataset was made available from Los Alamos National Laboratory (LANL) and represented over 700 million anonymized authentication events over a nine-month period.[1][2]

Our poster submission demonstrated the use of Python to analyze and visualize the data. Since our scripts relied on various Python modules not found in the standard library, we recommended using the Anaconda Python distribution (3.x) which contained those modules (and a lot more). One key module that we used, to perform some of the network analysis, was NetworkX. Another module, to plot results, was matplotlib. We also demonstrated how one could use the IPython Notebook in a browser.

An authentication event was represented as a simple entry: "time,user,computer", where "time" was in seconds offset from the beginning, and "user, computer" were anonymized entries with unique numeric identifiers (e.g. U214,C148). We preprocessed the dataset to generate two files: one containing just the time values, another representing the user-computer information as a global, static graph. This type of graph, with two disjoint sets of nodes (users and computers), is known as a bipartite graph. Since the second file, containing the graph, took about 8 hours to generate, we made it publicly available in case others wanted to experiment. (Generating the first file, with only time values, just took a few minutes using one of our scripts.)

Our first step was to perform a sanity check on the time values for the authentication events. Fig. 1 is a histogram plot of all events over the nine-month period. Using the matplotlib module, we can interactively select a region to zoom into and see general daily and weekly usage patterns. The script to generate this histogram is parameterized so that a user can see more detailed (or coarse) plots.

Fig. 1: A histogram, over time, of all authentication events (top); zooming into a 2 week window (bottom)

Next, we use the NetworkX module to plot the graph and zoom in on particular nodes that seem to be hubs in the network. In the following two figures, the User nodes are colored red and Computer nodes are colored white. Fig. 2 shows C148 as a hub with numerous User nodes connected to it. Fig. 3, in contrast, shows U12 connecting to numerous computers. Obviously, if we had more information about the authentication events, we might be able to determine that certain User hubs were, for example, just the result of system administrators performing maintenance. On the other hand, it may be an indication of questionable user behavior.

Fig. 2: Node C148 as a hub.

Fig. 3: Node U12 as a hub.

In addition to visually inspecting the graph, we can programmatically analyze it to discover certain features, e.g., hubs or connected components. These techniques can be found in our poster and scripts.

Discussing results with LANL's Hagberg (left)

According to LANL's Aric Hagberg, there will likely be another dataset coming sometime this year that will have more metadata.

Our abstract, poster, Python scripts, and additional documentation can be found at https://github.com/rheiland/authpy.

We welcome your comments.

^{1. Authentication, in this context, is the process of verifying the identity of a person connecting to, e.g. logging into, a computer.}

---

[1] A. Hagberg, A. Kent, N. Lemons, and J. Neil. Credential hopping in authentication graphs. In 2014 International Conference on Signal-Image Technology Internet-Based Systems (SITIS). IEEE Computer Society, Nov. 2014.

[2] A. D. Kent, L. M. Liebrock, and J. C. Neil. Authentication graphs: Analyzing user behavior within an enterprise network. Computers & Security, 48:150-166, 2015.

CTSC DataONE engagement: identity management system review

In the CTSC-DataONE engagement, CTSC and DataONE staff worked together to perform an architectural review of DataONE's identity management system. DataONE (Data Observation Network for Earth) is "a distributed framework and sustainable cyberinfrastructure that meets the needs of science and society for open, persistent, robust, and secure access to well-described and easily discovered Earth observational data."

CTSC's overall assessment of the DataONE identity management system was positive. Strengths include support for authentication using federated identities, equivalence mapping of multiple identities for the same person, and a well-specified access policy language. CTSC made recommendations for improvements in the areas of system documentation, architecture, and operations. See the report at http://hdl.handle.net/2022/16926 for more details.

CTSC's engagements are inherently collaborative. Many thanks to the DataONE team, and specifically Ben Leinfelder, Bruce Wilson, and Dave Vieglais for the collaborative effort that made this engagement possible.

For more about how CTSC helps NSF projects visit http://trustedci.org/howwehelp.