Archive for February 4, 2020

Tuesday, February 4, 2020

A New Hash Algorithm for Git

Jonathan Corbet (via Hacker News):

With the hash algorithm abstracted out of the core Git code, the transition is, on the surface, relatively easy. A new version of Git can be made with a different hash algorithm, along with a tool that will convert a repository from the old hash to the new. With a simple command like: 

git convert-repo --to-hash=sha-256 --frobnicate-blobs --climb-subtrees \
   	--liability-waiver=none --use-shovels --carbon-offsets

a user can leave SHA‑1 behind (note that the specific command-line options may differ). There is only one problem with this plan, though: most Git repositories do not operate in a vacuum. This sort of flag-day conversion might work for a tiny project, but it’s not going to work well for a project like the kernel. So Git needs to be able to work with both SHA‑1 and SHA‑256 hashes for the foreseeable future. There are a number of implications to this requirement that make themselves felt throughout the system.

One of the transition design goals is that SHA‑256 repositories should be able to interoperate with SHA‑1 repositories managed by older versions of Git. If kernel.org updates to the new format, developers running older versions should still be able to pull from (and push to) that site. That will only happen if Git continues to track the SHA‑1 hashes for each object indefinitely.

Previously:

Alternative Ways to Protect Yourself From Being Spearfished

Ivan Drucker:

We came up with a technique that uses Google Voice text messages as an alternative to authenticator apps—although it requires a bit more setup, we think it’s easier to use and understand, plus it acknowledges some people have to allow trusted assistants or consultants access to their accounts.

[…]

I called my carrier and activated a PIN, and I keep it in my password manager. I strongly advise that you do the same—here are informational links for AT&T, Sprint, T-Mobile, and Verizon. However, I don’t want to rely solely on a carrier transfer lock. I don’t know how well they are implemented, and I assume that some thieves are really good at what they do and may be able to talk their way around it.

[…]

Because the account email address in no way identifies them and is used for nothing other than hosting the Google Voice number, a thief should never come across it. And, even if one did, they wouldn’t know to whom it belongs. (If you do try this Google Voice approach, be sure to remove your real cell phone number from your account, which is added by default during setup. If you don’t, an attacker stealing your cell phone number would still get the Google Voice text message codes. Also disable the default forwarding of text messages to your email address.)

Google Voice accounts are probably more secure than your real phone number, but be careful about your account expiring.

NSErrorDomain, NS_ERROR_ENUM, and NSErrorUserInfoKey

Bertrand Longevialle (via Colin Cornaby):

Objective-C has a few macros to available to make your own NSError+YourDomain.[hm] self-documentingly crystal-clear. 👌

[…]

Because it is imported in Swift as a specific type, properly defined NSError domains and code enums let the client benefit from all the completeness of NSError while writing first-class swift code.

While NSError initing remains very similar, their handling gets shortened and clarified.

Joachim Kurz:

What the Compiler does for the enum cases of an NS_ERROR_ENUM is two-fold:

  • use the name of the enum and remove that prefix from all enum cases before importing them to swift
  • create an enum with the given name to hold those cases. If the given name ends with Code remove that suffix.

See also: Handling Cocoa Errors in Swift.

Delivering Origin-bound One-time Codes Over SMS

Ricky Mondello:

We’ve published an explainer about an idea to harden SMS-delivered one-time passwords by allowing senders to associate the codes with a website. We’ve been talking about the idea with some folks at Google, and would like more feedback.

WebKit (MacRumors):

This proposal attempts to reduce some of the risks associated with SMS delivery of one-time codes. It does not attempt to reduce or solve all of them. For instance, it doesn’t solve the SMS delivery hijacking risk, but it does attempt to reduce the phishing risk.

[…]

But because there is no standard text format for SMS delivery of one-time codes, systems which want to make programmatic use of such codes must rely on heuristics, both to locate the code in the message and to associate the code with a website. Heuristics are prone to failure and may even be hazardous.

[…]

To address this, we propose a lightweight text format that services may adopt for such messages. It’s about as simple as it gets. It begins with (optional) human-readable text. After the human-readable text both the code and the origin appear on a single line, with sigils denoting which is which. This is the last line of the text.

Previously:

Update (2020-04-08): Ricky Mondello:

We’ve moved “Origin-bound one-time codes delivered via SMS” to @wicg_, where we’re working on a shared spec with our collaborators at Google.

Update (2020-08-27): Filipe Espósito:

Earlier this year, Apple’s WebKit team proposed a change to the format of SMS one-time passcodes to make two-factor authentication more secure. Apple confirmed today that developers can already implement these changes with iOS 14 and macOS Big Sur.

Copyright © 2000–2024 Michael Tsai.