If the database is not local, and there’s no authentication, what stops someone else from accessing it inappropriately?
43 karma · joined July 3, 2020
This is highly misleading. It's true that there's a handful of global AWS services - but only their control planes operate from a single region (e.g. us-east-1). Their data planes are regionally isolated or globally distributed.[1]
The only time you'd normally use a service control plane is to deploy changes, e.g. when you create, read, update or delete service resources or update configuration during a change window.
Workloads should be designed for "static stability", as recommended by AWS.[2] A statically stable workload only depends upon the data planes of the services it uses at runtime. Statically stable workloads are designed to continue operating as normal even if there's a service event impairing one or more control planes (including for global services).
> During us-east-1 outages it's sometimes possible to continue using existing auth tokens or sessions in other regions, while not possible to grant new ones.
This is just plain wrong! The IAM Security Token Service (STS), which grants IAM tokens, is a data plane-only service and runs independently in each region [3]. The IAM data plane, which enforces access control, is also regional.
If the IAM control plane is impaired, you might not be able to create new IAM roles (a control plane operation) - but you can continue generating and using temporary credentials for existing IAM roles (data plane operations) within the region your workload is running in. This allows statically stable workloads to continue using IAM without interruption.
[1] https://docs.aws.amazon.com/whitepapers/latest/aws-fault-iso...
"Global AWS services still follow the conventional AWS design pattern of separating the control plane and data plane in order to achieve static stability. The significant difference for most global services is that their control plane is hosted in a single AWS Region, while their data plane is globally distributed."
[2] https://docs.aws.amazon.com/whitepapers/latest/aws-fault-iso...
"...eliminating dependencies on control planes (the APIs that implement changes to resources) in your recovery path helps produce more resilient workloads."
[3] https://docs.aws.amazon.com/whitepapers/latest/aws-fault-iso...
"STS is a data plane-only service that is separate from IAM, and does not depend on the IAM control plane."
I thought you were paraphrasing John 1:1 for a moment! [1]
Are you saying other sequencers are unable to render the same data as piano roll and score?
Let me rephrase: for the majority of users, the usability and resilience benefits of synced credentials are enormous, and the security costs are marginal at best. But this rests on a number of assumptions. YMMV.
I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.
Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)
By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.
Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.
> How do the decryption keys for the encrypted passkeys get shared between devices?
They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).
In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.
The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).
That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.
For machines you don't control, such as your employer Mac, well that's a special case. In theory you can use "FIDO Cross-Device Authentication", which is a passkey flow designed specifically for authenticating on one device using a passkey stored on a different device, and involves scanning a QR code.
I've never tried this though. Personally I tend to avoid mixing personal stuff with work stuff, so the problem rarely arises.
If an "online" password manager uses end-to-end encryption, then the credentials really are only on your computers. The only thing "in the cloud" is encrypted blobs of data being moved around for the purpose of device sync and backup.
This insistence on using local non-syncing password managers is a masochistic exercise in making life difficult for yourself with no security benefit.
Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.
Or are you saying the credential exchange process itself could block providers?
Apple's native passkey implementation doesn't require doesn't require you to install extra software, and the passkeys sync by default. I thought Google's and Microsoft's were similar - but I haven't tried them.
> And even if you do, it’s discouraged
Really? Where is it discouraged? I thought synced passkeys are intended as the solution for consumers.
> the spec is allowed to deny you access
Yeah but I thought that's for enterprise use cases, not consumer. E.g. employers that want to enforce device type restrictions on their employees.
This is not true - browsers including Safari support passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain.
> you're always locked in to one passkey vendor or another.
This will change: https://1password.com/blog/fido-alliance-import-export-passk...
If someone passes away, their family members can use the Emergency Kit to gain access to and use all their credentials - including their passkeys.
(The Emergency Kit also allows you to recover your data in the event that you forget your master passphrase or lose all your devices.)
The default, built-for-the-masses implementation of passkeys is called "synced passkeys". They are designed to sync between all your enrolled devices, ideally using end-to-end encryption.
You authenticate with whatever device you happen to be using at the time - phone, tablet, laptop, desktop - doesn't matter. If you lose one, you replace that device and re-enroll - then all your passkeys magically re-appear on the new device.
If you're cross-platform, modern password managers work across ecosystems - for example, 1Password syncs passkeys between Mac, Windows, iOS, Android, and Linux. If you're all-in on Apple, their native passkey implementation syncs passkeys between all your Apple devices. I thought Google and Microsoft do something similar now.
It's a real mystery why people believe passkeys have to be stored on your phone only.
It wouldn't need to be intelligent to do this; it could be a self-replicating machine with no intelligence at all - which is orders of magnitude simpler and therefore more likely.
Chaotic initial state -> self-replicating machine -> intelligence is much more likely than chaotic initial state -> intelligence.
(See my other reply to the GP comment about The Recursive Universe, where all this is discussed.)
One of the chapters asks "what is life?". It considers (and rejects) various options, and finally settles upon a definition based on Von Neumann-style self-replicating machines using blueprints and universal constructors, and explains why this is the most (only?) meaningful definition of life.
Later, it talks about how one would go about creating such a machine in Conway's Game of Life. When the book was written in 1984, no one had actually created one (they need to be very large, and computers weren't really powerful enough then). But in 2010 Andrew J. Wade created Gemini, the first successful self-replicating machine in GoL, which I believe meets the criteria - and hence is "alive" according to that definition (but only in the sense that, say, a simple bacteria is alive). And I think it works somewhat like how it was sketched out in the book.
Another chapter estimated how big (and how densely populated) a randomly-initialized hypothetical GoL universe would need to be in order for "life" (as defined earlier) to appear by chance. I don't recall the details - but the answer was mind-boggling big, and also very sparsely populated.
All that only gives you life though, not intelligence. But life (by this definition) has the potential to evolve through a process of natural selection to achieve higher levels of complexity and eventually intelligence, at least in theory.
That's totally different to deploying new "code", i.e. new versions of the agent itself. You'd expect that to be treated as a software update like any other, so their customers can control the roll out as part of their own change management processes, with separate environments, extensive testing, staggered deployments, etc.
I wonder if such a content vs. code distinction exists? Or has EDR software gotten so complex (e.g. with malware sandboxing) that such a distinction can't easily be made any more?
In any case, vendors shouldn't be able to push out software updates that circumvent everyone's change management processes! Looking forward to the postmortem.
Here "permission" is defined as an "Operation/Object pair" - for example, read/write/execute access to a particular file. But crucially, there's no user involved (yet). That's where authorization comes in. When a permission becomes associated with a user (in this case via roles), you have authorization.
This sense of the word "permission" has now become very well established in the field of identity and access control.
Permissions are rights or privileges, which exist independently of their assignment to particular users.
Authorization, on the other hand, can have two meanings - both of which relate to _assignment_ of permissions to users (preferably via groups or roles):
1. The process of assigning permissions to users, as in "you need to be authorized to do that".
2. The process of confirming whether a user has the necessary permissions to perform some action.
The second meaning can also be referred to as access control (or more precisely, runtime access control). It's what applications typically do after authenticating users. Hence, if you want an alternative to "authorization" in the runtime verification sense, the term "access control" might be appropriate.
On the other hand authN and authZ are perfectly adequate and well-understood.
Since the term "authorization" always relates to a (direct or indirect) binding between permissions and users, it makes no sense to use the term "permissions" as a substitute for "authorization".
Everything you said about sample rate applies more to bit depth. Higher bit depth (bits per sample) results in a lower noise floor. When audio is digitally processed or resampled, a small amount of noise ("quantization distortion") is added, which accumulates with further processing. This can be mitigated by working at higher bit depths - which is why professional grade audio processing routinely uses 24 bit formats (for storage) and 32-bit or 64-bit floating point internally (for processing), even if the final delivery format is only 16 bit.
Sample rate, on the other hand, affects bandwidth. A higher sample rate recording will contain higher frequencies. It doesn't have any direct effect on the noise floor or level of distortion introduced by resampling, as I understand. (It could have an indirect effect - for example, if certain hardware or plugins work better at particular sample rates.)
A survey of ~2,000 professional audio engineers done in May 2023 showed that 75% of those working in music use 41.1 kHz or 48 kHz, while 93% of those working in post production use 41.1 kHz or 48 kHz.[1] These are the basic CD-derived and video-derived sample rate standards.
From this it's clear that even in professional audio, higher sample rates are a minority pursuit. Furthermore, the differences are extremely subjective. Some audio engineers swear by higher sample rates, while others say it's a waste of time unless you're recording for bats. It's very rare (and practically, quite difficult) to do proper tests to eliminate confirmation bias.
[1] https://www.production-expert.com/production-expert-1/sample...
EDIT: add link to survey.