I've been using U2F where possible for about a year, and I have a secondary Yubikey registered everywhere I have the primary registered.
I am going to be switching to a USB-C one soon, though, and it only now occurred to me that I haven't really been keeping a "list" of all the sites where I've got them registered. Right now, not a lot of sites support it so it won't be too tough to find them. But I should probably be keeping a list so I at least can be sure when I've definitely replaced registered the new Yubikey in all places the old one was registered.
That doesn't really address your question as to what happens when you lose your keys, but it's perhaps relevant that there are a few warts around replacing even keys you haven't lost.
My prior car was new and I later decided that the added expense of a new car did not justify it. My plan was to get a few-years old "A to B" used car (like a Corolla or something) when it started needing work.
But I did change my mind and get a Model 3.
* Autopilot is quite nice. I'd compare the experience to driving a car with cruise control as compared to one that doesn't have it. It's not the end of the world, but if you have a car with cruise control, it's tough to imagine intentionally buying your next one without it barring financial difficulties.
* Not having to fill up at gas stations is nice. There's a little more planning involved for trips, but for normal day-to-day, it's waking up every day to a full tank.
* Upcoming software updates. The initial Model 3s didn't have summon or the dashcam feature, both of which have been added over the air, and more of which will be added sooner.
* I think the auto industry in general has become stagnant and "safe" in terms of innovation, and I want to support a disruptive entity that will force the others to re-think the ways they're doing business.
* It's got an API, which already has third party tools for an Apple Watch app, detailed analytics, etc.
* They're taking a risk with the interior of the car, with the lack of gauge cluster and spartan design. To me this looks like what happened when the software industry switched from "as many UI buttons and features as possible" in the '90s to the simplified, "overall user experience" focus we see in modern software. And I want to support that.
* There's some "feel-good" factor to damaging the environment less, and supporting the market that will allow for society to join in.
I agree with you in that I can't imagine spending $63k on a non-Tesla. The differences between a basic used car and a new Mercedes or something just don't justify it. But I do feel differently about the Tesla.
> * They're taking a risk with the interior of the car, with the lack of gauge cluster and spartan design. To me this looks like what happened when the software industry switched from "as many UI buttons and features as possible" in the '90s to the simplified, "overall user experience" focus we see in modern software. And I want to support that.
I guess this is fine if you live in California, but a car that I can't operate while wearing heavy mittens is literally unusable to me for nearly half the year.
The car doesn't require touching the screen to operate it.
The nav / media controls do, but those can be voice operated, too. And a lot of the media controls work from the steering wheel knobs (play pause skip back etc.), also.
EDIT: And all Teslas can have their climate control turned on remotely by the app / API, and can be safely warmed up even in an enclosed space (since there are no fumes).
I don't really consider requiring a touchscreen (be it in car, or on phone) for climate controls to be an acceptable replacement for a couple simple mechanical buttons and knobs. In the best case, it's less convenient, and it adds many additional failure cases.
The climate system has fewer moving parts than a typical climate control system, so if anything, it is removing failure cases. It is unique—there are videos on YouTube that describe how it works if you’re doubtful.
In practice, I rarely adjust the climate setting after setting it to the temperature / orientation I want, but I suppose everyone is different.
To me it feels a lot like when many used to claim they could never get an iPhone because they prefer a physical keyboard. But I suppose we’ll see how the industry responds over the next few years.
Yeah, it removes the mechanical failure cases, but I've never had that happen with any of my vehicles. OTOH, I'm pretty regularly in situations where I'm parked in cold temperatures without having cell coverage in a warm location where I can wait for the car to warm up. (And normally, I don't need to "wait" for the car to warm up, I turn car on, set blower to max defrost, clear snow/ice from windshield, and go. Once/if the windshield is clear, I turn blower down for some quiet, and turn off compressor to save on fuel/range, as appropriate.)
Hooking that all up to voice operation sounds fine though (though preferably customizable, so I could have a single command to say, turn on seat warmers, turn blower to max, set output to windshield) - I never use voice operation for my phone because it's obnoxious to so in public, but that's not a problem if I'm in my car.
Thanks for posting. This is a serious issue that is difficult to discuss openly and your perspective (particularly the part about a poor woman from a bad neighborhood's changing expectations) is something I hadn't seen or thought of before, but absolutely makes sense.
I have a Ledger Nano S that I use for cryptocurrency and it does basically this. It won't sign transactions unless you approve them from the device, and the little screen on the device shows the address(es) to which you're sending.
It's $100, which is probably too much for your average user, but cheap enough that it's got to be feasible for a U2F kind of thing in a few years.
I guess even the addition of the screen, though, kind of necessitates using a cord so you can see that screen, which makes it less clean than my Yubikey Nano (which is far less obtrusive). But I think we're getting closer.
Thanks. Yes, this is something what I think of. Does it show on the screen what operation you confirm with U2F? Or just "U2F authentication"? But cord makes it far less convenient unfortunately.
I use it for gpg, ssh(gpg-agent) and u2f. These are official applications that you can install on the device that does the above. It doesn't show the operation, just the website trying to access.
I'm not sure if it supports U2F. If it does, I haven't used it. It just seems to prove that what you were conceptually describing can exist, and at a not-completely-unreasonable price point.
> I've seen this called Function as a Service and honestly I think using that term instead of Serverless would go a long way to fixing this issue
But "Functions as a Service" doesn't cover what it is, though.
The following AWS services are "serverless" but would not be "function as a service:"
* S3
* API Gateway
* SQS
* SNS
* Cognito
* DynamoDB
* CloudWatch (logs and metrics)
* Step Functions
In all cases, you are not provisioning or managing servers. Scaling is linear and costs are linear based on how much you use them, and typically based on what's actually being used (bytes stored, requests made, etc.) and not per-node. Because they're all hugely multi-tenant, they also cost almost nothing to use at low scale.
"Functions as a service" covers serverless compute, but it doesn't cover the huge architectural difference (from the developer's perspective) between the services above and rolling your own (for example) S3.
If we're qualifying anything on a server that developers don't have to manage themselves as serverless than anything with an API becomes serverless...despite all of them actually running on servers.
OK. I guess to me categorizing those things in the same bucket as EC2 or Salesforce is missing a pretty fundamental architectural difference and benefit. I'm not claiming "serverless" is an ideal term, but I haven't seen the case made for anything better.
The distinction I've heard and make (regardless of serverless being the right term) is that these infrastructure services expose their control plane and data plane without tying you to the concept of a particular machine. Compare this to all publicly available forms of RDS where I still have to think in terms of machines for scaling and management.
OpenVPN traffic over TCP 443 will still be distinguishable as OpenVPN traffic, it's just a little harder.
Normal TLS handshakes over TCP typically look very similar, so if OpenVPN did those, it would be tough. But OpenVPN's TCP mode is basically just a TCP encapsulation of the UDP mode messages, and even with the new tls-crypt option enabled, the packets still contain unencrypted parts that could easily identify them as OpenVPN traffic.
As far as I can tell, if you're looking for your TCP port 443 traffic to look just like normal web traffic, you'll need to use a different protocol.
Apple has been requiring all apps on the App Store work on IPv6-only networks for two years now [1]. They require it work on a network with NAT64 and DNS64 set up.
Essentially your device gets only an IPv6 address and the router translates IPv4 addresses to IPv6 ones. Your DNS server does the same thing. The end result is that your device talks only native IPv6, but the router is translating back and forth as necessary for IPv4.
It's actually pretty easy to test if you have an extra Mac laying around. There's a hidden checkbox on the Network preferences pane that lets any Mac create a NAT64 / DNS64 WiFi network [2].
Using the secure enclave, you (as a developer) can have it generate a private key you'll never be able to get and then ask it to sign / encrypt (symmetrically) arbitrary things for you.
Given that TOTP (one of the more common phone OTP methods, used by Google Authenticator) uses a symmetric key, it seems unlikely it’s being stored in the Secure Enclave
It may just require an extra step. My understanding of TOTP is that it's the key data (typically a string represented by a QR code) and a time offset that is used to generate the OTP. If the only thing stored on disk is the code encrypted by the secure enclave's key, and the only way the decrypted code is in memory at runtime is if it's decrypted by the secure enclave's key, then that still offers protection against some attack vectors.
You (as an attacker) could then recover the key if you had full control of the OS and could trick the user into authenticating so the secure enclave decrypts the key, but would presumably have more trouble if you (as as attacker) simply stole the device.
You as an attacker would arguably have just as much trouble simply unlocking the device, you'd be left with the same amount of protection approximately. As long as you have disk encryption, the security margin would be about the same. A marginal improvement at best.
>AFAIK that means it'll take more than a jailbreak to get to them, although I don't know if OTP apps are using that capability or not.
sure, you wouldn't be able to extract the keys, but what's preventing you from generating thousands of codes and extracting those instead? since they're time based, you could easily generate lots of them for a long time into the future (eg. 10 per day for the next 5 years). that should afford you plenty of opportunities to do a login attempt.
This can't be used directly for generating OTP tokens (see the other comments), but what would stop you with a normal key on the secure enclave is that you can require the enclave itself requires a higher level of authentication (facial scan match, fingerprint scan) to perform those key operations.
Yes, that's great for asymmetric stuff, but we're talking about TOTP, which uses a fixed symmetric key and a hashing algorithm. Unless you can run arbitrary code on the secure element, like you can with Intel and Qualcomm stuff it can't be done and even if it can be, it'd be a significant effort investment for what's probably a negligible secure it gain in practice. Still, I'd be pretty impressed if any apps did so.
You're seeing Cognito User Pool pricing. Cognito User Pools is basically having AWS host your user / password / details database for an app you're building. It takes care of some details like verifying e-mail addresses / phone numbers and integrates with Cogito Federated Identities, which makes it easy for your app to (for example) allow login via Google, Facebook, or an account they create (which is stored in that user pool).
This Google service looks more comparable to Okta or auth0. That is like if you're a sysadmin at a big company and you want one place where your users can be authenticated, which can then allow access to all of the web apps you use (Dropbox, Salesforce, Gmail, etc.).
EDIT: And to tie them together a little:
If you were building a web app using Cognito, you could likely add a federated identity via Okta, auth0, or this Google service, which would then allow your users to log in directly to your service through that without having to create / manage an account separately.
I am going to be switching to a USB-C one soon, though, and it only now occurred to me that I haven't really been keeping a "list" of all the sites where I've got them registered. Right now, not a lot of sites support it so it won't be too tough to find them. But I should probably be keeping a list so I at least can be sure when I've definitely replaced registered the new Yubikey in all places the old one was registered.
That doesn't really address your question as to what happens when you lose your keys, but it's perhaps relevant that there are a few warts around replacing even keys you haven't lost.