New two-factor authenticator: Commodore 64(oldvcr.blogspot.com)
oldvcr.blogspot.com
New two-factor authenticator: Commodore 64
http://oldvcr.blogspot.com/2022/11/meet-your-new-two-factor-authenticator.html
63 comments
It might be air gapped, but knowing the quality of electronics in those days, I would guess a C64 is not immune to data exfiltration via EM radiation through the air or through the power supply or via the keyboard. :-)
I remember tuning in to C64's channel from a different room's TV.
The RF encoder + cable acted as a transmitter.
The RF encoder + cable acted as a transmitter.
Back in my day, wireless was a bug, not a feature!
Indeed, a bug in the other sense too.
Once in the early 90s, I was attached to a consulting firm whose primary goal was helping businesses get onto the Information Superhighway all the CEOs were buzzing about.
We were granted a guided tour one night of a facility at the top of a skyscraper in San Diego. It was shrouded in mystery and government TLA programs. My boss was explaining parts of it to me.
He said this is a TEMPEST secure facility. I'd never heard the term but when he described the principle to me it made a lot of sense. My father is a radio buff and raised me to learn all about electromagnetic stuff. The facility had conditioned power lines and shielded walls and partitions that could block EMR effectively to keep computing information safe from prying eyes.
There were other fascinating Top Secret features of the facility that were explained to me that night. Of course the facility was not in operation and unmanned at the time of our unclassified tour. I was gobsmacked at the depth of real bona fide security measures and countermeasures, even in those primitive times.
We were granted a guided tour one night of a facility at the top of a skyscraper in San Diego. It was shrouded in mystery and government TLA programs. My boss was explaining parts of it to me.
He said this is a TEMPEST secure facility. I'd never heard the term but when he described the principle to me it made a lot of sense. My father is a radio buff and raised me to learn all about electromagnetic stuff. The facility had conditioned power lines and shielded walls and partitions that could block EMR effectively to keep computing information safe from prying eyes.
There were other fascinating Top Secret features of the facility that were explained to me that night. Of course the facility was not in operation and unmanned at the time of our unclassified tour. I was gobsmacked at the depth of real bona fide security measures and countermeasures, even in those primitive times.
It should be possible just from the monitor: https://en.wikipedia.org/wiki/Van_Eck_phreaking
Yes, I remember when I was a child flipping through the UHF channels on my black and white tv, visible in the snow and static on one of the channels I could see the shapes in motion of my next door neighbour playing on his Atari 2600.
That most likely was caused by an overpowered "RF Modulator" transmitting a strong enough signal for you to pick up. One popular model used UHF Channel 33 https://en.wikipedia.org/wiki/Sup%27R%27Mod
This is unrelated to "Van Eck Phreaking"
This is unrelated to "Van Eck Phreaking"
Somewhat related: [(Theoretical) long range wireless NES video](https://youtu.be/8sQF_K9MqpA)
Van Eck phreaking FTW! :)
Anyone who actually needs to be wary of this wouldn't be using a C64 anyways. Why do people feel the need to protect against such theoretical boogeymen that literally don't care about them?
Did you miss the :-) at the end of their comment?
TOTP has far worse problems, like phishing. TOTP should only ever be implemented for low risk novelty use cases and any website that still supports it should be ashamed of themselves.
This seems like a classic case of perfect being the enemy of good. TOTP is so much better than SMS codes, and they are still very widely used.
This is a "not as bad as" fallacy.
https://rationalwiki.org/wiki/Not_as_bad_as
TOTP is phishable and the secrets to unlimited codes live in plaintext on both the client and the server. Endpoint malware, phishing, and database dumps are some of the biggest threats online and TOTP offers no strong defense to any of these. In some ways TOTP is even worse than SMS as it is possible to manipulate timestamps to get a code valid in the future. SMS and TOTP both are garbage in terms of both security and UX. Their use should be discontinued ASAP.
Webauthn solves for these problems, and everyone has devices that support it already. It is negligent at this point for web service providers to not mandate webauthn and discontinue both SMS and TOTP.
https://rationalwiki.org/wiki/Not_as_bad_as
TOTP is phishable and the secrets to unlimited codes live in plaintext on both the client and the server. Endpoint malware, phishing, and database dumps are some of the biggest threats online and TOTP offers no strong defense to any of these. In some ways TOTP is even worse than SMS as it is possible to manipulate timestamps to get a code valid in the future. SMS and TOTP both are garbage in terms of both security and UX. Their use should be discontinued ASAP.
Webauthn solves for these problems, and everyone has devices that support it already. It is negligent at this point for web service providers to not mandate webauthn and discontinue both SMS and TOTP.
You are using that fallacy incorrectly. Additionally, quoting fallacies at people is it itself a fallacy when used in this way, is tiresome, and probably best avoided.
Webauthn has a number of severe usability downsides that will conspire to hamper its adoption outside of use cases where people are literally forced to use it.
1. The keys cannot be backed up. Nobody is going to accept being locked out of their online accounts if they lose a physical key.
2. Nobody wants to mess with a physical key when logging in anyways. At least TOTP can live in my password manager.
3. The options for not having physical keys are platform specific, tie you to a platform providers account for backup, and turn an operating system reset or a new smart phone or badly applied ban or account lockout from an annoyance to a possibly catastrophic loss of functionality.
None of these are problems in the enterprise because they have simple workarounds. For the rest of us? Yuck. I will gladly keep my platform independent, easy to back up, widely ubiquitous standard with the trade-off of looking at the URL bar when logging in and not clicking links in emails.
Webauthn has a number of severe usability downsides that will conspire to hamper its adoption outside of use cases where people are literally forced to use it.
1. The keys cannot be backed up. Nobody is going to accept being locked out of their online accounts if they lose a physical key.
2. Nobody wants to mess with a physical key when logging in anyways. At least TOTP can live in my password manager.
3. The options for not having physical keys are platform specific, tie you to a platform providers account for backup, and turn an operating system reset or a new smart phone or badly applied ban or account lockout from an annoyance to a possibly catastrophic loss of functionality.
None of these are problems in the enterprise because they have simple workarounds. For the rest of us? Yuck. I will gladly keep my platform independent, easy to back up, widely ubiquitous standard with the trade-off of looking at the URL bar when logging in and not clicking links in emails.
People saying that we cannot deprecate and replace TOTP because it is better than SMS is broken logic thrown around in places like HN -constantly- and -that- is tiresome to me. It seems like a verbatim of the fallacy I linked, but I admit I linked it out of frustration with seeing this poor defense of TOTP constantly.
To your points:
1. Multiple devices such as Ledger support FIDO key backups in the form of transcribing simple english words to paper. Most services support multiple webauthn devices registered at once though which is simpler for most people. You can also as a last resort offer a user with a one-time-use 2FA reset code just like TOTP sites do if you wish. Lots of options.
2. Your laptop and phone already have built in webauthn authenticators if you have a device made in the last several years.
3. See #1 for backup options
The default paths for TOTP recommended to most like Google Authenticator do not have a backup solution either. Users will have to research alternative TOTP solutions that support backups just like Webauthn, so that situation is no worse.
Webauthn is as good or better in UX and better in every way in security. People had to learn to use TOTP, which is complicated. People capable of using TOTP are technical enough to register two webauthn devices like a phone and a yubikey, or a phone and a laptop, or failing all else a phone and a paper backup.
To your points:
1. Multiple devices such as Ledger support FIDO key backups in the form of transcribing simple english words to paper. Most services support multiple webauthn devices registered at once though which is simpler for most people. You can also as a last resort offer a user with a one-time-use 2FA reset code just like TOTP sites do if you wish. Lots of options.
2. Your laptop and phone already have built in webauthn authenticators if you have a device made in the last several years.
3. See #1 for backup options
The default paths for TOTP recommended to most like Google Authenticator do not have a backup solution either. Users will have to research alternative TOTP solutions that support backups just like Webauthn, so that situation is no worse.
Webauthn is as good or better in UX and better in every way in security. People had to learn to use TOTP, which is complicated. People capable of using TOTP are technical enough to register two webauthn devices like a phone and a yubikey, or a phone and a laptop, or failing all else a phone and a paper backup.
Sure, it may not be as secure as FIDO/WebAuthn, but it's a lot better than SMS/Email 2FA.
Arguing SMS is better than TOTP is like arguing IE7 is better than IE6. Sure, but both are so far from being anywhere near a reasonable solution today I cannot understand why people make an argument like this seriously.
Everyone has a webauthn capable device, if not multiple, right now.
The only reason phishing is still a thing is because people keep implementing and defending phishable 2FA methods.
Everyone has a webauthn capable device, if not multiple, right now.
The only reason phishing is still a thing is because people keep implementing and defending phishable 2FA methods.
iPhones have only just gotten support for acting as Bluetooth authenticators, and from what I can tell, Android devices have only had it for a year or so. So we only now seem to be at the point where most people would have a device they could use as a WebAuthn authenticator across multiple devices, making it only now a viable replacement for TOTP for most people (without buying a hardware authenticator). I don't see anything shameful about still supporting what was until recently the best option for most people.
(Personally, I'll be waiting until 1Password gets WebAuthn support before moving to it from TOTP.)
(Personally, I'll be waiting until 1Password gets WebAuthn support before moving to it from TOTP.)
People can also use software browser-plugin authenticators, or software solutions provided by their operating systems. Even software anchored webauthn still stops far more threats than TOTP or SMS. That said few would need that fallback as TouchID or Chromebook authenticators or Windows Hello all work great too.
1Password is a centralized and proprietary database system that leaks all secrets to system memory every time you use one. Why would you want that to manage webauthn secrets for you? You just tap your webauthn device when prompted. No third party control required.
1Password is a centralized and proprietary database system that leaks all secrets to system memory every time you use one. Why would you want that to manage webauthn secrets for you? You just tap your webauthn device when prompted. No third party control required.
And if I need to sign in on another device, I can't use that platform authenticator, as it's tied to that device. So I'd have to either have another WebAuthn authenticator, or use a fallback method like TOTP or SMS, which defeats the whole point of using only WebAuthn. And most people won't go and buy a hardware authenticator. So like I said, WebAuthn is only now just starting to become viable for the average person to use instead if TOTP.
You simply add each device you want to login with as a trusted device. Most services allow you to add as many devices as you want. I do not understand why this is a adoption barrier.
And then if you get a new device, you have to somehow log in on that new device (with either backup codes, enabling TOTP or SMS 2FA temporarily, etc), and add the new device as an authenticator. And repeat that across every service. Same for new/existing accounts, people don't want to have to add every device to every service they use. Not being able to use your WebAuthn authenticator on other devices is an adoption barrier (as is the alternative of buying a hardware authenticator).
Hi. Concerning 1Password and leaking to system memory… What about the others like Bitwarden/Vaultwarden or KeePass and Strongboxsafe? Aren’t they doing the same?
Any password manager would need to decrypt passwords in order to use them, and that has to be done in system memory. And short of using something like a TPM or Secure Enclave, or asking for the master password each time, the decryption keys have to be in memory as well. You're always going to be subject to the security of the OS you're running on as to who can read your process's memory.
As someone who is rather distrustful of the real motives of the security in general, TOTP is IMHO a good solution that increases security for the user but is also entirely under the user's control.
As this article shows, a 6502-level CPU is definitely powerful enough to do this and other crypto primitives; smartcards, which can perform RSA operations, are roughly of the same power.
As this article shows, a 6502-level CPU is definitely powerful enough to do this and other crypto primitives; smartcards, which can perform RSA operations, are roughly of the same power.
TOTP is a cute trick (we used to do mOTP which is very similar, on phones, back when "smart" phones weren't a thing yet) - But, it isn't actually really good security. It's easily phished and it relies on a secret which means either party might leak that secret.
FIDO in contrast has better security and retains control, with the main loss being simplicity, I understand how it works pretty well, but most people aren't going to really put the time in or have the inclination.
FIDO is designed to be used for things like WebAuthn, which can't be phished, and doesn't use secrets so the Relying Party doesn't know anything which can be compromised.
You can build one yourself, buy Solo Keys, or indeed buy a Yubico product.
FIDO in contrast has better security and retains control, with the main loss being simplicity, I understand how it works pretty well, but most people aren't going to really put the time in or have the inclination.
FIDO is designed to be used for things like WebAuthn, which can't be phished, and doesn't use secrets so the Relying Party doesn't know anything which can be compromised.
You can build one yourself, buy Solo Keys, or indeed buy a Yubico product.
I actually prefer TOTP, at least personally, as a perfect compromise. The problems with FIDO, besides the obvious lack of adoption, are the expense of key devices, difficulty of backups, and lack of support on many devices that don't have NFC (even those that do are frequently spotty)
The 'leaking' of the secret is, to me, a feature. That means I can safely store it as a backup (printed in a safe, even) and restore it to any device I want in seconds. I don't care about a leak by the service, because that is game over for my data there anyway: if they can't protect 2F secrets, nothing is safe.
Really, mutual TLS would be perfect, but nobody is going to support that. I seem to remember even Windows tried something like that a decade ago and even their weight couldn't break us away from passwords for Internet sites.
The 'leaking' of the secret is, to me, a feature. That means I can safely store it as a backup (printed in a safe, even) and restore it to any device I want in seconds. I don't care about a leak by the service, because that is game over for my data there anyway: if they can't protect 2F secrets, nothing is safe.
Really, mutual TLS would be perfect, but nobody is going to support that. I seem to remember even Windows tried something like that a decade ago and even their weight couldn't break us away from passwords for Internet sites.
Both Android[1] and iOS[2] have both recently gained support for acting as WebAuthn authenticators, supporting authenticating on other devices (Chrome/Safari on desktop gives you a QR code to scan, then the devices communicate via Bluetooth to use the phone as a WebAuthn authenticator). The keys also sync via your Apple ID/Google account. Should go someway towards making WebAuthn a viable replacement to TOTP for people who need to sign in across multiple devices and don't want to buy a hardware authenticator, though more widespread support is necessary I think.
[1]: https://developers.google.com/identity/passkeys/use-cases#si...
[2]: https://support.apple.com/en-gb/guide/iphone/iphf538ea8d0/io...
[1]: https://developers.google.com/identity/passkeys/use-cases#si...
[2]: https://support.apple.com/en-gb/guide/iphone/iphf538ea8d0/io...
Sounds awful. I don't want Google or Apple owning my 2FA keys.
Sure, don't then. But other people are insistent that they can't tolerate the inconvenience of needing to own more than one authenticator, and yet they also can't tolerate the risk of losing an authenticator, so this is how they can square that circle.
My point was more that WebAuthn is starting to become a more viable option for the average person, with phone based authenticators that can be used to authenticate on multiple devices and keeps your keys backed up. I wouldn't use Google sync for WebAuthn myself either.
If you can't properly backup your FIDO credentials the practical security for vast majority of individuals is much, much worse than TOTP. It is extremely inconvenient and the risk of locking yourself out is truly massive.
Does Solo Keys enable that?
Generate whatever you need on your PC and then load it into as many keys you feel like.
Does Solo Keys enable that?
Generate whatever you need on your PC and then load it into as many keys you feel like.
Thats the point of passkeys. They can be backed up and sync'ed between devices.
But even if you don't want to use the popular passkey implementations, you can still easily register multiple authenticators which mitigates the risk of losing one. On a new site, I'll register my hardware FIDO key, my phone as a passkey, and my laptop authenticator (either touch-id on MacOS or tpm-fido on linux machines).
Soon there will be other passkey implementations that will also support syncing and backups (1password for example is working on this).
Don't settle for a phishable authentication method.
But even if you don't want to use the popular passkey implementations, you can still easily register multiple authenticators which mitigates the risk of losing one. On a new site, I'll register my hardware FIDO key, my phone as a passkey, and my laptop authenticator (either touch-id on MacOS or tpm-fido on linux machines).
Soon there will be other passkey implementations that will also support syncing and backups (1password for example is working on this).
Don't settle for a phishable authentication method.
Until a satisfactory implementation exist I'll take the phising alternative every day of the week.
We'll see how it plays out but I'm not optimistic this is going to end well.
We'll see how it plays out but I'm not optimistic this is going to end well.
> We'll see how it plays out but I'm not optimistic this is going to end well.
Why? Its all open standards. There are already a number of independent implementations in the works.
Why? Its all open standards. There are already a number of independent implementations in the works.
I bought two keys, keep one at home and one on my keyring. If my house burns down AND I lose my keys, there's account recovery codes that they have you note down - those I keep offline in geographically separate areas.
>You can build one yourself
Not necessarily, FIDO supports attestation.
Not necessarily, FIDO supports attestation.
Some people insist on having attestation, and presumably if we said "No" they would build their own authentication standard with blackjack and hookers (and attestation).
I don't see it myself, but they really want it, and in niche environments it's not crazy. If you issue all 5000 employees with Fictional Corp. very secure fingerprint authenticators, checking for the Fictional Corp. attestation means you can be sure nobody used their factory default Solo Hacker Key FIDO device and then pasted the resulting values into a GitHub Gist. Would anybody really do that? Well, maybe, after all there were various SecurID tokens facing public webcams so that their owners could use the OTP from the token without risk of losing it...
However, on the public web no relying party (~ web site) should use this, especially one which offers some other unattested alternatives; and you as user shouldn't allow attestation if attempted -- at least Firefox and I believe Chrome let you say "No" and you should.
I don't see it myself, but they really want it, and in niche environments it's not crazy. If you issue all 5000 employees with Fictional Corp. very secure fingerprint authenticators, checking for the Fictional Corp. attestation means you can be sure nobody used their factory default Solo Hacker Key FIDO device and then pasted the resulting values into a GitHub Gist. Would anybody really do that? Well, maybe, after all there were various SecurID tokens facing public webcams so that their owners could use the OTP from the token without risk of losing it...
However, on the public web no relying party (~ web site) should use this, especially one which offers some other unattested alternatives; and you as user shouldn't allow attestation if attempted -- at least Firefox and I believe Chrome let you say "No" and you should.
I built one myself. I've yet to find a site that doesn't support it. I'm sure there are some out there, but in practice attestation isn't a big problem.
...yet. And by the time it is, it'll be too late.
Except the industry is moving away from attestation. The popular passkey implementations don't support it. You won't see attestation use outside of enterprise specific settings.
> As someone who is rather distrustful of the real motives of the security in general
Do you mind elaborating on that?
Do you mind elaborating on that?
So far I haven't seen a single major company doing phone based (insecure) 2fa not use the number for marketing, data abuse, etc.
Non-standards based "authenticator" dedicated apps phone home and spy on you. Intentionally trying to break or block actual TOTP.
Non-standards based "authenticator" dedicated apps phone home and spy on you. Intentionally trying to break or block actual TOTP.
TOTP without a real time clock is ambitious :)
(author) The CIA TOD clock is okay for this. It uses wall mains voltage, so it's about as accurate as your average office clock. You can use a CMD-compatible device to seed the time; I'll be adding Ultimate-II+ support as soon as it's off backorder.
>about as accurate as your average office clock
That's underselling it, mains frequency is deliberately controlled to keep average frequency very accurately in long-term periods.
That's underselling it, mains frequency is deliberately controlled to keep average frequency very accurately in long-term periods.
Right, but this uses a 30-second period, which could be affected by smaller variations. In this case the use of the TOD is unavoidable because if I used the Timer A interrupt (50Hz or 60Hz depending on video standard), it would be slowed when interrupts were disabled for doing BCD calculations - the C64's IRQ routine at $ea31 can't handle the situation if an IRQ occurs while decimal mode is on. This is a known Kernal bug. I suppose I could hack around that but this was simpler.
Do you need to configure the Hz? Otherwise it'll run faster in the USA va Europe.
(author) Yes, it accounts for 50Hz vs 60Hz, see https://github.com/classilla/totp-c64/blob/main/totp.xa#L129 . Basically it uses the other CIA as a cycle counter to see how many cycles elapse between TOD ticks, and then adjusts accordingly (from https://codebase64.org/doku.php?id=base:efficient_tod_initia... ).
See here: http://codebase64.org/doku.php?id=base:initialize_tod_clock_...
I don’t understand it completely, so would appreciate an explanation.
I don’t understand it completely, so would appreciate an explanation.
The 8-Bit Guy just did a video about the SX-64 yesterday: https://www.youtube.com/watch?v=i4gHaXOevVM
It's a cool little box, unfortunately hobbled by a terrible screen, interesting timing on seeing this here today.
It's a cool little box, unfortunately hobbled by a terrible screen, interesting timing on seeing this here today.
I see the clock code accounts for leap years - but what about leap seconds?
Of course, most TOTP systems allow for a little clock drift, so being out by a few seconds should be fine.
What a delightful hack. It makes me want to drag my BBC Micro out of the loft to try something similar!
Of course, most TOTP systems allow for a little clock drift, so being out by a few seconds should be fine.
What a delightful hack. It makes me want to drag my BBC Micro out of the loft to try something similar!
30s is the default interval for TOTP, and most seem to allow +/- several intervals, so around a minute or two of drift is still OK.
(author) Sadly, no leap second support currently. A future adjustment ;)
Man, you are my hero
If there was any anxiety in the 8-bit era it came from disk-born viruses (although in the C-64 era I don't recall even that as a worry). No log-in, no passwords, no cookies, no spyware. (I suppose the BBS introduced most of us to passwords for the first time?)
C-64 + 2FA feels sort of ... blasphemous? Besmirching?
C-64 + 2FA feels sort of ... blasphemous? Besmirching?
But does it play a cute little 8-bit sound bite each time you use it? (Like, Mario catching a coin)
I used Nokia 6300 J2ME for TOTP generation around 2017. Less likely to get a zero-day there. Or rather more likely but less likely that someone would want.
I find it funny how the internet went straight into the cryptic(to understand for normies) nature of 2fa based on SIM card, when it might had been simpler (and possibly more secure in practice), to just go with key files at first.
Everyone already knows what SMS are, there's nothing cryptic about it on the user side. Also SIM cards don't need a backup.