Security Cryptography Whatever

> Isn't a Ubuntu server secure out of the box?

I think people working at RedHat are more competent in moving security forward on Linux than what Ubuntu does. Ubuntu hardly innovates at all. Its target market seems to be desktop users (or server admins that are only familiar with the Desktop version). Personally I wouldn't put Ubuntu (or any other distribution) on a server without an elaborate playbook to tailor it to my needs (on Ubuntu that playbook is always more complex from my experience). This is where Ubuntu fails for me because it makes some weird assumptions as to what I want in terms of security (which are absent in Debian). YMMV.

Although I think that a distribution's goal should be accessibility and configurability - in that regard all of them don't prioritize security features as much as I'd like to see (but knowing myself I probably would complain the second these features become too opinionated - which they most certainly would - which is why I think Debian does the right thing with not making opinionated assumptions).

Ubuntu compared to Debian standard install is more bloated, interim releases are much buggier, and Ubuntu LTS is less stable than Debian stable. Ubuntu's root certificate store is constantly outdated (though the same issue might also be on Debian). Their apparmor configuration lags behind, ... whatever is good they usually inherit from Debian.

All distributions could do more to lock down processes with seccomp-filters in systemd. Would be interesting to see what lynis⁰ discovers when comparing a fresh server install between Ubuntu and others. In over 20 years I have seen some real shit-shows in production with all distributions except Debian (again ymmv).

Jason Donenfeld, the creator of Wireguard said about Ubuntu on the latest¹ SCW podcast:

> Ubuntu is always, a horrible distribution to work with, ...

> Well, they [Ubuntu] sort of inherit from Debian, but they're like not super tuned in to what's going on and like not really on top of things. And so it was just always, it's still a pain to like make sure Ubuntu is working well. but I don't know, it's not too much interesting to say about the distro story, just open source politics as usual.

while somewhat anecdotal I trust that Jason knows what he is talking about having been on the linux security kernel team for ages and familiar with the quirks of various downstream vendors. His development cycle for WG is: implement -> decompile -> formal-verification -> rinse/repeat :-/

All of Linux security is a shit show. This is why grsecurity is charging money for it's service.

⁰ https://cisofy.com/lynis/

¹ https://securitycryptographywhatever.buzzsprout.com/1822302/...

There is no description of the protocol or of its security goals, so I am making some guesses based on a cursory look at the source and what I imagine this might be for.

A single symmetric key is derived for both directions, and there is no checking of nonces, so as far as I can tell any message can be dropped, reordered, or replayed in both directions. (Including replaying message from A to B as if they were from B to A.) This is a bit like using ECB and likely to lead to fun application-specific attacks like [0].

This is very much rolling your own crypto, in a dangerous way. I am on the record as being "against" the "don't roll your own crypto" refrain [1], but mostly because it doesn't work: it should discourage people from publishing hand-rolled protocols such as this, but instead people think it means "don't roll your own primitives" and accept any use of "Ed25519/X25519" as probably secure.

Please read about the Noise framework [2] to get an idea of how much nuance there is to this, and consider using a Go implementation of it [3] instead.

P.S. This kind of issue is also why I maintain that NaCl is not a high-level scheme [4]: this could have used NaCl and have the exact same issues. libsodium has a couple slightly higher-level APIs that could have helped, secretstream [5] and kx [6], but again please use Noise.

[0] https://cryptopals.com/sets/2/challenges/13

[1] https://securitycryptographywhatever.buzzsprout.com/1822302/...

[2] https://noiseprotocol.org/noise.html

[3] https://github.com/flynn/noise

[4] https://words.filippo.io/dispatches/nacl-api/

[5] https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...

[6] https://libsodium.gitbook.io/doc/key_exchange

Passkeys is the "normal" name for a FIDO2/WebAuthn credential that basically lives within a phone or password manager. It does add a few things. Namely the ability to store many passkeys per device per app/site, the ability to sync those passkeys (e.g. via iCloud or similar), and the ability to use QR codes and Bluetooth to do a local-only authentication on a device which doesn't have the passkey (which is what often requires some proprietary implementation).

