Hacker News Reader

Comment by lelandbatey | Hacker News Reader

I'm so glad this has been created. I've felt for quite some time that TOTP is such a triumph of simplicity and security. It's so simple that if you have your secret key on hand, you can generate your TOTP code with just 30 lines of Python!: https://github.com/susam/mintotp/blob/main/mintotp.py

It's amazing! Its default UX assumes you're basically air gapped. It works based on a minimal shared secret that's totally portable. Conceptually, it's as clear as "hash (your secret+(now()//30)), display hash as decimal, only show the last 6 (ish) digits".

What a triumph. I love TOTP.

This is meant as a sidelong critique on passkeys.

View on HN

It doesn't have the killer feature of passkeys though, vendor lock-in. Which is the sole purpose of them.

Wrong, what it's missing from passkey is phishing resistance. And you can use passkeys with at least a few independent commercial password managers if you are not happy giving your passkeys to Google & Apple (I work for one such password manager)

Psst: your employer is a vendor benefiting from said lock-in.

Without a means for transfering from one password management resource to another, passkeys create an increasingly significant friction against migrating one's account and artifically reduces competitive pressure on the vendor.

The phrase we use for that anti-consumer phenomenom is "vendor lock-in"

(If your employer has an effective and practical import and export technique for passkeys, I would be delighted to hear so and apologize for the suggestion otherwise. But as far as I've seen, that's not a thing.)

Passkeys are still very much work in progress but there will be standard ways of transferring passkeys between password managers at least https://www.theverge.com/2024/10/15/24270875/password-manage...

I'm not working specifically on passkeys lately so I don't know exactly what is already available to the public, I'll ask around

That is table stakes. So, rewind 5 years. Introduce that, remove attestation while you are at it. And make sure we have multiple compatible implementations.

Without it passkeys are a sham. And since that was and is the case I don't see any conceivable future where passkeys benefit anyone but google/apple/ms. For the sake of the web it needs to die.

The expectation is that for any service you should be able to have multiple passkeys -- including multiple passkeys from different vendors. I'm not sure how that exactly causes lock in?

Exactly, you can just register passkeys from multiple providers if that's a fear. Worst case (i.e. Google nukes your account and you've only set one passkey), you go through the usual email recovery or backup codes process and set a new one.

That misses the overhead of having to rotate the passkeys for thousands of websites you've used them on.

Being able to export a passkey sounds like a bug, not a feature. I was surprised that the spec was altered to allow hosting in the cloud at all, I thought it was more interesting as a means of keeping secrets in secure enclaves.

It would be good to have a FOSS-implementation with TPM as the storage backend for computers and phones. Then people wouldn't need to use keys stored in the cloud.

Have a look at Keepassxc. It doesn't use a tpm, but supports passkeys and is portable.

This is the sole reason I'm avoiding passkey setup. How big of a worry is it?

Assuming you've only set one passkey (you can add multiple passkeys from different passkey managers) it's no more of an inconvenience than if you lost your password. Normal recovery/backup code processes still work.

TOTPs are amazing! I'm currently building a low-power, offline ESP32 device that generates time-based one-time QR codes and displays them on an e-ink screen. I plan to use it for proof of presence.

What's your approach for keeping the clock in sync?

I use a GPS module that turns off once it has retrieved the time and location.

Here is a short breakdown of the project: https://github.com/sweing/TOTP-QR-Gen/blob/main/post.md

if you're only doing the signature generation rather than the full protocol (which TOTP leaves entirely up to the user), then the code to generate a passkey signature wouldn't be any longer

Yeah, I have implemented it in PHP and Lua as well, cannot check the LOC right now, but it is around ~30 as well, if not less, at least in PHP.

It’s definitely a fairly trivial implementation, here’s one of a few dozen lines of (not very clean) Swift: https://github.com/JustAman62/ovault/blob/7ee38b7e5c2666cd34...

The simplicity of the implementation makes a test suite even more valuable, as it’s really quite hard to figure out if your implementation is correct.

As part of writing the test suite, I also wrote an implementation in JavaScript. It uses the Web Crypto API rather than external libraries.

https://shkspr.mobi/blog/2025/03/using-the-web-crypto-api-to...

Reply on news.ycombinator.com