Current account recovery best practices?
from to on 17 Jan 2024 01:30

Hi all,

Need to pick your brains for a bit regarding best practices for handling of account recovery issues while traveling.

Premise would be that my phone gets lost or stolen, and I may not have easy access to my laptop either, and being in a foreign country I couldn’t easily get a copy of the original SIM to restore via OTP.

Consequently, I also don’t really love the idea of using some password manager with a master password and no F2A.

Under those circumstances, what would you consider the best way forward to ensure accessibility without crippling myself in the process?

The only thing I can come up with is a random subdomain on one of my domains, with random username and random password, where I store an encrypted container containing txt-files. Maybe even further obscured with a random cypher (all numbers / letters shifted x positions to the right or something).

But there’s gotta be other use-cases out there, so I was wondering what you are using?

Ideally something that doesn’t involve another person.


#cybersecurity on 17 Jan 2024 01:57 next collapse

Keepass db syncd on cloud with multiple devices, 2FA using email instead of mobile number. on 17 Jan 2024 02:03 collapse

How do you get into your email? on 17 Jan 2024 02:53 collapse

I use an email client which saves my password and I don’t need to enter it. But the keepass db can also store your email password for you. on 17 Jan 2024 03:02 collapse

That’s the problem.

We’re discussing accessing your accounts without prior access to a pre-authorized device.

If you don’t have a device that’s already signed into your email, you can’t get into your passwords at all. Email is locked with a password stored in your password db, your password db is locked with your email. Without one or the other signed in already, you’ve locked yourself out of your own accounts. on 17 Jan 2024 12:38 collapse

Keepass db doesn’t use email 2fa, its just a file you store on your device

I store it on all my devices so if I lose one I still have several others.

I use nextcloud to keep them syncd but you can use any cloud (google drive, icloud, one drive, Dropbox, etc) on 17 Jan 2024 14:15 collapse

That’s still gaining access through a device that’s already signed in/has your password db.

If you do not have access to a device that’s already signed into your accounts/has a copy of your password db; how do get in?

Presumably you’re smart enough to not have password only auth on a public facing nextcloud instance if it stores your password db…

This is the scenario we are discussing. The fact you store you db on other devices is entirely irrelevant. on 17 Jan 2024 14:45 collapse

My nextcloud instance uses fail2ban and I use a >32bit strong password.

Assuming I lose my phone and my laptop and my personal computer and my nextcloud instance I would be screwed.

Since I host my own mailserver I would be able to create a new mailserver with a new password though and recover any accounts with a new email. on 17 Jan 2024 02:10 next collapse

I have a backdoor into my home vpn using a series of usernames, passwords, and long obfuscated http paths/subdomains.

In an absolute emergency, I can traverse that maze, retrieve a key+config to connect to openVPN, then reach my vaultwarden vault. No 2fa on that vault as it’s not accessible from WAN. (though technically I could add 2fa and still be able to disable just the 2fa from vaultwardens admin console in a pinch) on 17 Jan 2024 03:14 collapse

Do you have all the paths, usernames and passwords committed to memory? My biggest fear is making it so secure that I don’t remember it myself, since I’ll effectively never use it until the emergency case occurs. on 17 Jan 2024 03:38 collapse

Yeah. They’re all human readable but non-obvious instead of random strings. Stuff that’s easy to remember but difficult to guess. You’ve just got to avoid typical patterns like ‘randomwords526!!’ or ‘p00rex@mpl3’.

I do like to exercise that memory now and again, testing that I remember and that everything’s functioning as it should. Just in case, theres instructions on paper in a safe place.

Being four separate item’s minimum: subdomain, path, username, and password, none of which are published anywhere ofc; makes it pretty secure. The openVPN config/key needs a password as well, so 5 items. on 17 Jan 2024 03:53 collapse

Right, I’ve taken a similar approach now. Unknown subdomain at an unknown domain which is not accessible from the web, only via ftp. FTP username and password are known only to me, long and obscure but not forgettable. Then a random subfolder-tree down in an outdated cgi-bin script. In the folder I’ve got a password protected zip archive with dropbox recovery codes, and in the dropbox finally my google codes in yet another password protected archive. All passwords different and never been in any reported breach.

That’s gotta do it for now. Thanks a lot for your input! on 17 Jan 2024 03:46 next collapse

Well that’s kinda the point. Missing your factors is supposed to make it harder.

So — account recovery code written out, that doesn’t say it is for your account?

E.g. Apple allows it as a backup to your Apple ID should you get locked out.

Depends on the syy on 17 Jan 2024 03:49 collapse

Yes exactly, but I still need to be able to access it myself.

Writing the codes out is one thing, but taking a paper with me on international trips actually increases the risk of it getting lost, damaged or stolen as well; and if someone was to figure out what they are for, that could even increase the potential risk. Hence my question what other people are doing :-) on 17 Jan 2024 05:17 collapse

I use a very simple “hashing” algorithm that I can do mentally. If I want to log into a service, I “hash” its name, and that’s my password.

Every service I use has a different password, and I don’t have to remember any of them. I have no keyvault that can be stolen.

MFA is still an issue. You’ll need your recovery codes to be accessible, but encrypted. on 17 Jan 2024 17:32 collapse

This is pretty clever actually