[Edit]: An important feature of "Passkeys" is that browsers and operating systems have a special API that allows an app to pre-start a sign in with a known user/email/etc. which if there is a passkey for that user it'll automatically start the FaceID or similar confirmation process. Which Passkeys are checked is controlled by the OS/Password Manager which checks which website is asking and what username it's checking. This is just to make it so it seamlessly logs you in. It does a fall-back to just asking what your user is which is the initial workflow.

This[0] is a good podcast to listen to with Adam Langley from Google about how Chrome supports Passkeys and why they're a good thing. It includes the details of how/where/why there are some proprietary bits needed to implement "Passkeys".

[0]: https://securitycryptographywhatever.buzzsprout.com/1822302/...

FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-t...

Chromium Blog on Passkey support (Dec 8, 22) https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...

i listen to a few cryptography podcasts and cryptography is an interest of mine[1]. most security engineers agree that JWT has too much of a surface area and takes a lot of care from the implementer that it can lead to security holes[2].

Another reason i like just generating a securiity token when the user logs in is that i can require a join on the table for any query so that its extra secure.

e.g. if fetching "posts" for a "user" and i have 3 tables (users, posts, and user_tokens) i can do an inner join like this (if the `posts` table has `user_id`):

  select p.*
  from posts p
  inner join user_tokens ut using (user_id)
  where p.user_id = $1 and ut.token = $2
    
  -- `users` table wasn't needed for this join since am not selecting from it

with JWTs the security happens once when you verify the JWT signature, but then security is less of a focus when making queries, which would complicate queries anyway since you have to make sure the same user who owns the JWT has access to the data (it handles authentication but not authorization). You still need to hit the database anyway for fetching any data so the headless approach for JWTs isn't really saving me much, so I like to just bake in security for the queries.

[1]: I recommend new book "Real World Cryptography" by David Wong

[2]: (podcast about JWTs from cryptographer, august 2021) https://securitycryptographywhatever.buzzsprout.com/1822302/...

--

EDIT: would probably want a few more predicates in that query to account for token status.

e.g.

  where p.user_id = $1 and ut.token = $2
  and ut.is_revoked = false and ut.is_expired = false

WebAuthn does not mandate any kind of form factor[1], external tokens use CTAP for USB/Bluetooth/NFC, Apple FaceID/TouchID and Windows Hello using proprietary interfaces with the built-in hardware. Blink-based browsers ships with a virtual authenticator for debugging[2] and there are a few more[3].

Apple and Google already announced cloud syncing earlier this year, using "passkey" as a friendlier term for end-users. QR codes already allow for cross-ecosystem non-synced use cases, like using my personal Android phone to log in an account with my work Macbook. https://securitycryptographywhatever.buzzsprout.com/1822302/... is a good listen to catch up on the latest developments.

[1]: https://www.w3.org/TR/webauthn-2/#authenticator-model [2]: https://developer.chrome.com/docs/devtools/webauthn/ [3]: https://github.com/herrjemand/awesome-webauthn#software-auth...

> I wonder when I can just get a virtual yubikey built into my phone. No extra device. My phone is my device.

Last year, Apple shipped the first version of this: you can enroll your phone (or TouchID-equipped Mac) on sites like GitHub.com and it’ll use the Secure Enclave for WebAuthn secrets. I’ve been doing this since 15.4 came out and it’s great. Prior to that, I used a Yubikey 5 with USB and NFC, which is still handy since that’s where I store TOTP seeds for less secure sites.

Passkeys extend that idea further by allowing you to register once and have it synced rather than having to register every device on every site[1].

That last part is important because AWS has a huge barrier: the number of MFA devices you get is one, which means you either need insecure things like synced TOTP seeds or you have to be comfortable never losing your Yubikey. I have been asking our TAM to prioritize fixing that for years so backups can be a real thing.

1. Over simplified a little - hear Adam Langley at https://securitycryptographywhatever.buzzsprout.com/1822302/... for the right version