Yeah, to match the dot pitch apple is designing for, the 4K monitor would have to be more like 22 inches instead of 27. We know this since the 4K iMac is a 21.5 inch screen.
For me the option key was always the one that threw everything else off..since failure to recognize it made me doubt all the others :-). One "pneumonic" that helps for the option key is that it looks a bit like a "fork in the road" (i.e. "an option"). The ^ for ctrl goes back to linux, so "logical" for folks with that background. And, cmd is used so often I just got used to it.
The verified device flow isn’t meant to be as strong as 2FA, but is a very strong mitigation against mass credential stuffing attacks for all users.
In terms of client certs, see my response in https://news.ycombinator.com/item?id=22849985. I agree client certs would be great. However, it can be tricky to couple your app logic with transport based security. A good example of this...chrome/google introduced a crazy cool concept called “channel bound cookies” - http://www.browserauth.net/channel-bound-cookies, but it never gained any traction because of the complexity noted.
One issue with HTTPS client cert auth is that it can be non-trivial to support at the application level when you have a multi-tier architecture where TLS termination happens at the edge of your infrastructure.
What isn’t stated in that post is that we are sending monthly email notifications to any user found using password authentication during the deprecation. As a result, we expect the vast majority of users will have been notified several times before the brownout. The brownout is mostly aimed at unearthing any forgotten automations that will break when we disable support for password authentication permanently.
GitHub Actions tokens are actually based off our newer “GitHub apps” system and not “OAuth apps”. GitHub app tokens support much more granular controls (both in terms of abilities and resources). OAuth doesn’t lend itself to super granular controls since they are scope based (ex. Defining a scope per repository doesn’t really scale). This whole area is something we want to address with personal access tokens in the future.
It’s not at all about the security of delivering credentials over https, but more about the the complexity of trying to defend against weak passwords/credential stuffing with an api. For example, it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices to an api.
My experience with password managers is that they work great for me, because I understand every sharp edge and can work around them. My experience when advising family to use them is that they invariably fail them and they get frustrated. Password managers rely on pretty gross heuristics to work. They are effectively trying to automate something built for a human (choosing, remembering, and entering a password). WebAuthn gives us a real API built by and for machines. This will make the flow much less error-prone and more secure.
100% true. I personally wish the hardware-focused U2F bit didn't predate the WebAuthn spec. I feel, because of that, way too much focus is placed on the "hardware security" bit. I view the main benefit as replacing user selected weak passwords with a non-phishable, non-server-side loggable, non-server-side sensitive secret needed authentication standard that can be implemented entirely by code, largely without user involvement, and that doesn't rely on gross failure-prone heuristics the way password managers do today. Oh, and it is all a better user experience too. It is one of those crazy wins that you just don't get in the security space that often. I really don't care if that takes the form of a hardware security key or as a pure software implementation in the platform browsers. My guess is we will strike a middle ground...with the dominant form of authenticator being hardware based...but that hardware taking the form of the devices you already own (phone, laptop, etc).
This isn’t to say it happened on every response..it was a relatively small fraction. But, it was enough to tell _something_ was going on. Who knows, it could be something quirky on the network and not even a gRPC issue. But, because the runtime is so opaque, it made debugging quite difficult.
One that we encountered in several services were gRPC ruby clients that semi-regularly blocked on responses for an indeterminate amount of time. We added lots of tracing data on the client and server to instrument where “slowness” was occurring. We would see every trace span look just like you would hope until the message went into the runtime and failed to get passed up to the caller for some random long period of time. Debugging what was happening between the network response (fast) and the actual parsed response being handed to the caller (slow) was quite frustrating, as it requires trying to dig into C bindings/runtime from the ruby client.
Need or not need...a bigger issue is simply the technical reality of what you have now. If your non-trivial infrastructure doesn’t have great http2 support, it might be a pretty big lift to make that change first.
Our main hinderance with gRPC was that several disparate teams had strange issues with the fairly opaque runtime. The “batteries included” approach made attempts to debug the root causes quite difficult.
As a result of the above, we have been exploring twirp. You get the benefits of using protobufs for defining the RPC interface, but without quite as much runtime baggage that complicates debugging issues that arise.
While the tools themselves might not use the same key for both operations, I think the question was asking about whether it is problematic that a user’s SSH keys, used in SSH for signing, are also used by these tools for encrypting. In other words, the concern being the same key is used for two different operations, even if not in the same tool.
As I commented in https://news.ycombinator.com/item?id=19953623, I’d love to see another blog post walking folks through why/how the “dangerous” RSA keys are in fact useable for both operations because the textbook RSA concerns aren’t a concern because of X, Y, and Z.
The bit being referred to is how signing and encryption can be inverse operations of each other in some schemes. The canonical example is textbook RSA. Signing is the same operation/math as decryption. Likewise, verifying signatures and encryption are the same operation/math. So, if one used textbook RSA for both things under the same key pair, then an encrypted blob under public key PK could be decrypted if you can get the same person to sign that same blob using secret key SK. In other words, in textbook RSA sign(private, encrypt(public, message)) == message.
There are things that make this less trivial to exploit for non-textbook cases. But, either way, it is generally easier to mostly go with “don’t use the same key for both signing and encryption” so you don’t have to do a bunch of stuff to figure out if a given construction is safe. If Filippo is supporting RSA ssh keys, I’d love a post walking through the way to prove that reusing RSA keys turns out to be safe if done carefully/thoughtfully.
I mostly agree, though I still think adding 2fa to whatever password manager you do use is vaguely worthwhile. Long term creds can get checked into repos, accidentally pasted somewhere, etc. May as well have 2fa to mitigate this edge case ️.
SMS does still help to mitigate a common attack...folks trying out password dumps on other sites. But, I don’t disagree we need to move on when we have more options to choose from. Right now the best looking option is webauthn with platform authenticators.
I think the trick is to push the trust up a level to the platform owner (you have to trust someone at some point) via webauthn or something. If you do that, then the browser itself can be the one the be trusted to show the actual public key being added. As long as you are relying on the server itself to serve trustworthy JS to show and validate the new public key, you are kinda stuck.
As noted elsewhere in this thread, I’m not advocating this homegrown solution. But, I will play devil’s advocate a bit. Yeah, sure, a Secure Enclave key per device is more secure than not. But, what is your threat model where this is the priority? The only realistic threat model where the enclave (or hardware security key) would come into play is malware running on the device. But, in that situation, you are probably hosed anyway. The malware can read browser session cookies. Or, it can interact with the enclave or external dongle in ways that would grant them access to whatever site they want by sending bogus site challenge requests for site X to the enclave/dongle when you meant to approve a challenge for site Y.
I personally think there is potentially a big security usability win by using a securely (key part here) synced private key (via iCloud Keychain for example).
I’m not advocating for this homegrown solution, but moving private keys around isn’t necessarily the worst idea ever. A unique key per device requires explicit registration on each device. That is “better security”, but also potentially far worse security user experience. Security user experience isn’t to be undervalued. 2FA today is miserable precisely because of the tragic security user experience. Folks don’t understand how fragile things are if they drop their single device with google authenticator in the lake. I think a securely synced shared key could be a huge usability win with only nominal security downside. For example, I think Apple could pull this off pretty darn well using their iCloud Keychain system.
This feels vaguely like a homegrown version of webauthn, but without any of the niceties of having the browser enforcing origin protections and ensuring the credential isn’t lost if cookies/local storage are cleared.
I’m not even convinced “don’t click links” is the best guidance. That message has been pushed so hard that people immediately think their machine has been compromised once they have clicked a shady link. That is nearly never the case. Clicking links isn’t something that should cause fear. Nobody is burning a modern browser vuln in a spam email. I think the message should be more focused on not manually entering credentials into a site. Lean on your browser to validate domains and know which sites are associated with which credential. I say that somewhat aspirationaly , as I still think there is lots of room for how well browsers and password managers work for novice users.
Totally to each their own...there is no perfect solution for this. I do understand the the apprehension with google shutting down services, though google photos is so wildly popular it would almost be analogous to them shutting down gmail at this point. Also, one nicety with google photos is the photos are just photos in a folder structure of your choosing. If/when the service goes away you can literally just import the folder structure to the next thing.
Here is a quick repo that has all the directions and hazel rules. I only spent all of 5 minutes pulling it together, so feel free to open an issue if you run into any problems.