Difference between revisions of "Security notes / Glossary"

From Helpful
Jump to: navigation, search
m (Red Team)
m (Forward secrecy)
Line 374: Line 374:
 
==Unsorted==
 
==Unsorted==
  
===Forward secrecy===
+
===Forward and backward secrecy===
  
 
<!--
 
<!--
 +
Consider that people may record SSL sessions.
  
The idea that finding out something now cannot compromise something in the past.
+
In itself this gives them nothing but noise.  
  
 +
But if your encrypted transfers always the same secret long-term secret key,
 +
then if you find that key twenty years later, ''all'' past exchanges are now immediately readable, and all future ones too.
  
Usually in cryptography, where it mostly refers to protocols that negotiate unique keys for a session based on a key, rather than using that key directly.
+
{{comment|(And long-term secrets are ''practical'', because as we all know (and all don't do nearly enough),
 +
you should verify secrets are tied to the identities we think. But identity and MiTM aside...)}}
  
This because if someone manages to break that session key, it compromises only other messages from that
 
session, and reveals very little about past (or future) sessions, or the secret key it came from.
 
  
  
For example, when encryption negotiates a session key ''based on'' a secret key, rather than using that secret key directly, then finding the session key has no effect on past (or future) captured sessions.
+
Now consider that it most uses of encryption, parties only care about the ability to understand each other during the short-term exchange.
  
The term 'forward secrecy' basically points out that the secret key does not lose value after such an event.
+
If you could, say, agree on a unique key for each session, and forget it immediately afterwards, this gives you some extra protection.
 +
 
 +
 
 +
Finding a session's key does not give you the secret key (by merit of it not being the same thing), so does not
 +
 
 +
But more importantly, you can also build it in a way that even if you find the ''secret'' key,
 +
it does not help in finding individual session keys.
 +
 
 +
 
 +
 
 +
 
 +
 
 +
'''Forward secrecy''' means that
 +
: if a long-term secret is revealed,
 +
: then past sessions are still secure,
 +
: because you cannot discover a past session key
 +
: future ones may or may not be, we're not saying anything about that
 +
 
 +
 
 +
'''Backward secrecy'''
 +
: if a long-term secret is revealed,
 +
: then future sessions are still secure,
 +
: because you cannot discover a future session key
 +
 
 +
 
 +
Yeah, the names are not very intuitive, because both really talk about both directions in time.
 +
: Also, backwards secrecy is sometimes called "future secrecy" which... yeah.
 +
: Also, there is a difference between forward secrecy and ''perfect forward secrecy''
 +
 
 +
 
 +
 
 +
 
 +
Notes:
 +
* The two are separate because one is easier to guarantee than the other.
 +
 
 +
* This is nontrivial for multiple reasons.
 +
: you probably want to derive the session key from from the long-term secret key, it no longer ties the exchange to identities, but doing this wrong may still reveal things about the long-term secret.
 +
: also, the agreement on the session key will have to be part of the session, so it it needs to not reveal anything about the session key ''or'' the long-term secret.
 +
: This is doable, but nontrivial. You usually use some existing key exchange protocol
 +
 
 +
* use of session keys may also help reduce the probability of finding out information about the secret from the messages themselves
  
  
 
https://en.wikipedia.org/wiki/Forward_secrecy
 
https://en.wikipedia.org/wiki/Forward_secrecy
 +
 +
 +
 +
For example,
 +
: [[TLS]] achieves forward secrecy with (ephemeral) [https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Diffie-Hellman key exchange].
 +
: [[Signal]] uses [https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm Double Ratchet] which (under some conditions) also does backward secrecy
 +
 +
 +
  
  

Revision as of 15:37, 10 May 2022

Security related stuff.

Practical


Theory / unsorted



how to do a login system badly
how to do encryption badly
Disk and file encryption notes


Attacks

Access control

Least privilege (principle)

The principle of least privilege means each actor in a system should be able to access no more than it needs.


For example, you can say

your web server should be denied to real all of the filesystem, except its own documents
your backup program should
be able to read most everything, but...
not be able to run anything (beyond its own components)
not be able to write anything except to the backup disk and its own logs


This is part of why functional accounts are often created for each such part: It's easier to handle this in broad terms even in simpler DAC setups, with just filesystem permissions.

When you want to crack down on this more thoroughly and more visibly, look at things like SELinux (because it adds MAC).


Note that the isolation in VMs and OS containers, are implicitly least-privilege as well: no connection to the outside unless permitted.


See also:



Discretionary Access Control (model)

Discretionary access control (DAC) means access to an object is at the discretion of the object's owner.


...more precisely, the identity of subjects. Usually that's owner-based, though e.g. capability systems often allow transfer to other parts.

Mainly contrasted with MAC

Examples:

permissions in most filesystems


Mandatory Access Control (model)

Mandatory access control (MAC) means that the system that decides to allow access between objects, instead of the object owners (though some systems apply MAC on top of DAC)


Often means labeling objects with particular categories, and having rules based on these categories.

Such (often-broad) labeling is often done for practical reasons: it often makes the rules simpler, which makes it more clear they express what you intended.


MAC usually means design up front, and reconsidering that full design on each change.

This is also why it often assists DAC, because

  • while MAC is good at partitioning off parts of a system in broad terms (e.g. web server may only read under /var/www regardless of permissions),
MAC it is less flexible at anything you can't describe fully at the design stage (like people sharing specific files securely).
  • while you can sort of implement DAC with MAC, this is often so messy
to the point that it may be harder to verify as being correct


Role-Based Access Control

Role-based access control (RBAC) is focused on roles and role hierarchy, subjects and sessions.

It's a moderately detailed abstraction, considered a thing of its own, and a common reference for this sort of thing because these concepts cover a lot of typical needs of larger organisations


This makes it (possibly mainly the role part) a potential piece of of DAC, MAC and others.


https://en.wikipedia.org/wiki/Role-based_access_control


Attribute-based access control

Related notes

If you squint, there is sometimes very little difference between a category that a MAC system works on and a group that a DAC works on.

That is, very similar to users

The difference lies largely in who may change them - the admin, or the relevant user.

This is also roughly why there is value in mixing them. E.g. stricly separate web server, database, and other in terms of many resources. And have users as a third general pile, they can figure out among themselves and mostly just care about filesystem DAC anyway.

Hacking terminology

Passive recon

Attack vector

Attack surface, Attack factor

Attack tree

Red Team

Unsorted

Forward and backward secrecy

Man in the middle

Two generals problem

The bitter ex test

Phishing

Worm, virus, trojan, etc.

Performative security, LARP security, cargo cult security

End to end encryption

Zero knowledge