{"@attributes":{"version":"2.0"},"channel":{"title":"jrt","link":"https:\/\/jrtberlin.de\/","description":"Recent content on jrt","generator":"Hugo -- gohugo.io","language":"en-gb","lastBuildDate":"Sun, 21 Jun 2026 21:30:00 +0100","item":[{"title":"Passkeys: A comprehensive overview","link":"https:\/\/jrtberlin.de\/p\/passkeys-a-comprehensive-overview\/","pubDate":"Sun, 21 Jun 2026 21:30:00 +0100","guid":"https:\/\/jrtberlin.de\/p\/passkeys-a-comprehensive-overview\/","description":"\"Featured

Passkeys are everywhere right now. But Why should I care?<\/em> My password is secure!<\/em><\/p>\n

In this post I try to cover how we got into to today’s mess of authentication methods and why passkeys are a good option going forward.<\/p>\n

How did we get here?\n<\/h2>

The first computer password allegedly 1<\/a><\/sup> dates back to the MIT Compatible Time-Sharing System (CTSS), with multiple terminals that where not user-specific but with each user having an individual set of user-owned files. At the time it seemed like a straight forward idea. Yesterday’s solutions like security questions<\/em> about your mothers maiden name where also considered but discarded due to higher resource usage for something so unimportant like authentication.<\/p>\n

Interestingly for us, the system was also a target of the first password theft. Using punch cards users could request to print specific files offline. Allan Scherr, a Ph.D. researcher at MIT at the time, requested a print-out of the file containing all passwords. The next day he found a printout containing all the systems-passwords.<\/p>\n

This illustrates two security issues:<\/p>\n

    \n
  1. If there is a path for actions to be taken with weaker or no authentication it can bypass the resilient authentication flow.<\/strong>\nThis is still the case with passkeys. If you log in using an alternative login method that bypasses the secure path the best authentication method does not protect you.\nRecent articles about “hacked” passkeys used alternative login methods (e.g. smart TV specific login flows) 2<\/a><\/sup>\nImplementors need to look at the authentication flow holistically instead of adding another option. The weakest link will still break, if you put a strong one next to it.<\/li>\n
  2. If you have access to the password database, all passwords are compromised.<\/strong>\nThis is true for all shared secrets<\/strong> and still applies today to the concept of passwords.\nWhile it is best practice to hash and salt the stored passwords and the plain-text is not written to disk, the hash and salt combination enables an offline attack using word lists or sheer brute force to try to find a match for the given hash. Bypassing every rate limit. Once found, the password can be used to authenticate against other systems as well, if the user reused the password. This concept is known as credential stuffing<\/strong>.<\/li>\n<\/ol>\n

    The MFA Pitfall\n<\/h2>

    We now know that passwords are shared secret that can lead to credential stuffing attacks<\/strong> because of password reuse. The underlying psychological issue goes a lot deeper than that.\nAs everyone who interacts with computers from time to time knows: A user can set their own password.<\/strong><\/p>\n

    The main security of passwords from the user perspective hinges on only a few things:<\/p>\n

      \n
    1. \n

      The password should be complex<\/strong><\/p>\n

      Passwords should ideally contain a random selection of characters from a large alphabet (e.g. numbers, letters, special characters,…) and should have a sufficient length. The result is a password that’s hard to brute force but also hard to remember for most humans.<\/p>\n<\/li>\n

    2. \n

      The password should be stored securely<\/strong><\/p>\n

      The complexity makes the password hard to remember. The result is that a lot of people write their passwords down. The classic example how this could be a problem is a post-it note on the monitor or under the keyboard containing the password. Writing passwords down in itself isn’t an issue when stored securely. Only in shared spaces or when others can access it, the behavior turns into an issue, essentially being the same thing as a key under a rock next to a locked house door.\nThis leads to many users logging in via the password reset flow, bypassing the password authentication flow. This is more or less the same as a magic link<\/strong> with extra steps. In a lot of scenarios the support staff can be convinced to change the associated e-mail address via phone, leading to the password reset e-mails being sent to the attacker.<\/p>\n<\/li>\n

    3. \n

      The password should only be entered on the correct site<\/strong><\/p>\n

      Phishing<\/strong> is one of the oldest and most effective entries into organizations and user-accounts in general. Scientific studies indicate that awareness campaigns are not an effective solution to the problem. 3<\/a><\/sup> The main issue is that once an attacker convinces the user that the site where they try to log in is the legitimate one the user is very likely to enter their credentials. With minor typos and look-alike, punycode<\/strong>, domains it is error-prone for users to differentiate correct from malicious domains. As an example jrtberlin.de<\/code> and jrtb\u0435rlin.de<\/code> are almost indistinguishable from each other depending on the font. The second one contains the Cyrillic small letter \u0435<\/code> instead of the Latin e<\/code>.<\/p>\n

      This issue is further increased by a very diverse landscape of valid domains. A friend of mine (@ljrk@todon.eu<\/a>) made a point in a class by having students decide which of the listed domains is an official Microsoft owned domain. 4<\/a><\/sup><\/p>\n

      Some examples like sharepont.online.com<\/code>, office.m365.com<\/code> and sharepointonline.com<\/code> sound plausible, while legitimate ones can sound phishy<\/em> as well like microsoftrewards.com<\/code>.<\/p>\n<\/li>\n

    4. \n

      The password should be unique<\/strong><\/p>\n

      People are bad at this because of all the before mentioned points. A lot of people pick the easy route and just use their password<\/em> for everything where it complies with the password policy.<\/p>\n<\/li>\n<\/ol>\n

      All in all: The password as a concept fails Saltzer’s and Schroeder’s design principle of psychological acceptability, if the password is good. 5<\/a><\/sup> 6<\/a><\/sup><\/p>\n

      Because of the before mentioned issues with passwords compliance teams, security staff and regulatory rules often require a second factor (2FA), often referred to as multi-factor-authentication (MFA).\nMFA methods are an add-on to a flawed authentication method, complicating the authentication process, while not resolving most issues.\nWhen an attacker convinces the user to trust that the phishing site is the real one and the user enters their password, there is no reason not to enter the time-based one time password (TOTP), match the displayed Number or press authenticate within the app.<\/p>\n

      Most phishing frameworks have built-in support for relaying second factors in real time.7<\/a><\/sup> The second factor usually tries to resolve one issue: credential stuffing<\/strong>, because it makes the secret the user uses to authenticate unique. Through its addition of a truly unique and machine-generated challenge-code, it renders the combined secret the user uses to authenticate as effectively unique. This makes the requirement of MFA so popular, since it’s hard to enforce a unique-password-policy through technological means, unlike enforcing MFA.<\/p>\n

      \n
      \n \ud83d\udcdd<\/span>\n Note<\/span>\n <\/div>\n
      \n

      If you already have unique passwords, TOTP and similar only add negligible additional security. Further, storing them in the password-manager alongside the password reduces the security only by a negligible amount, if the individual is not targeted directly by adversaries, since credential stuffing is forfeited in this case as well – phishing with TOTP replay works independently of the TOTP’s storage location.<\/p>\n <\/div>\n <\/blockquote>\n

      In reality attackers employ a social engineering technique where they try to log in using the credentials, generating authentication request notifications for the user. If the user doesn’t approve the login, the attacker will continue to spam the user with new authentication requests. Annoyance can result in a user approving the action in hope to end the spam or pressing approve on accident. This psychological weakness is known as mfa fatigue<\/strong>.<\/p>\n

      One MFA-method that increases in popularity that tries to resolve this issue is the magic link<\/strong>: When the user authenticates, they get an e-mail containing a link. Opening the link logs the user in. This method has a few issues but can, when used correctly, offer some phishing protections. One typical issue with this method is in the implementation. It is important that the link does not authenticate a remote session and only authenticates the user on the device where the link is clicked. Otherwise, an attacker would get authenticated when a user clicks the received link and the phishing site tells the user to check their e-mails.\nA lot of sites in recent years have adopted this method or even replaced passwords entirely with this method. While being an improvement in terms of security, this method has some issues as well:<\/p>\n