Security notes / Unsorted

Security related stuff. Linux - PAM notes · SELinux Securing services Public key encryption; SSL and TLS SSH: tunnels, X forwarding · keypair logins · SSH jails · loose notes · agent Apache config and .htaccess - security A little more practical security for the everyday person not-so-formal notes Ingredients that might be useful to know - MFA / 2FA · One-Time Passwords; also, authenticators More techincal waffling Message signing notes · Hashing notes · Auth - identity and auth notes Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Pre-boot authentication

https://en.wikipedia.org/wiki/Pre-boot_authentication

JSON Web Signature, Encryption, Tokens

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

GSSAPI notes

GSSAPI is a IETF standard to make it easier for various software to do various strong auth, e.g. Kerberos.

It also allows various other auth schemes to be plugged into it.

Which also makes it potentially interesting for SSO setups within an organisation.

(not unlike SASL, which can include GSSAPI)

It's used by things like OpenSSH,

NaCl

There are two security related things called NaCl - which are completely unrelated to each other.

(There are also other things called salt, like automation software Salt (a.k.a. Saltstack)

Side note: Asymmetric v.s. symmetric keys

Simpler systems had symmetric keys, meaning that the encoding and decoding key was the same.

This allows encryption in both ways -- and that both parties have to trust each other mutually.

You have to trust neither will accidentally or purposefully leak the key, because that key means all possible abilities including

reading received encrypted data from, current or past

imitating the other side's data

That's usually fine between two parties, but sharing the same key between more than two is as weak as the weakest link. Again,

reading all parties' encrypted data from, current or past

imitating all parties involved

This is arguably the largest problem that public-private key systems target (there are other upsides):

given the public key of someone's (public,private) keypair, it is nearly impossible to calculate the private one

ideally even with any number of encrypted messages

...which is why it isn't a problem to hand the public ones out.