I am live blogging Symposium on Access Control Models and Technologies (SACMAT'26) which is being hosted by the University of Waterloo this year. The below summaries are my interpretation and should not be seen as a literal quotes from the presenters.
Contents
Speaker: Thomas Ristenpart
There are several different threat models that security researchers work on. Often we consider criminals to be a primary type of attacker. This talk talks about interpersonal tech abuse, which is a serious and poorly supported area.
Interpersonal tech abuse focuses on someone you know or is physically around you. It includes people like intimate partners, family members, co-workers, and really anyone who knows the person well and possibly has physical access.
Intimate partner violence (PV) is a huge problem and not just for women. At least once in their lives:
IPV is often a form of control. The violence is used to exert control over another person.
New York City is committed to ending gender based violence (ENDGBV) one aspect of that is to provide support to people who experience these issues.
Started with a year long interview study that involved both professional workers who work with victims of IPV and also with some IPV victims themselves.
Technology is definitely being weaponized to exert control and harass people.
Attacks usually involve multiple of these categories.
Real attacks
While the most common attacks may appear “simple” but they are actually very complex to manage or mitigate. Abuser may physically be in the home with physical access and they may not be able to leave for many reasons. Locking an abuser out may also trigger other types of abuse and make the situation worse.
Technology should be able to help
A review of the “landscape” showed that there are many types of dual use apps. These may be build for another purpose but have all the tools needed to track people.
cscw 2017, chi 2018
Brilliant plan: build a IPV spyware detection tool. Actually this a bad plan because:
To address the need better the researchers created the Clinic to End Tech Abuse.
The key reason is that our focus is on the types of threats that organizations experience and not on the inter-personal threats.
The abuser may have:
Authentication faillibility hypothesis: We will never be able to prevent some adversaries from accessing target’s account.
Papers:
Awareness is an important issue for victimes. They do not know how to find out if their accounts are compromised.
When someone else logs into your account, can you tell? A research study suggests no. Most systems do not have user-visible logs that could be used by victims to see who has historically logged in. Or even used as evidence in court.
Twitter for example does give some of that information, but the interfaces are internally inconsistent.
Ongoing access attackes are also a serious issue. Abuser may change the recovery email to the abuser’s email address. This issue is more complex because of the number of ways we can now use to login to your account. This situation means that if a victim does something like changes their password, the abuser then just uses the backup email to get access back in.
Vulnerable systems have the folloiwng properties:
Spoofing Untrustworthy data is often being presented to users as valid data. Often they take client browser information and use that to impact the logs.
We do not expect people to handle detailed legal problems or medical problems. Why do we expect them to handle detailed technical problems themselves?
Speaker: Si Zhang
Domain-based policies: imagine an IoT type situation where there are multiple smart devices. We then mat permissions inot protection domains. Then authorization rules can be specified in relation to the protection domain instead of the device.
The logs can generate huge numbers of log entries. Those logs are also not guarenteed to be accurate, we may occasionally get errors or bit flips.
The best policy is the one that is simplest and clearest in explaining the policy.
Speaker: Indrani Ray
Some online services which include file storage allow multiple types of access control to control access to those files. And those systems exist at the same time. This leads to the possibility of conflict.
We consider how actual implementations co-exist to derive schemes (authorization state-transition systems).
Looking specifically at Google Cloud Storage:
We experimented with what a user can do with various types of actions a user could do. We then tried different permission sets to see what minimum permissions are needed to do the action.
We formalize both IAM and ACL approaches that Google Cloud Storage uses. For both the experiments above were done to understand how the actual system works, not just how it theoretically works.
Not all states in Google Cloud Storage can compose.
Some unexpected permissions were found during the data collection. For example, a user can change another user’s role even though they are not the owner, which is not documented.
Speaker: Puneet Gill
Given a user permission assignment linking users to permissions directly, they then convert into a possible candidate RBAC policy.
The general idea is to derive an ordered sequence of roles. More specific roles may inheret from more general roles. Doing things this way can allow the minimizing of redundancies in permissions so that each permission is linked to a smaller number of roles.
Speaker: Sonia Chiasson
No one, other than security professionals, sit at the computer to “do security”. So security is seen as a barrier. It also takes time and effort, but is necessary to keep doing their main task.
For most users, worst case situations that security professionals care about are unlikely to happen. So after tons of work, users don’t see any impact.
In usable security: the same task must be easy for legitimate users or impossible for attackers. <- this is weird way to design user interfaces
Every new technology caues new attacks to come into existance.
Standard HCI approaches do not always work. For example it is recommended to give users feedback in HCI. But that feedback can also be used by attackers. So helpful feedback is not always possible.
Most authentication approaches treat humans more like computers. They expect humans to be able to do things like memorize long random passwords, which is not how humans work.
Users are asked to create fairly complex passwords and change them regularly. We find in research that the more complex the password requriements an organization has, the simpler the passwords get.
NIST recently released new guidance around passwords that suggest more usable options.
Recent research also shows that adoption of the new NIST guidance is lagging.
Mapping passwords to accounts is also an issue. Most users have hundreds of accounts and therefore hundreds of passwords. So this is a data and resource task.
Users central task in coping with their passwords is rationing their effort to best protect their important accounts. But users are not the best at judging which accounts are th emost important.
Most people are still very hesitent to use a password manager. The general public has been told for decades to not write their password down. So a password manager seems suspicious. It also makes people feel uncomfortable not knowing their passwordes. What if they get locked out?
Transitioning to a password manager is usability wise a bit complex. If you have old passwords then they just move the old passwords into the password manager. Now they do not get the beneifits of a password manager since the passwords are still weak.
Recent work: getting users to think about password habbits as a whole rather than individually. Created a set of visualizations based on the data in a password managers.
In theory single sign on should reduce the number of passwords people need to manage. For example “Log in with Google” or “Log in with Facebook” instead of typing in a username and password.
The issue here is privacy. The local website the user is trying to access now has some access to SSO-based data such as your name. Each SSO offers different additional information.
Empirical Analysis and Privacy Implications in OAuth-based Single Sign-On Systems
Passkeys have advantages of public key cryptography. There is no shared secret that can be leaked. All this sounds great.
Why do users not like passkeys? Public-facing materials focus on the cryptography but not the user-relevant functionality. Users are also worried about recovery, device loss, and cross-device access.
Culture has a big impact on security decisions including password sharing. People share passwords for many reasons.
One-account == one user is strongly based on Western culture and does not necessarily fit into other cultures. These other cultures are 100s of years old and are well developed and built around supporting people in a collectivness society. The problem is that the tools do not fit these societies.
Sharing isn’t a problem to be solved, it is a design criteria to be worked with.
This is also an issue in Western cultures: for example caregivers that assisst older adults. Authentication was the most common issue. Often older adults reached out to whoever was on hand because there was no clear way to help them otherwise than to share the password in person.
Authentication needs to consider the role of helpers.
What about Emergency Rooms? Also a common place that account passwords are shared. Because the main goal of these professionals is patient care and authentication takes away time from that primary goal.
Education will only go so far. Improved designs are much better.
We need to accept that sharing, delegation, and recovery are real main tasks, are all primary activities or there will be problems.
Speaker: Sushanth Ambati
Issues exist around the number of passwords and apps that lead to user frustration. Passwords may be an unsafe and frustrating to use. Industry created single-sign-on, but that does not yet solve the issue. Now there is a big target on the companies that do single sign on (Google, Facebook, etc.).
Self-sovereign (SSDI) - Users hold the keys and credentails. No central database to breach.
This is a challenge-centric systemization. jSurveyed the area and then identified six challenges, classified 47 papers by hand, and 12 deployments. Created 5 frounteers the area could aim for.
Challenges:
Of the papers
Few systems that support self-sovereign exist at all. But none address all the challenges. Being self-sovereign is more of a spectrum rather than a binary state.
Speaker: Antonis Michalas
The general idea: the voter can submit a fake visible vote and a hidden real vote. Two protocols were created with semi-honest adversary and malicious adversary.
Speaker: Tushin Mallick
A system administrator might want to know what kinds of crytopgraphy is running on their various systems, in particular, are they post-quantum or more classical. We could look in the code. But could we look at the processor instead?
The idea is to look at standard CPU logs and use the provided information to determine which crytography algorithums are running, or at least if they are post-quantum or not.
They were able to differentiate with high accuracy if post-crypto algorithums were running or classic. That was also true under conditions where the CPU was busy with other non-crypto tasks.