Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog


IMO = In My Opinion is a blog format where a author reflects his own opinion

As the release of ZITADEL v2 comes closer, I was working on getting the DNSSEC setups ready for our new domains (besides zitadel.com there are more) and I did wonder how the DNSSEC adoption turns out today?

## DNSSEC reputation

I know that DNSSEC has an arguable reputation and [this Stack Exchange article](https://security.stackexchange.com/questions/21121/if-dnssec-is-so-useful-why-is-its-deployment-non-existent-for-top-domains#:~:text=%40JasperWallace%2C%20Google%20is%20implementing%20things,not%20being%20fast%2Fcheap%20enough.) sums it up nicely. Although I agree with a lot of the criticism, I also think that one point is over exaggerated. This being the risk of a government entity taking control over the keymaterial of a domain at the registrar level. “Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.”, cited from [this article](https://sockpuppet.org/blog/2015/01/15/against-dnssec/). While this holds true, it does not reflect the fact that even if the keys were managed in a different way that the control of the domain ultimately still resides with the Libyan government's registry. If we follow down this route of argumentation, the single risk we currently all take is the ICANNs control over the whole system. How ICANN counteracts this concern with public and transparent processes can be read in [this entertaining article](https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/) from cloudflare .

Leaving all this aside makes me still think that a second trust anchor to the TLS PKIs is not a bad thing to consider. By separating the keymaterial from TLS and DNS (let's not talk about DANE for now) from each other, brings the additional value of making it difficult (maybe more time consuming) for an attacker to compromise two separated organizations. The “price” to pay for this is reasonable and it provides some small security improvements.

With the additional rise of DNS over HTTP (DoH) and DNS over TLS (DoT), the security of DNS based attacks should improve over time.

## How we deploy DNSSEC

For quite a while we were running DNSSEC on our domains hosted with Cloudflare. But with the recent changes in our architecture we wanted to reduce the number of companies that process our traffic, this to reduce risks associated with GDPR. With that said we settled for Google's DNS (Cloud DNS) and registrar (Cloud Domains) because we already run many of our services with Google. If you are interested in what we are using from whom checkout [our trust page](/trust).

As a side note, running the DNS server with the same provider as the registrar and TLS CA conflicts with my statement above, where I argued that separating those parties might add to the security. But we think reducing the number of sub-processors and companies involved is worth this trade-off.

## Who else uses DNSSEC

Out of curiosity I wanted to quickly brush over some of the big providers out there and see if they deploy DNSSEC. Let's say the results are confusing, because there does not seem to be a clear pattern of who deploys DNSSEC.

### No DNSSEC deployed

- [Microsoft Login](https://dnssec-analyzer.verisignlabs.com/microsoftonline.com)
- [Microsoft](https://dnssec-analyzer.verisignlabs.com/microsoft.com)
- [Google](https://dnssec-analyzer.verisignlabs.com/google.com)
- [Auth0](https://dnssec-analyzer.verisignlabs.com/auth0.com)
- [Okta](https://dnssec-analyzer.verisignlabs.com/okta.com)

### DNSSEC deployed

- [Akamai](https://dnssec-analyzer.verisignlabs.com/akamai.com)
- [Cloudflare](https://dnssec-analyzer.verisignlabs.com/cloudflare.com)
- [Login.gov](https://dnssec-analyzer.verisignlabs.com/login.gov)
- [Swiss Government](https://dnssec-analyzer.verisignlabs.com/admin.ch)

## Discussion

It is interesting to see who did deploy DNSSEC and who didn't. I think some of the tested sites hold off on deploying DNSSEC because they fear a potential user impact on a large audience. Notwithstanding, I think for security oriented services like a login provider it does not exactly feel like a great way to not enable DNSSEC. We think each element we can use to protect our customers is worth looking into. To be honest DNSSEC is definitely not the silver bullet for DNS security but still it is a minor improvement.


As the release of ZITADEL v2 comes closer, I was working on getting the DNSSEC setups ready for our new domains and I did wonder how the DNSSEC adoption turns out today?

IMO - DNSSEC


IMO = In My Opinion is a blog format where a author reflects his own opinion

At this year's Worldwide Developers Conference (WWDC) 2021 Apple did announce something that really got me thinking about what the future for Risk Based Authentication (RIBA) holds.

In short Apple did announce a feature called “iCloud Private Relay”. What it basically does is to hide the user's origin from the services the user calls. This in a way that Apple and the egress provider should not be able to track the user. Whether that’s true or not is a thing we will see in the future. This design somewhat resembles what TOR does but with less privacy.

<img
  src="/blog/2021-07-07-imo-rba-is-broken-01.png"
  width="100%"
  alt="iCloud Private Relay"
/>

If a user enables this feature, your RIBA seriously will have a bad time. This is because, as you can see below, the user's IP Address will be more or less useless as a signal. As of writing this blog I was in Switzerland and the IP used to egress my traffic was in a region located in the US. If this also tends to change a lot and fast you can basically throw away IP addresses as data of your RIBA.

<img
  src="/blog/2021-07-07-imo-rba-is-broken-02.png"
  width="100%"
  alt="Settings Private Relay"
/>

```json
{
  "ip": "2a09:bac0:205::815:95a",
  "ip_decimal": 55878094235311776708809106431373805914,
  "country": "United States",
  "country_iso": "US",
  "country_eu": false,
  "latitude": 37.751,
  "longitude": -97.822,
  "time_zone": "America/Chicago",
  "asn": "AS13335",
  "asn_org": "CLOUDFLARENET",
  "user_agent": {
    "product": "curl",
    "version": "7.76.0",
    "raw_value": "curl/7.76.0"
  }
}
```

Some of you now might say: “Well we have cookies and browser fingerprinting”.
Yes but with Apple's recent announcement towards improving the privacy features of Safari things are getting harder as we speak. And this does not only apply to Apple but other browsers as well.

So what is the solution to all of this?  
To be frank with you, get rid of your RIBA process and start towards the passwordless journey. It both improves your security and the users' risk quite a lot. If you are interested I dearly recommend that you read my [IMO - Passkey in iCloud Keychain](/blog/imo-passkey-in-icloud-keychain/) as well.

So that’s it? Just throw RIBA away?  
Well there is a nuance to this, which I might encourage you to differ a little from that view. If we are talking about **re-authentication** and **session management**, I still recommend you to use signals you collect about the device and user, for example user-agent version, language, time, TLS version and cipher and so on to prevent things like “session cookie extraction” from the browser.

**But please stop relying on RIBA for the plain authentication of a user!**

## Resources

https://www.apple.com/newsroom/2021/06/apple-advances-its-privacy-leadership-with-ios-15-ipados-15-macos-monterey-and-watchos-8/

https://www.theverge.com/2021/6/10/22526881/apple-icloud-plus-privacy-subscription-services-revenue-wwdc-2021

https://www.heise.de/hintergrund/Die-Kruecke-fuer-Passwoerter-und-wie-sie-ausgenutzt-wird-4970547.html


Apple's “iCloud Private Relay” breaks risk based authentication (RIBA). You should get rid of your RIBA process and start towards the passwordless journey.

IMO - Risk Based Authentication is broken


IMO = In My Opinion is a blog format where a author reflects his own opinion

With the recent announcement of Apple at their annual Worldwide Developers Conference (WWDC) 2021, our perception of how secure authentication should work will gradually shift towards a passwordless future.

The new(est) innovation from Apple to get rid of passwords and second factors is called “Passkeys in iCloud Keychain”. It basically works with the WebAuthN API by utilizing the FIDO2 specification (CTAP2) to create a private / public key pair for each login system. This is normally identified by its domain name of the server challenging your device for authentication. For this to work across devices it is necessary to synchronize the private key in some way.

[Edit: The video has been removed from youtube. You can watch it on developer.apple.com](https://developer.apple.com/videos/play/wwdc2021/10106/)

But wait … synchronizing a private key across your devices with a cloud solution does not sound exactly … sane!  
Well, ok. Let's argue for a minute what the “normal” user does anyway. Many users today rely on password managers to synchronize their passwords and sometimes even their second factors. By doing so, they already expose their secrets to some provider, for example Google, Apple, Microsoft, 1Password, and so on. Even if those providers claim that the secrets are encrypted, it is not a penny better from a security perspective than the synchronization of a private key with the same process. In the end, all private keys, passwords and OTP seed secrets are all **secrets** which allow access to your resources.

But then again, some of you might argue: “I totally control the sync process with a software I run on my own!”  
Well that does not really change the statement above because you end up using a device from one of those vendors anyway and most of them are closed source, so you have absolutely no guarantees that they don’t steal your credentials on the OS level anyway (some exceptions apply - looking at you Linux and to some degree Android).  
To make things worse on an OS or even browser level. Something, like a malicious browser extension or trojan horse, could steal things like access_token or cookies, which broadens the threat model a lot towards OS and browsers.

Oh and to make things worse… Out of band processes like OTP, SMS-TAN and email codes don’t help this effort. If you gain access to either the user's device, OS, or browser, then your whole security model is broken anyway. This is because a lot of today's users just use one device in which they login and also store, receive or generate their second factor.

Ah and yes don't even get me started about those pesky banking authentication apps!

So with this in mind is it still a bad thing to sync the private key?

Well, in my opinion, even with all the downsides like synchronization of private keys (secrets in general) we still gain an **improved user experience** and **phishing resistance**, which I find important these days **without any additional risk** (remember you have them anyway). Also, we reduce the attack surface by **preventing credential reuse** by the user.

So if you ask me: The tradeoff made here by Apple does outweigh the risk. And if you think this risk is too high for you, then just do not use iCloud Passkeys (and password managers in general) and stick to hardware keys.  
If you really care about security you would end up with mTLS (mutual TLS) anyway because this is the only way to mutually authenticate connections and mitigate Man-in-the-middle risk more or less completely (which FIDO2 does not). But this is a topic for another time.

If you want to test iCloud Passkeys today you are best off to use iOS 15, iPadOS 15 or macOS Monterey. Optimally you have multiple devices to see whether the keys get synced across your devices with iCloud Keychain.

As of today more and more systems and services offer the use of passwordless authentication methods. For example your Microsoft Login can be used in this way. Popular Open Source IAM Solutions like Keycloak also give you the option to use passwordless. Our IAM as a Service project ZITADEL does also provide support for the password authentication future.

But remember: Passkeys in iCloud Keychain are **not production ready yet** (technology preview) and are intended for testing only. So for your own sake, please register a fallback hardware key like the ones from our friends at SoloKeys or YubiKey. We recommend you to register multiple keys anyway.


Apple spearheads the push to a passwordless future. But is their proposal to sync your private keys with their iCloud a good idea?

IMO - Passkey in iCloud Keychain

All posts/ #imo

IMO - DNSSEC

IMO - Risk Based Authentication is broken

IMO - Passkey in iCloud Keychain

Why

Explore

Company