ivlad

Microsoft runs a bug bounty program. NightmareEclipse (that’s the researcher’s handle) allegedly participated and Microsoft did not honor their part of the bug bounty program terms.

This is a completely different situation - a company evaluates the security of a prospective vendor prior to entering a business agreement.

Minority of sites have global traffic. This is especially true for non-English sites.

So, while average request may have to travel quarter (not half) of the Internet globe, median request from the set of requests that matter has much lower latency.

Barcelona to Stockholm is about 65ms, ~35ms to Amsterdam, ~43ms to Frankfurt.

HTTP/3 is ubiquitous, you don’t get TCP handshake penalty anymore in major browsers.

nginx can do about 20krps per CPU for static files. You only need CDN if you want to improve time to DOM loaded in locations where time to first byte is over ~100ms and can be improved with local caching.

If all your users are in Spain and you don’t care how fast your site loads for a techbro in California, you indeed don’t need CDN.

> PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover.

You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.

I might be missing something: is this any conceptually different from using PKCS11 provider for TPM in OpenSSL?

Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.

If someone eats junk food at McDonald’s it does not mean I should eat junk food at Burger King. If someone does not encrypt their radio comms, it does not mean I should be satisfied with breakable encryption.

Absolutely

The whole post is a PR activity presented as some kind of analysis. It is bs.

First, long-living credentials are the standard because the machinery to rotate them is complicated and, in fact, via indirection requires another set of long-living credentials. Out of all problems that any security engineering team has to solve at an organisation, this one stands high on the cost of implementation, adds friction to everyone involved including end-users, and is low on the value provided (compare to, say, network segmentation).

Second, while proclaiming no long-living credentials, they, in fact argue for concentration of long living credentials in running software that will be the target of intrusion. They say, the options are “a vault that only issues short-lived creds based on long-lived creds that you insert once and that it never gives back” and “a credential-injecting proxy”. Both of those applications hold long-living credentials in memory. Recall, the attacker had root privileges on the node, so dumping the creds from the memory with a little disassembly if needed, was in reach of the AI agent.

Funny enough, they dismiss the working solution: “we had to turn TPM storage off by default on Linux and Windows” - because they could not figure out how to work with TPM? Resealing and the workings of configuration registers is non-trivial, I admit, but totally manageable.

To sum up, I feel the author bends backwards to preach for the religion of short-living credentials even when they are not a solution while providing contradictory arguments for their case. This is why I called it bs.

Lack of the authentication means an adversary can feed any data to the receiver.

Local data access is a win, I agree

09 F9 !!

44 bits of security is not “pretty good”. The post author used Python, but anything more performant would result almost real-time decryption.

There are no performance implications of using a proper 128 key because they are doing AES anyway. If they were resource constrained and choose a variant of TEA encryption due to constraints, it would be understandable, but no, the encryption is implemented in hardware.

There also seems there is no message authentication, a rookie mistake.

Technically, no.

SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.

Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.

Three so-called “cribs” are typically mentioned in literature:

1. Weather reports that were encrypted with Enigma for the High Command and then sent again encrypted with a much weaker cipher for (if I recall correctly) merchant fleet.

2. “Keine besondere Nachrichten” or “Keine besondere Ereignesse” - depending on sources. It means “no important news” or “no important events”.

3. “Heil Hitler” at the end of the message. This one is maybe an anecdote. If something like that would be sent I suspect the radio operators would send “HH” at most.

Mandatory watch: https://www.youtube.com/watch?v=pyMNIFZTQkg

I have deployed FIDO authenticators at a ~2000 employees organization as the second factor. It was great for a while - when early versions of macOS and iOS respected the “platform” claim and created non-exportable private keys backed by Secure Enclave. Windows was never a problem, keys were created in TPM. We mandated 2 FIDO credentials - typically the laptop and either a phone or Yubikey (or both). People were encouraged to use the later but as soon as the keys were not exportable, phones were acceptable.

Then, Chrome got an update and started hijacking the enrolment process from the operating system and created keys synced to Google Account. This resulted worse UX because authentication now required pulling the Android phone (for those unlucky ones who have it) and confirming the login there instead of doing it right on the computer, uninterrupted.

Then, Apple followed with cloud-only key pairs and then so did the password managers (including Bitwarden Enterprise we were using) and everything become a mess.

The only solution would be to use the key attestation and to only allow specific security keys. Both Chrome and Apple have config knobs to simplify enterprise attestation (a strong assurance, which FIDO authenticator has been used), but neither Windows nor macOS support key attestation for hardware-backed keys (and macOS ignores “platform” claim altogether).

It sucks.

Neither Apple nor Google do key attestation for their cloud-synced keys.

This

    > Which is happening with all the big platforms right now.

Does not seem to be happening. Am I missing something?

If you are going to store passkeys in a password manager, the whole situation is no more secure than just using passwords.

Consider:

1. Password managers tie passwords to sites, so phishing-resistance is achieved. 2. Password managers allow long, complicated, individual password per web site, so compromise blast radius is 1.

I was talking about the non-resident FIDO keys. “Passkey” term is meaningless unfortunately because FIDO Alliance did not define it initially, it was a marketing term invented by Apple and then re-introduced (or shoved down the throat) by the FIDO alliance.

In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys.

Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed.

Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.

> The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud).

From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.

Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.

> Not true. The original concept was always for them to be cloud synced.

It was not. The original U2F spec was created before that idea was around and it talked about hardware security keys as means to store the primary key pair.

I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.

You don’t. You don’t store anything at all.

On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there.

On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in.

Expanded: As long you as the user has the security key fob, you can login. You should have 2.

Or, you use `xargs -0` for null termination instead of white space termination. `find` conveniently supports `-print0` that will use null character as separator.

Was exactly my thought: why not to use null termination?

Looks like a case where reading man page would have spared writing another copycat utility.

TP-Link is absolute crap of network hardware. Not to mention “leftover debug code”: https://nvd.nist.gov/vuln/detail/CVE-2024-21827

Genuine question, if you use bastion hosts, why do you need Tailscale? Why not to expose tcp/22 to the internet and allow public key authentication only (or, certificate based one, if you prefer fancy)? OpenSSH security track record seems to be better than that of Tailscale.

Rolex and Casio deal with simply when IERS introduces one.

Beats is a new time measurement system, not just a new clock. So if the world (IERS) would stops it, they would have to have new rules for dealing with leap “micro-days” or “mili-beats”.

And second is the fundamental SI constant, quite a bit of stuff is derived from it.

Enterprise PKI is not hard and has many uses besides issuing certificates to web servers. Any company of 1000+ users or endpoints should just set one up.

I did it multiple times, most recently using YubiHSM as root key store for offline enterprise root CA.

Or, just use IPv6 and host Internet services in a routable address. Then, use ACLs at web server / proxy / L7 lb level to allow acme-challenge unauthenticated but everything else authenticated.

Lets encrypt supports IPv6 for validation.

It looks like a poorly thought-out marketing project. For example, how to deal with the Earth rotation irregularity and leap seconds? One beat is way too long to correct with, so the correction has to be in centibeats, fractions of beat, inconvenient. Why would this in CET and not in UTC? Aligning start of the day with the existing customs seems beneficial.

But the idea of the universal decimal time is a nice one. I wish we had something like that.