The NREL inertia video explainer felt a little like it was begging the question - "inertia protects the grid because it has inertia and keeps spinning" - it doesn't quite feel like it explains where the extra energy comes from or goes, just that the mass keeps spinning. (I also haven't had a physics class in a long long time so some of this is not obvious to me, except that I understand from just common sense that if something's spinning you had to put a bunch of energy into getting it going in the first place and it's going to keep going if left on its own)
Anyway, I was hoping someone could fill in some details for me. Imagine a simplified grid: a dam that sends water through a penstock past a turbine/generator and into an electrical circuit, and a couple of resistance heaters on the other side of the circuit. The energy comes from water flowing through the dam - the dam operator opens up the sluice gate to let water flow through, the generator extracts the mechanical energy and turns it into electrical energy and it goes down the wire to the resistance heater where it gets turned into heat energy. Everything is balanced - the right amount of water is flowing through the dam to turn the turbine at the right speed to balance out all of the energy flowing through the wires and into the resistance heaters (and lost along the way, like losses in the transmission lines, etc). In this setup, there's some measure of pressure that turbine pushes back against the water flowing through the penstock of the dam, which is balanced out by how much pressure is coming from the water behind the dam and the pressure being put on the surface area of the penstock in the dam and the pressure being relieved by the water leaving the dam.
I get that thanks to inertia, if the sluice gate accidentally slams shut and all water stops flowing through the dam, the turbine is going to keep spinning for a bit and energy is going to keep going out onto the grid, though it will start to slow down due to friction at the turbine and energy being extracted from the system by the resistance heaters on the other end of the grid.
What I'm less clear about is how does inertia help when the water keeps flowing at the regular speed but when demand drops from the grid load. Let's say one of the resistance heaters turns off in a home somewhere - what happens to the energy from the water that was previously flowing into the grid via the turbine? Does the inertia in the spinning of the turbine somehow push back against the water flowing the dam, slowing the water down a bit/building pressure up in the penstock and behind the dam - with that pressure buildup being exactly equal to the energy that used to be going into the resistance heater? And that pressure either stays built up from the turbine until someone lowers the sluice gate a bit to cut back on the waterflow through the dam? Or does nothing involving inertia happen here - if the resistance heater gets turned off the overall load is reduced and the turbine spins a bit faster because there's less pushing back on it, and the water can move through the dam a bit faster, and the turbine just spins faster until someone notices it's going a bit too fast and the gate needs to be lowered so it drops back to rotating at 60hz?
Similarly, if someone turns on another resistance heater and now more energy is needed on the grid, but the sluice gate isn't opened up immediately, is inertia involved here somehow? If the turbine has to push harder on the grid side because of extra load, presumably the turbine slows down? Or does the turbine get pulled along by the new load somehow (more inertia?), and so more water can push past the turbine, giving it the extra energy it needs (and presumably dropping the water pressure in the penstock in the dam? And the pressure stays low until the sluice gate is opened up a bit more and more water can flow through the dam?)
I am using water pressure from a dam here, but I assume this would be equally true in a gas plant generating steam - if more energy is needed, the pressure in the steam drops until someone turns up the burner and creates more steam, etc, or if less steam is needed the pressure just builds up until someone notices and turns down the burner?
If anyone can explain how inertia and the grid translates into changes in the actual source of energy, I'd much appreciate it!
I think the very simplified idea is that inertia slows down how rapidly the generators slow down respectively speed up in response to load changes, thereby giving you a better chance of adjusting power generation to match the new load.
If your ratio of inertia to power demand variability is too low, then any sudden change in power demand will lead to your generator rapidly spinning up/slowing down before (in the case of your imagined dam) you have any chance of de-/increasing the water supply to the turbines as required. If it slows down or speeds up too much, then whoops you're hitting the grid frequency limits, power trips, and you've got a blackout.
If it spins up too much and too rapidly it might even exceed the mechanical limits of the generator, though normally real-life systems should of course always be designed to be capable of safely handling even a complete load trip, because there's always the possibility of a tree suddenly falling onto a power line or whatnot…
With sufficient inertia on the other hand, any mismatch between power generation and power demand now only manifests itself as your generators gradually starting to spin faster/slower, giving you enough time to adjust the water supply valves as required.
For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token?
(I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key)
EDIT: My ideal setup, I think, is an app on my phone that I can use as my token - somehow signaling to my desktop/laptop that it's nearby and can be used as a token and ideally popping up a notice on the phone lock screen when there's an authentication request so I can quickly get to it. Then in my app, I'm free to export and backup my keys for all of the sites I'm enrolled with as I see fit. I know, I know, maybe being able to export the keys makes the setup less secure, but I will trust myself not to accidentally give the backup to a phishing site. (And I do worry that I'll accidentally get phished using a TOTP app, so I'd like to switch to FIDO, but I don't want the pain of multiple keys)
I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.
Storing your keys in secure hardware on a phone is almost certainly more secure than storing a key in software on your desktop hard drive.
If you don't trust your hardware, it's almost always game over. Desktops have devices running dubious firwmare as well, but at least with a hardware key store, the window of compromise ends at the time you update – a stolen key stays stolen forever.
For me the biggest anti-phone argument is that they break and that is very common. They also run out of power. Hardware keys offload this to something that can go through the washing machine or ride in monsoon rains on my motorbike's keychain.
This is an urban legend. It ticks all the boxes of people who are inclined to be paranoid about these sort of things (I realize saying that may come across as a value judgment: it isn't), so it remains a popular meme. But the "baseband controls the main phone" is a meme that was maybe true for mid 00s dumbphones but not modern smartphones.
That's not to say that you should trust modern smartphones. That's up to you. It's just that in whatever "trust" means to you, the baseband urban legend shouldn't come into the equation.
While I can't find the reference, I remember reading about how Apple set up their connection to the modem in a very particular way to where it has its own co-processor for any code it needs to run, and the bridge between it and the main SOC is just IO for rpc and network access.
Well, the baseband always was its own processor - that's why it's a separate thing called a baseband. What you're thinking of is an IOMMU, it's like a firewall that prevents coprocessors from reading all of RAM.
If there are vulnerabilities on the AP (main processor) then you can hack it from the baseband, but also from the bluetooth or WiFi chips.
Your phone is a whole lot more secure than your PC. It has to be, because you carry it around with you all day and it's easier to steal, so it has to be resistant to a lot more things.
Caveat emptor on cheaper/older phones or ones you enabled developer modes on.
Yes, either the Browser or the OS will need to be involved. For example, for Webauthn on Chrome on Windows: chrome receives the request, then it calls the Windows Hello APIs. Then, that Windows Hello API shows a popup to read a physical security key or authenticate a virtual security key via face/PIN (this is protected by a TPM, but it's "virtual" since Windows generates it via the TPM but stores it encrypted on-disk).
To support a syncing fido keyvault, Chrome could very well redirect the calls to its own popup for choosing to 'use Chrome', or 'use another key', which would then call the Windows Hello API. In fact, Chrome already supports this[0], with 'Add a new Android phone' is simply how they're presenting Webauthn over BLE, and it works with iOS when passkeys are enabled in the iOS developer menu[1].
I don't trust Google or Apple to be my main authentication provider, or to manage syncing my private key. Their customer service is terrible and they are way too arbitrary on locking folks out.
I would trust my bank (well, my credit union.) I can go see them in person if I need to and they take my lawyer seriously, they also take security seriously, they're properly regulated, and ultimately they're my main concern if someone stole my credentials, so I'd like them to be on the hook for protecting my credentials.
This announcement isn't about that and neither provider is asking to sync your private key. In fact the opposite is true: with FIDO2, you're in much greater control of your account security because authentication creds are now on a hardware token versus as bearer credentials you type and an adversary can steal and replay. Many of us believe we're very good at protecting our passwords, but this isn't true in reality and FIDO2/U2F standards objectively make accounts more secure precisely because they remove humans from the equation.
> neither provider is asking to sync your private key.
Yes, they are. According to the white paper linked in the press release:
Just like password managers do with passwords, the underlying OS platform will “sync” the cryptographic keys that belong to a FIDO credential from device to device.
Except it kind of is - the way I read this is "Apple/Google will turn your phone into a hardware FIDO token, but will use iCloud/whatever to reduce the huge painpoint of having more than one hardware token and keeping them all in sync"
I really love the idea of FIDO and making sure that my authenticator only authenticates to sites that I've approved, but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
This is a net benefit over synced passwords, which everyone already trusts them to do. You haven't been forced to use a (syncing) password manager over a physical password book in the past, and you won't be forced to use Passkeys[0] or the Android equivalent in the future; hardware security keys will still be usable since this announcement is about embracing the FIDO Standard.
Your average user is more concerned about losing their password than they are about authenticator sovereignty. Moving towards cryptographic primitives for auth versus shared secrets is a net benefit versus current state.
> but having multiple keys right now is a huge pain, but I'm not excited about "just sign up for Apple and that pain goes away" because I sure as hell don't trust Apple not to cause me pain in the future.
Compromise is necessary, and probably a bit of regulation from government to enforce good outcomes from exception handling. Passkeys need to be stored and managed somehow, and your average user does not want to do that, just like they don't want to run their own mail server, syncthing instance, or mastodon instance.
EDIT: (HN throttling, can't reply) @signal11 You can already be locked out of all of those accounts without recourse.
> Your average user is more concerned about losing their password than they are about authenticator sovereignty
Right up to the point when they’re locked out from their Google, iCloud or Facebook accounts with little recourse or appeal. And then they discover it’s not just Google, a whole host of other services don’t work.
And it does happen, and I for one don’t want to wait for legislation to mitigate this blatant attempt at yet more centralisation.
Many authenticator apps allow you to extract and back up the private key yourself, with no involvement of any 3rd party. But it's a totally optional workflow and you're never asked for that private key while authenticating, so the mass phishing and spear-phishing attacks seen with passwords are still infeasible.
This announcement is partially about the platform-integrated authenticators being made into 'virtual' authenticators backed by a platform vendor-specific cloud ecosystem. So for example, a credential registered on an iPhone may be synchronized over iCloud Keychain to work to log in my Mac via TouchID.
This is something which has always been as part of the model - an authenticator is just an abstract thing that represents an authentication factor, generates keys for a particular use, and doesn't share private keys outside its boundaries.
This announcement possibly marks a transition where sites supporting Web Authentication (with a bring-your-own-authenticator model) will go from seeing 90%+ hardware-bound authenticators to seeing 90%+ platform-integrated, synchronizing authenticators. Bundled into that prediction is a hope that this (and other proposed changes) will lead to a 10x increase in adoption.
Not at all, because before anybody could take your account away from you if you did not accurately compare two visual strings, potentially in Unicode.
By replacing that operation, which humans can not perform reliably, with computer operations, users are no longer subject to others taking control of their account.
Let me add my recent experience in the bucket. Few days ago I upgraded my legacy Workspace account to a business account. (I was in a time crunch; couldn't evaluate alternatives.) I enter my debit card details in the checkout and got a generic error message asking me to "try again later." Thought there was something wrong with their service and tried the next day. Same error. After some 15 minutes of searching forums, turns out debit card is not supported in my country on account of SMS based TOTP, which doesn't work for subscription services. (If they could mention it in the haystack of their help pages, why can't they say that right when I signup?)
Anyway, more searching led to an alternative. There's an option to request invoiced billing where I would get a monthly bill & pay - debit card works here. Clicking that option took me to form. Filled it, got a call from a sales guy few hours later. Sadly, he had no clue about my problem, despite being from my country. On top of that he told me he's from a different team and don't deal with sales queries (WTF. Then why did he call me?). Told me he'd email me some options and, at that point I wasn't hopeful. Thought he would send me some stuff I had already seen on their forums. On seeing the said email, my disappointment sank even lower. The generic mail had absolutely nothing to do with my issue and the help urls were totally unrelated.
I just ended up using my friend's credit card to complete the transaction. I'm seriously considering moving elsewhere.
Is product management this pathetic at Google? I'm sure if you went for a PM interview they'd judge you nine ways to Sunday. For what? Everything Google does seems like it's built by three robots in a trench coat collaborating unsuccessfully with other robots in trench coats.
I recently moved my family's legacy GSuite service over to Fastmail, and it seems like they've carefully planned for this exact scenario. Account setup on each device is as simple as downloading a configuration profile with a QR code. And Fastmail has a built-in option to authenticate to your old Google account and pull all your mail over to the new account, preserving all the details, and then keep sync'ing until you're ready to turn the old account off. I thought I was going to have to sync things myself. Nope! Took all of five minutes to set up my account and sync. Couple weeks later I deactivated the old GSuite accounts.
And now I'm a customer again, which feels good, even though it means spending actual money.
There is no comparison between Google and Apple customer support, and they should not be mentioned in the same sentence. Google support is nonexistent. With Apple, I can chat online or get in person support. They are more like a bank.
Despite what most people think, banks are often a really long way behind on security. Banks don't care about security of any individual customer, merely security of the bank as a whole. That means if 0.01% of customers lose all their funds due to credential stuffing, it isn't an issue - the bank will just refund them if needed.
Unlike say ssh with key authentication, where it would be a total failure if 0.01% of attackers were allowed to login without the key.
In the Netherlands the banks provide the iDIN system, so you can authenticate on more sites with the bank provided logins. Each bank has a slightly different system often using bank card and bank card readers and ways to authenticate through authorised banking app on individual mobile phones.
And besides that we have also a government provided login system which can also even work with your ID card. But mostly works with government systems and health insurance companies.
Tracking from bank or both? Anyways, in Latvia we have similar system and it is a convenient way to authenticate within services where you MUST prove you are person X.Y.Z.
For example, some electric company, if you auth via this method, will provide you with contracts, electricity usage graphics for all the sites you own and and other info you must access as a customer. Same goes for recycling company. These usually provide a way to register using email matching whatever email you had in contract (thus linking to real person anyway)
And then for other services where you request some data electronically that they must "register" each request. For example request some extended data on land/house ownership. You can't have that with non-real-life identifiable entity.
So usually login via bank is an login option with companies you either have juridical relationships or you must provide real life identity where you would otherwise have to show passport in real life.
We have GDPR and consumer focused regulators in the EU. Our governments are actually out to protect citizens from corporate malfeasances, as opposed to either ignoring it, or out right enabling it.
If a company abuses this data, you have strong forms of recourse available to you as a citizen, and banks are incentivised to remove bad actors, to ensure they don't become embroiled in enforcement action triggered by a 3rd party.
I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security - I'm not protecting nuclear weapons, my threat model is not state actors trying to attack me, my threat model is me leaving my key in my pants pocket before putting it in the washing machine.
I wanted to enable YubiKey for my Bitwarden account and feared exactly this. Now I've spent 200€ for 4 YubiKeys, so if I ever miss or break one, I will hopefully be fine. But imagine telling your grandma to buy at least 2 YubiKeys for 100€ just to make your Facebook login more secure.
I was about to say the same thing. These things are quite sturdy and if you loose your key (as people do) you retire the old one and make a new. These things are neither expensive nor irreplaceable. Of course if you loose your key it's going to hurt, as it should.
I've had a Yubi Key for almost 5 years now. Zero issues.
Has anyone tried a Ledger or Trezor device for something like this? Your FIDO U2F private key is deterministically generated [0] based upon your seed phrase, which you can backup, and restore on other devices.
At least Ledger actually does support U2F as an installable application, but that's the predecessor to FIDO and has some weaknesses in comparison. I'm also not sure whether WebAuthN supports legacy U2F authenticators without the browser performing some protocol translation.
I have a Ledger as a backup key. Keyword is backup since it's less convenient to use than a Yubikey due to needing to put in a pincode first. Though that could be a security feature in and of itself.
What do you mean by a honeypot? Both are pretty well trusted devices, and users easily have tens of billions of dollars deposited on them. Given that, I feel pretty comfortable using them for 2fa.
That's exactly why FIDO [1] and WebAuthN [2] are moving towards a concept of backup-able/cross-device-sync-able authenticators.
That is arguably less secure in some contexts, but there are workarounds, and I do see the point that for most services, availability/key loss recovery is as much of a concern as is security.
Right. Some core services get this treatment, like email and important online accounts. For others I rely on reset mechanisms tied to those email accounts if I lose the primary key and haven't had the chance to register the secondary. Every few months I'll sync up anything that has been missed.
It's not perfect, but it's a hell of a lot better than TOTP.
This. For a while I tried to keep a list of accounts I needed to add my offsite key to, and then every year or so I'd retrieve the key, and add in bulk, but that became way too complicated.
While not ideal, I'd be happy if I could register with the public key of my offsite key or something similar. Really I think there should be a way to register a public persona, and add / remove keys from that persona at will.
Or, just let me (somehow) generate multiple hardware devices with a shared seed.
People have made the same incorrect assumption that fido can't be backed up many times and it is a common misconception that halts adoption of the best security win since TLS. I feel important to correct this in tech circles so we start telling friends and family to setup a solution to the most common account loss problems.
Also, BIP39, the only backup spec that exists for FIDO atm, originated in the Bitcoin community where key loss is a very expensive problem that needed an elegant solution.
BIP39 can be used to backup any type of asymmetric cryptographic key that could ever exist in a human friendly way but sadly I am not aware of any vendors implementing it outside of hardware wallets which are general purpose tools
They can be used for PGP and FIDO and password management without using them for cryptocurrency and this is totally valid.
I absolutely agree that this is a thing that needs to be solved. I cobbled together my own solution using undocumented bits of the Solo firmware[1], but that's not nearly usable enough for average users.
But here's the problem: outside of the hype bubbles, cryptocurrency stuff does not have a good reputation. If the only thing that supports this markets itself as a cryptocurrency wallet, that is going to hurt adoption. People generally do not buy devices in which they actively do not want the main feature.
(I did remind myself of DiceKeys[2] while looking through my notes to find [1], but that has its own problems, such as "oh god what are you doing why does this involve OCRing a photograph of dice on my phone".)
This problem is already well solved and deployed to millions of people. That it is my point.
To your dicekeys example, a much better solution, IMO is using bip39-diceware which allows you to roll for 256 bits of entropy in the form of 24 BIP39 words with dice, using only a paper worksheet. You can use these with a KDF to determinstically generate any type of key material be it for PGP, FIDO2, mutual TLS, or whatever you like.
BIP39 is a general purpose innovation in human friendly cryptography, and so are the general purpose personal HSM devices that support it.
I don't feel it is productive to balk at a generally useful technology just because one dislikes the biggest audience creating demand for it.
Someone can have a religious objection to porn and still enjoy the bandwidth growth and other improvements to the internet that porn demand helped create.
Just because a toaster is marketed for toast, does not mean you can't enjoy it for pop tarts. Just because a pressure cooker has a "chicken" button, dosen't make it any less useful to a vegan.
The examples are endless.
Those that are fundamentally against experiments in decentalizated governance should at least try to appreciate that space presents high stakes security problems that engineers will innovate to solve.
Many of the best cryptographers in the world, like Dan Boneh and team at Stanford, spend a huge amount of their time focusing on innovations in privacy, computational effenciency, and cryptography to meet demand created by popular decentralized systems experiments.
If anything, buy products like hardware wallets that improve security for you and recommend their teams spin up marketing and product development approaches more inclusive of customers that have moral objections to decentralized governance and value storage use cases like yourself.
Okay, so first of all, you know very well that "moral objections to decentralized governance" is not the problem people have with blockchain technology.
But beside that, perhaps I didn't quite make the point of my comment clear enough. You're trying really hard to convince me of things. I know very well how this works, and what problems it solves, and I do think it's a good solution to this problem.
The main reason I'm not going to buy one of these isn't anything about the technology; it's because I already have a solution for myself and I have no reason to bother switching to another solution.
This isn't about my opinions. I'm explaining why the general public is going to continue to ignore this otherwise valid solution. The marketing around it actively ties it to a thing that most people have negative opinions of, and makes the feature they actually want seem like an afterthought. Even here, you repeatedly refer to it as a hardware wallet, because that has always been the primary focus of those devices.
The effect of this is that the average non-blockchain-person just sees you posting a lot of comments in a tangentially related thread trying to sell them on blockchain tech. Do you see why this, from the perspective of a non-blockchain-person, is counterproductive?
You will continue to have trouble getting people to adopt these devices until either the marketing focus changes or public opinion on blockchains changes. And one of those is going to be much easier to accomplish than the other.
I am not telling you this to bash blockchains. I do have negative opinions on that space, but I don't care to debate them here; nothing would be accomplished by either of us by doing so. I am giving you advice on the way your message is perceived by others.
The services I interact with that support WebAuthn usually only allow you to register one key. Backup and recovery is a confusing puzzle for most of these services.
Tell the services you interact with that they're basically going against the spec.
"Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators."
This has been talked about in HN comments almost daily for like a week — does anyone from AWS/Amazon read this forum, or are they too busy performing blood sacrifices trying to recruit graduates?
It's actually horrible! Even key rotation is horrible!
My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic.
The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site that haven't been rotated yet.
Multiple keys on an all sites is also basically impossible. You need to register all the keys, and ideally those keys are in different places.
I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG.
Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.
I've recently started to track my service dependency graph! So like, to keep using github I need my password store, my email and one of my two security keys. To use my email, I need...
Please contact me if you're interested, I will release the tooling I have.
It would indeed be nice if you could "cross sign", CA style, a new yubikey with an old one, and that would somehow get passed along to the various services.
I have not thought about the various attack vectors that this may or may not enable though.
FIDO2 with resident SSH ed25519 keys works great, just make sure the OpenSSH client and server versions on all the machines you’ll be using the key on support it. I wish there was a way to sign Git commits somehow using them instead of PGP.
I keep an off-site backup at my parents house. Right now it includes a printed copy of my backup codes, so if my house burns down and everything is a total loss here, I at least don't have to start from zero. They live far enough away that my backup offsite backup can get to be a few months out of date but that's usually fine. (If I were to make a major change in something I'd make a special visit)
I don't want to spend a bunch of time when I visit to find that key and add it to all of my new accounts and hope I got everything - I want to make a backup of my current key right before I visit and when I visit, I just put the new backup key in the desk drawer and take the old one home with me.
I have much more backups of my workstation etc., should I now buy dozens of crypto hardware key thingies and constantly switch them around to match the backup disks?
For those who do offsite backups: Is an offsite backup possible across the Internet? Or do you have to physically drive the key to the offsite location?
When I create a new account somewhere, does that mean I have to move N backup keys out of their drawer to the workstation and register each of them on the account?
And how to even create a backup and keep it in sync?
With backup disks, it is a matter of shutting down the machine, removing one disk from the RAID1, and you have a backup (the removed disk is the backup). Or doing "dd if=..." if you don't use raid.
Is something as simple possible with those fancy crypto toys? Or is some arcane magic required to copy them?
Is this perhaps all as usual: An attempt to get more control and tracking of users, disguised as "security"?
With devices that support BIP39 backups like the Ledger or Trezor, you are backing up the random seed that generates all possible future accounts deterministically.
Backup once, setup 100 accounts, lose authentication device, restore backup to new device, regain access to all 100 accounts. Easy.
Most people have smartphones which ship with WebAuthn so they are good to go. Granted phones are like $500+ so by contrast a Yubikey is a much cheaper alternative for a secondary backup device for most people.
I want to have both, a hardware key and a password. A password alone always has to grant me access again, ideally without needing to register a machine too. Honestly I hate that this is so widespread already, I want my devices to be a non-recognizable ghosts for security purposes. An access log would be more appreciated.
I have a Yubikey and use it as a part of my passwords. But I would like to have a second master password that I only use in emergencies. Yes, it is easy to forget so make sure you don't. But a password that is rarely used is also rarely exposed to third parties.
To be honest, the most problems I see with FIDO is the lacking trust in the alliance of companies behind it but I don't know too much about the technicalities of FIDO.
Hear hear. I already have enough to worry about besides this little magical security wand failing/getting lost. I require a bullet proof method-of-last-resort mechanism in place for the inevitable day when the fob is no longer available.
I have abused and soaked every model of Yubikey. I even melted the casings off every model with acetone to lookup chip specs and Yubico responded by switching to a new unidentified glass hybrid compound no common solvents seem to impact.
In all cases the Yubikeys still worked even as bare abused PCBs. You need a blowtorch or a drill to break one.
Anyway, I was hoping someone could fill in some details for me. Imagine a simplified grid: a dam that sends water through a penstock past a turbine/generator and into an electrical circuit, and a couple of resistance heaters on the other side of the circuit. The energy comes from water flowing through the dam - the dam operator opens up the sluice gate to let water flow through, the generator extracts the mechanical energy and turns it into electrical energy and it goes down the wire to the resistance heater where it gets turned into heat energy. Everything is balanced - the right amount of water is flowing through the dam to turn the turbine at the right speed to balance out all of the energy flowing through the wires and into the resistance heaters (and lost along the way, like losses in the transmission lines, etc). In this setup, there's some measure of pressure that turbine pushes back against the water flowing through the penstock of the dam, which is balanced out by how much pressure is coming from the water behind the dam and the pressure being put on the surface area of the penstock in the dam and the pressure being relieved by the water leaving the dam.
I get that thanks to inertia, if the sluice gate accidentally slams shut and all water stops flowing through the dam, the turbine is going to keep spinning for a bit and energy is going to keep going out onto the grid, though it will start to slow down due to friction at the turbine and energy being extracted from the system by the resistance heaters on the other end of the grid.
What I'm less clear about is how does inertia help when the water keeps flowing at the regular speed but when demand drops from the grid load. Let's say one of the resistance heaters turns off in a home somewhere - what happens to the energy from the water that was previously flowing into the grid via the turbine? Does the inertia in the spinning of the turbine somehow push back against the water flowing the dam, slowing the water down a bit/building pressure up in the penstock and behind the dam - with that pressure buildup being exactly equal to the energy that used to be going into the resistance heater? And that pressure either stays built up from the turbine until someone lowers the sluice gate a bit to cut back on the waterflow through the dam? Or does nothing involving inertia happen here - if the resistance heater gets turned off the overall load is reduced and the turbine spins a bit faster because there's less pushing back on it, and the water can move through the dam a bit faster, and the turbine just spins faster until someone notices it's going a bit too fast and the gate needs to be lowered so it drops back to rotating at 60hz?
Similarly, if someone turns on another resistance heater and now more energy is needed on the grid, but the sluice gate isn't opened up immediately, is inertia involved here somehow? If the turbine has to push harder on the grid side because of extra load, presumably the turbine slows down? Or does the turbine get pulled along by the new load somehow (more inertia?), and so more water can push past the turbine, giving it the extra energy it needs (and presumably dropping the water pressure in the penstock in the dam? And the pressure stays low until the sluice gate is opened up a bit more and more water can flow through the dam?)
I am using water pressure from a dam here, but I assume this would be equally true in a gas plant generating steam - if more energy is needed, the pressure in the steam drops until someone turns up the burner and creates more steam, etc, or if less steam is needed the pressure just builds up until someone notices and turns down the burner?
If anyone can explain how inertia and the grid translates into changes in the actual source of energy, I'd much appreciate it!