Identity management is a mess on Azure! I still cannot understand the difference between app registrations and enterprise applications, and how they tie into service principals.
They also have a lot of different resources, such as Graph API, Entra ID.
Manage identities are simpler, since they are Azure constructions, so they work more or less like a IAM role. But then you try to use them with Entra ID APIs and things fall apart.
Sign In with Apple is allowing you to "create an account"(author's words) on @company.com, which should not be supported in the firat place. Instead, it should rely in a central directory controlled by company.com for authentication
"Create an Apple account with support@company.com email"
Wait - how is that workflow possible and supported?
In my head, authorization under @company.com would be delegated to a central directory, instead of relying on Apple ID. It is effectively an authentication bypass.
- CS: Have a staging (production-like) environment for proper validation. It looks like CS has one of these bu they have just skipped it
- IT Admins: Have controlled roll-outs, instead of doing everything in a single swoop.
- CS: Fuzz test your configuration
It is possible Cloudflare did a timepointed release on this. Controlled roll-outs wouldn't work if all the daily chunked updates didn't activate the kernel driver until some point in the future.
That's how I see it too. Not security, but developer experience. You set the file as readonly, but provide a message to PostgreSQL superuser that this is as intended
This is discussed in LWN comments, in fact. But the problem there is that the protocol used to communicate the fact that the file is read-only to the application (errno==EACCESS or equivalent on other platforms) does not provide any useful way for the system administrator who makes the file read-only to add a notice explaining why permission is denied, in a way that it is also communicated to the app - so that it could display it to the user.
So the proper solution to this whole thing would be for the OS to provide such a facility: "permission X is denied to Y because Z". This seems like a useful facility in general, come to think of it. But it would have taken more time and effort, and would require buy-in from more parties, some of whom might be very hostile to this notion (e.g. I don't think it would be an easy thing on Linux). No wonder that this isn't an option that is even contemplated as realistic.
And so instead we got yet another easy-to-make crutch in the tower of crutches and duck tape that is modern software.
"Note that this information only applies to dormakaba Saflok systems; several other lock manufacturers use MIFARE Classic keycards and are not affected by the Unsaflok vulnerability"
So it is likely they way that Saflok implemented MIFARE Classic. Will start to read about this protocol more.
At this point, MIFARE Classic can pretty much be considered plaintext.
There are very fast card-only cloning attacks against even the newest "hardened" cards, and in many of these lock systems (no idea about Saflok in particular though), MIFARE is the only layer of cryptography, and the card only contains a bitmask of locks/doors that it should be able to open.
I have an original London Underground Oyster Card which still works fine! It's MIFARE Classic according to Wikipedia, and do often wonder when TfL will cancel them.
They'll probably keep it around either indefinitely, or will replace it with a fully account-based scheme where there's nothing stored on the card itself (i.e. no stored-value balance) other than an authentication key for the card number.
That's the model they already use for bank (credit and debit) cards too, so they need the backend to manage a deferred account-based system anyway. That's also what the MTA in New York does: They've never supported stored-value cards, and their new physical OMNY cards are effectively just a weird type of closed-loop EMV payment card.
reply