It is kind of scary too — lose the key and no one can get you back in to your account.
It is kind of scary too — lose the key and no one can get you back in to your account.
sounds like a feature
"want to totally restart your entire digital life? just rip up your key :) never worry about something from your past coming back to you ever again!
You make posts on twitter, it's not protected the same way.
Do Apple definitely not retain a key? If they don’t is the encryption quantum secure?
If this is the threat vector you’re worried about, you shouldn’t have had anything in iCloud (or any cloud for that matter) to begin with, rendering this debate completely moot.
Incorrect: only Apple cannot.
You can voluntarily declare:
- recovery accounts: these trusted accounts can help you authenticate anytime.
https://support.apple.com/en-us/HT212513
- legacy contacts: these trusted contacts can access your account in the event of your death.
https://support.apple.com/en-us/102631
As for the "lose recovery key" situation is no different than hardware token 2FA + recovery codes. Print multiple copies and spread them to trusted third parties.
That's easy to backup. You can even print it and bury it in a sealed box in the garden or put it in a book or whatever. It depends who you are protecting against.
That means you're one natural disaster away from losing everything.
As much as it can "weaken" security, an electronic backup is still recommended for most
Maybe I'm being dense (probably), but where would you save it?
iCloud? No, that doesn't work - you need the key to access iCloud.
Some other cloud storage service? No, that doesn't work - you need your phone to generate a token for access and your phone was destroyed in the same fire as the paper backup.
Seems like the safe choice is a lock box at a bank or similar. Or a fireproof safe at home.
Of course, a code like that can be in multiple places, possibly where it won’t be recognized as such.
I'm imagining this spiraled around somebody's upper thigh... "fakePassw0rdo̶n̶e̶t̶w̶o̶t̶h̶r̶e̶e̶four"
But safety deposit boxes are a good choice too, just be careful to balance your own convenience. If you can't easily update your backups, you're really unlikely to include new accounts in them
I suppose a phrase works too, and easy to remember.
I guess you'd have bigger problems at that point.
Also, the idea is simple enough you could DIY your own version with stuff from any hardware store.
You definitely don't need your phone for access. I use Yubico security keys for everything like this. I have several of them that are on all my accounts and I don't keep them in the same place.
The conventional way to do this would be encrypt it with a symmetric cipher keyed from a password or passphrase. I've been using an unconventional approach where the secret you have to memorize is an algorithm rather than a password/phrase. Programmers might find an algorithm easier to memorize than a passphrase.
Here's an example of this general idea. The algorithm is going to be a hash. This one will take a count and a string, and output a hex string. In English the algorithm is:
hash the input string using sha512 giving a hex string
while count > 0
prepend the count and a "." to current hash and apply sha512
The recovery code I want to backup is 3FAEAB4D-BA00-4735-8010-ADF45B33B736.I'd pick a count (say 1969) and a string (say "one giant leap for mankind"), actually implement that algorithm, run it on that input and string. That would give me a 512 bit number. I'd take "3FAEAB4D-BA00-4735-8010-ADF45B33B736" and turn it into a number too (by treating at as 36 base 256 digits). I'd xor those two numbers, print the result in hex, and split it into 2 smaller strings so it wouldn't be annoyingly wide.
Then I'd save the input count, input string, and the output:
1969 one giant leap for mankind
ed428dffa23f4f14ae2a7b7e842019fc11b5726d726b96c11ec266758be67cb0
f2a78a320a85df809afe83c6c7840e2d175cceadb455260735405cd047459cc9
I'd then delete my code.I could then do a variety of things with the "1969 one giant leap for mankind" and the two hex strings. Put then in my HN description. Include then in a Reddit comment. Put them on Pastebin. Take a screenshot of them and put it on Imgur.
To recover the code from one of those backups, the procedure is to implement the algorithm from above, run it with the count and string from the backup to get the 512 bit hash, take the 512 bits of hex from the backup, xor them, and then treat the bytes of the result as ASCII.
Then delete the implementation of the algorithm. With this approach the algorithm is the secret, so should never exist outside your head except when you are actually making or restoring from backup.
When picking the algorithm take into account the circumstances you might be in when you need to use it for recovery. Since you'd probably only be needing this if something so bad happened that you most of your devices and things like your fireproof safe, you might want to pick an algorithm that does not require a fancy computer setup or software that would not be in a basic operating system installation.
The algorithm from this example just needs a basic Unix-like system that you have shell access to:
#!/bin/sh
COUNT=$1;
shift;
KEY=`/bin/echo -n $* | shasum -a 512 | cut -d ' ' -f 1`
while [ $COUNT -ge 1 ]; do
KEY=`/bin/echo -n $COUNT.$KEY | shasum -a 512 | cut -d ' ' -f 1`
COUNT=`expr $COUNT - 1`
done
echo $KEYFinding somebody’s will doesn’t give you access to any of their data or funds.
I also stuck that key in 1Password (sure it's less safe, but if my 1Password was breached I have far bigger problems than this key being retrieved).
Then keep a hard copy in a safe. Been contemplating sending my parents a safe (who live several states away) with keys on a sheet of paper without context that only I have the combination too. But not sure yet.
A friend of mine who was (maybe is? he knows I'm not a fan so we don't talk about it much) big into crypto stores his secrets in similar safes with trusted friends and family around the country. I think it's a good idea for things like this tbh.
I think I might need to look up to see if there is a known pattern to these keys that it could be easily figured out what it is even if it is just on a sheet with no context. Particularly 1Password which I think is a pattern if I remember correctly.
What does that mean?
Similar to how a lot of package companies have a certain pattern, length, whatever for their tracking numbers. If there was a somewhat reliable way to say "This is a 1Password key" or "This is an iCloud key" it makes it means even without context it could be an issue.
Survives a fire, earthquake. No tornadoes or tsunamis here. Nobody has stolen any such rocks from here.
I don’t doubt that many people do, but it’s still not a solution for the majority of Apple users.
> However, if you lose your recovery key and can’t access one of your trusted devices, you'll be locked out of your account permanently.
I considered it before but I think it's just too much risk as I rely heavily on iCloud. On the other hand, I don't see the risk with the current method if you're smart enough not to fall for things like MFA bombing tactics.
I don't think its a matter of being "smart enough". Human error can easily creep in when dismissing 10's or 100's of prompts.
Your data and account ownership interest doesn’t disappear because of failure to possess the right sequence of bytes or a string. Can you imagine if your real estate or securities ownership evaporated because you didn't have the right password? Silliness.
> Your data and account ownership interest doesn’t disappear because of failure to possess the right sequence of bytes or a string.
Somehow you have to establish that you are the owner of the account, in a way that nobody else can do it. This is very much not a trivial problem, and government IDs don't provide any kind of solution to it.
If you need a driver's license, how do you get a driver's license? With a birth certificate? Okay, how do you get a copy of your birth certificate when you don't have a driver's license?
If there is a path to go from your house burning down and you having zero documents to you having a valid ID again without proving you've memorized or otherwise backed up any kind of secrets, an attacker can do the same thing and get an ID in your name. This is why identity theft is a thing in every system that relies on government ID. Requiring all systems to accept government ID is requiring all systems to be subject to identity theft.
> Somehow you have to establish that you are the owner of the account, in a way that nobody else can do it. This is very much not a trivial problem, and government IDs don't provide any kind of solution to it.
This is actually very easy. You can identity proof someone through Stripe Identity [1] for ~$2/transaction. There are of course other private companies who will do this. You bind this identity to the digital identity once, when you have a high identity assurance level (IAL). Account recovery is then trivial.
> If you need a driver's license, how do you get a driver's license? With a birth certificate? Okay, how do you get a copy of your birth certificate when you don't have a driver's license?
This is government's problem luckily, not that of private companies who would need to offer account identity bootstrapping. Does the liquor store or bar care where you got your government ID? The notary? The bank? They do not, because they trust the government to issue these credentials. They simply require the state of federal government credential. Based on the amount of crypto fraud that has occurred (~$72B and counting [2]), government identity web of trust is much more robust than "not your keys, not your crypto" and similar digital only primitives.
NIST 800-63 should answer any questions you might have I have not already answered: https://pages.nist.gov/800-63-3/ (NIST Digital Identity Guidelines)
[1] https://stripe.com/identity
[2] https://www.web3isgoinggreat.com/charts/top
(customer identity is a component of my work in financial services)
"Pay someone else to do it" is easy in the sense that doing the hard thing is now somebody else's problem, not in the sense that doing it is not hard. That also seems like a compliance service -- you are required to KYC, service provides box-checking for the regulatory requirement -- not something that can actually determine if someone is using a fraudulent ID, e.g. because they breached some DMV or some other company's servers and now have access to their customers' IDs.
> This is government's problem luckily, not that of private companies who would need to offer account identity bootstrapping.
But it's actually the user's problem if it means the government's system has poor security and allows someone else to gain access to their account.
> Based on the amount of crypto fraud that has occurred (~$72B and counting [2]), government identity web of trust is much more robust than "not your keys, not your crypto" and similar digital only primitives.
The vast majority of these are from custodial services, i.e. the things that don't keep the important keys in the hands of the users. Notably this number (which is global) is less than the losses from identity theft in the US alone.
The general problem also stems from "crypto transactions are irreversible" rather than "crypto transactions are secured by secrets". Systems with irreversible transactions are suitable for storing and transferring moderate amounts of value, as for example the amount of ordinary cash a person might keep in their wallet. People storing a hundred million dollars in a crypto wallet and not physically securing the keys like they're a hundred million dollars in gold bars are the fools from the saying about fools and their money.
Using vitalchek, you can order a BC with a notarized document, using two people who have valid IDs as people to vouch for your identity. I've done it for multiple clients.
So if I'm understanding this correctly, if me and one of my friends both have a valid ID, we can get anybody's birth certificate?
Note: The notary will record the ID #s and other info of the two ID holders. So if something goes wrong, the two ID holders will be on the hook as well.
Once the notarized document is submitted to vitalchek, they'll process the request.
Of course, one would still have to know a few details from the BC (parents, location, etc) to get vitalchek to submit the request to the county/city registrar.
Though of course this is a method of fraudulently obtaining an official ID, so you do need to be concerned that the people engaged in that sort of enterprise might already have a couple of them.
> Of course, one would still have to know a few details from the BC (parents, location, etc) to get vitalchek to submit the request to the county/city registrar.
Which is the sort of thing that gets collected in big databases which then get breached and published on the internet.
I’m not sure you want that to be the absolute best digital security you can get.
Recovery key isn’t susceptible to that - and isn’t susceptible to fake-id-spotting-ability or bribeability of staff either.
> Why can't they offer a last-resort option like showing up in person at an Apple Store with government-issued photo ID?
This is easy to defeat and completely subverts the purpose of the system. If you are not comfortable with self-custody then don’t opt in.I'd say a lot of identity problems are there because companies have to identify people without an official ID somehow...
E.g. you could make it costly to attempt, require a notarized proof of identity -and- showing up at the Apple store, and enforce a n-day waiting period. A different employee does the unlock (from a customer service queue) than accepts the paperwork.
We don't lock people out of financial accounts forever when they forget a credential. It could definitely be solved for other types of accounts.
The main problem is that walking into an apple store with a government-issued warrant works just as well as walking in with a government-issued ID.