Live data from Hacker News

Things I learnt about passkeys when building passkeybot

enzom.dev

91–100 of 152 posts

Re: Things I learnt about passkeys when building passkeybot

#91

Earlier quoted context omitted.

You already need to submit to iOS or stock Android for a myriad of banking or government apps that use remote attestation to verify that you are running "untampered" software. Remote attestation is evil.

I keep seeing this where? What banks don’t allow you to go to their website and use them from your phone? Which government apps don’t also have websites?

In the EU there is Strong customer authentication [0], part of the PSD2 (Revised Directive on Payment Services).

I read as much about it from the official sources as I could about a year ago, so I might be wrong here. From what I remember even though no specific mention of Android or iOS attestation was made, a "strong" form of 2FA is needed. Stronger than TOTP.

In my country most banks I talked with require a mobile app for 2FA even if you're logging in from a desktop browser. I haven't (and will not) install a banking app on my phone, so I'm not sure if it would work if the phone doesn't pass the attestation (e.g., Play Integrity on Android). I wanted to install the app in an AOSP VM, but no bank would even send me the apk file - they all want me to download it from Google for some reason.

Another option was to pay for a hardware device from a third-party company.

I was lucky that one bank still uses SMS 2FA. It's weaker than TOTP (depending on your threat model, I guess), but I prefer it.

My other option is either to:

* have a smartphone;

* have an "approved" OS from an American company;

* have an account with said American company so I can download the app from the company's repository;

* run closed source software on my smartphone.

or to

* pay for a USB device from a third-party company;

* that barely works with Linux;

* that requires a closed source program to run;

* that doesn't work with VMs and troubleshooting was a pain (I tried).

What I want is to use TOTP. I would actually store the secret on another device, as I'm not opposed to the idea of 2FA in general. And I would be fine if my money were drained as a result of me being hacked. If I had millions in my account, I could just use a separate computer only for the banking, but still a computer I chose.

Online banking (a superset of "mobile" banking) is very important for a person to have in order to participate in society. The ability to choose what hardware and software to use is also very important. The ability to not associate oneself with third-party companies, to accept their ToS and to pay them money is also very important. Therefore, I think those things should be my rights. I'm not complaining about a gym or a pizza place requiring a mobile app here, after all.

[0] https://en.wikipedia.org/wiki/Strong_customer_authentication

Re: Things I learnt about passkeys when building passkeybot

#92
post #31

Earlier quoted context omitted.

There are two problems with passwords. Reuse, and site breaches. The solution to the former is the same as passkeys: credential managers. Passkeys genuinely solve the second, in exchange for a vastly less comprehensible system (see all the uncertainty people have even here on HN) that doesn't support many of the ways people want to use authentication tokens.

No, the biggest issue with passwords is phishing. You can't phish a passkey.

The problem with this is requiring everyone to own a device with a secure enclave or similar hardware capabilities because some people are prone to being phished. Let me choose the level of risk I find acceptable.

Re: Things I learnt about passkeys when building passkeybot

#93
post #87

If I'm being honest, I regret every passkey I ever made. With my old flow, I knew when to use my Yubikey, when to use my OTP, and when to use SMS 2FA. With the new flow, these things say "use your passkey" and I don't know where in god's name I did this. If I did this on my iPhone in a WebUI that popped up when I followed a link to buy something, then it's never going to be on Chrome or Bitwarden. I've decided to sto…

I can't blame you. I know the passkey UX on Windows was absolutely horrible (and probably still is). However I can't say that I relate. I use 1Password and I don't think I've literally ever been asked to use the native UI. It always goes straight to 1Password. I'm not sure why we have different experiences. (I use a mac, an iphone, and a google pixel)

Re: Things I learnt about passkeys when building passkeybot

#94
post #31

Earlier quoted context omitted.

No, the biggest issue with passwords is phishing. You can't phish a passkey.

The problem with this is requiring everyone to own a device with a secure enclave or similar hardware capabilities because some people are prone to being phished. Let me choose the level of risk I find acceptable.

Passkeys don't require this.

Re: Things I learnt about passkeys when building passkeybot

#95
post #87

If I'm being honest, I regret every passkey I ever made. With my old flow, I knew when to use my Yubikey, when to use my OTP, and when to use SMS 2FA. With the new flow, these things say "use your passkey" and I don't know where in god's name I did this. If I did this on my iPhone in a WebUI that popped up when I followed a link to buy something, then it's never going to be on Chrome or Bitwarden. I've decided to sto…

It's all a bit of a mess right now, but with some fiddling in settings you should be able to get your passkeys in one place (probably Bitwarden) and access them everywhere.

Safari on iOS can store and use passkeys from any app that implements the right system API, including the default Apple Passwords but also Bitwarden and Chrome.

For desktop, you can either use a browser extension provided by some password managers (such as Bitwarden), or if you're on a Mac, Safari and Chrome can access passkeys from other apps similarly to on iOS (but not as many providers support this API on Mac as on iOS, and in particular Bitwarden doesn't, so you'd have to use the extension for that).

Re: Things I learnt about passkeys when building passkeybot

#96
post #94

Earlier quoted context omitted.

The problem with this is requiring everyone to own a device with a secure enclave or similar hardware capabilities because some people are prone to being phished. Let me choose the level of risk I find acceptable.

Passkeys don't require this.

How else would you make the private key unexportable and the passkey uncopyable?

Re: Things I learnt about passkeys when building passkeybot

#98

The scariest thing is the casual mention of the Digital Credentials API[1]. Forget passkeys, when you need government issued credentials to surf the net, the good times are over. [1] https://developer.chrome.com/blog/digital-credentials-api-sh...

It's likely that the websites need your actual government issued credentials are not your twitters and your hacker news, but government websites that actually need to link the web user to the citizen. As an example my country has a portal that you use as a citizen to book appointments to government institutions, keeps you updated about the status of your requests, allows you to securely upload scans for additional documents that your request might need, etc.

Re: Things I learnt about passkeys when building passkeybot

#100

The scariest thing is the casual mention of the Digital Credentials API[1]. Forget passkeys, when you need government issued credentials to surf the net, the good times are over. [1] https://developer.chrome.com/blog/digital-credentials-api-sh...

There are plenty of websites and services already where you need to prove your identity to use them. The digital credentials API is an attempt to standardise that which is already legally required in the US, the UK, Australia, and the EU, except without having to upload a picture of your ID to a shady third party website.

The UK law is age verification not identity verification. Now, everyone in practice has collapsed that distinction, whether from incompetence or malice..
Post reply on HN