Security usability: Difference between revisions

From JookWiki
(Rework)
Line 25: Line 25:
Together all three of these are used to make security software usable.
Together all three of these are used to make security software usable.


==Case study: Key verification==
==Case study: Keys==
Here's a quick list of the best examples of modern security I can think of:  
Here's a quick list of the best examples of modern security I can think of:  


Line 34: Line 34:
All of these rely on keys which dumps a few tasks on people using the software.
All of these rely on keys which dumps a few tasks on people using the software.


The first is verifying keys. There are a few ways to do this:
The first task is verifying keys. There are a few ways to do this:


*Skip verifying the key
*Skip verifying the key
Line 44: Line 44:
If I had to guess which method is the most common, it's skipping verification. This is the option I pick all the time now for two simple reasons: It's easy, and it's reliable.
If I had to guess which method is the most common, it's skipping verification. This is the option I pick all the time now for two simple reasons: It's easy, and it's reliable.


- managing keys
The second task is backing up keys. People have to:


- key compromise  
* Create a secure storage location
* Copy the keys to the location
* Backup the secure storage location as well
 
Unless keys are used for something very important like signing packages or cryptocurrencies, people don't put much effort in to this step. In the case where they do take steps to back things up they have to have enough knowledge to do it securely and create redundant backups. Doing this step wrong (such as by backing up a key to cloud storage) can result in compromised keys.
 
The third step is to manage revoking and rotating keys. People have to:
 
* Replace keys regularly in case of unknown compromise
* Revoke keys in case of known compromise
 
As far as I know almost no security software supports doing these tasks in the first place. That means if someone steals your key they can impersonate or access some resource you have for an unlimited amount of time. The only way around this is to inform people through social networks and other insecure communication methods that your old key is compromised and you have a new one, and go through the steps of verifying and backing up the keys again. Yikes.
 
==Case study: F-Droid and Google Play==


==Trust==
==Trust==
Line 54: Line 67:


not how reality works
not how reality works
==F-Droid vs Google Play==

Revision as of 06:33, 3 March 2022

This is a WIP page, come back later.

This is a quick page on my feelings towards security and how most security software fails to be usable.

Background

Recently I read the article F-Droid: how is it weakening the Android security model? which provides a critique of F-Droid's security model and recommends people use Google Play Store.

The GrapheneOS developers provided similar critique but it contains numerous uncorrected errors. Instead of correcting this information they have chosen to threaten SylvieLorxu with legal action for pointing out these mistakes. I strongly recommend reconsidering any trust towards GrapheneOS and its developers given their priorities shown here.

Usability

Security software almost always asks people to do some of the following:

  • Verify authenticity of some data
  • Remember sensitive data
  • Store sensitive data securely

Unfortunately people are imperfect and fail to do these, not for the lack of trying.

Security developers take three approaches to deal with this:

  • Train people to make fewer mistakes
  • Design software to catch mistakes
  • Lessen the impact of mistakes

Together all three of these are used to make security software usable.

Case study: Keys

Here's a quick list of the best examples of modern security I can think of:

  • OpenSSH
  • Tor and its hidden services
  • Matrix

All of these rely on keys which dumps a few tasks on people using the software.

The first task is verifying keys. There are a few ways to do this:

  • Skip verifying the key
  • Send the key using another communication service or method
  • Ask for the key from someone you trust
  • Meet the person in real life and exchange the key directly
  • Verifying the key incorrectly

If I had to guess which method is the most common, it's skipping verification. This is the option I pick all the time now for two simple reasons: It's easy, and it's reliable.

The second task is backing up keys. People have to:

  • Create a secure storage location
  • Copy the keys to the location
  • Backup the secure storage location as well

Unless keys are used for something very important like signing packages or cryptocurrencies, people don't put much effort in to this step. In the case where they do take steps to back things up they have to have enough knowledge to do it securely and create redundant backups. Doing this step wrong (such as by backing up a key to cloud storage) can result in compromised keys.

The third step is to manage revoking and rotating keys. People have to:

  • Replace keys regularly in case of unknown compromise
  • Revoke keys in case of known compromise

As far as I know almost no security software supports doing these tasks in the first place. That means if someone steals your key they can impersonate or access some resource you have for an unlimited amount of time. The only way around this is to inform people through social networks and other insecure communication methods that your old key is compromised and you have a new one, and go through the steps of verifying and backing up the keys again. Yikes.

Case study: F-Droid and Google Play

Trust

security is a software problem to a social issue

libertarian threat model

not how reality works