read more
Staying Secure in 1Password.
The truth as it appears: the only way to stay fully safe, is to memorize and to have no way to recover certain things.
What are we safe against?
• Online threats (most likely)
⁃ Now that all passwords are unique and very long+random, we are fully secure.
• Theft
⁃ With a firmware password set, the thief will not be able to sell the computer at all/easily.
⁃ Admin password is set to something highly secure with FileVault on, to ensure that the thief couldn't even read the SSD contents if they took it out of the computer (which would be necessary to do to even try to read it, considering we have a firmware password set)
⁃ So long as computer had been unplugged from all devices and power for 10 minutes (time varies based on our setting) before thief starts trying to extract data, the file vault key has been completely wiped from RAM so even them opening the computer and somehow trying to recovery the data in the RAM we'd be fine.
⁃ Enabling a device passcode on the iPhone as we have done actually encrypts the phone, so the data can't be read even if the storage is removed.
⁃ Enabled iPhone backups as well, just for an extra level of encryption on those.
⁃ Both external hard drives encrypted with Time Machine
• Government Seizure
⁃ Any essential documents should be encrypted in 1Password, so it'll be safe.
Regarding Internet security:
• Should just be using VPNs, and a series of proxies
• Should use DNS crypt (otherwise which sites being visited is sent essentially in the clear)
• Potentially use Tor as well.
Online threats are essentially zero with 1Password. Every account will have an unbreakable password.
For convenience, we will enable TouchID on macOS and iOS. However, this makes 1Password only as secure as your computer's password and your iOS password to local users (i.e., people who have your computer/phone). It also makes it vulnerable to any remote vulnerabilities in macOS or iOS, because anyone who has remote access and can figure out either of those passwords can also get at the 1Password data, but this is highly unlikely unless it's Apple themselves.
Never store anything of absolute dire security in any shared vaults or a personal vault which is under the family account.
• This gives all family organizers the ability to reset, meaning there exists a copy of the vault key which was encrypted for their public key (server policies prevent their access, but a government could circumvent this; moreover, a nefarious and very technical organizer could find a way to steal this from the server and then if they stole the hard drive, they could decrypt).
Option for incredibly sensitive documents:
You could encrypt it with GPG, using the same master password you're using, then store it in 1Password. That way, even if they get into your 1Password account using various password reset/key schemes, they still could not get at that data. Note of course that decrypted documents will be saved to the drive after opening and modifying, would need to look into how to deal with that.
In a dire situation of security (in order of importance. Do if concerned and don't care about convenience):
Disable TouchID on iOS for 1Password immediately and exit the app to lock the vault.
Disable TouchID on macOS for 1Password immediately and lock the vault.
Secure delete anything incriminating, use command: srm -v (this will overwrite with 35 passes of zeros).
Turn off phone and turn back on to clear RAM and don't enter in passcode
Turn off computer and turn back on and don't unlock (to clear anything that might be in RAM; this will also wipe the file vault key from RAM).
Unplug everything from computer
--if more time--
Fully shut down computer after every use
On iPhone, make sure that the text isn't displayed on the lock screen (to prevent easily resetting accounts via text message without unlocking phone; could probably still be done by intercepting carrier).
Change the 1Password lock keyboard command to something easy.
Communicate only on Wickr.
• Disable TouchID on Wickr
• Research Wickr's security and check for ways of auto-deletion of messages (should be secure deleting)
Change the computer to hibernate immediately on sleep, which will in turn delete the FileVault encryption key from RAM immediately (so long as this switch is still turned on).
• sudo pmset -a destroyfvkeyonstandby 1 (should already have been applied)
• sudo pmset -a hibernatemode 25 (makes it so the computer will hibernate immediately, and thus there's no chance of the key being recovered from RAM).
Switch over to PGP emails, or whatever current standard is (ensure communication partner has a strong password set; their private key will be the key to reading your communications)
Have to assume any account that has a password recovery option is compromis-able, because there is a path to get in through Dad/phone recovery (which is why we should use PGP or store only in 1Password on any sensitive documents/communications). Have removed message previews, so they'd have to work with my carrier at least to get the recovery code via text.
Request deletion of any incriminating online accounts (obviously can't rely on this)
In severely dire situation of security:
Do the above (frankly, encryption is the best security).
• (optional) if you want to make it impossible for even you to grant access to 1Password, generate a new password with 1Password, copy it, and change your 1Password master password to it (that way you can't even access the data. You'll also want to delete all backups, which will have been encrypted using your old master password).
Destroy both devices.
⁃ If time, just run a 7-pass zero of the computer, then continue with below
⁃ Drilling through could help but won't completely destroy
⁃ Microwaving could help
⁃ Best thing would be to find the flash chips and hammer them to pieces
Notes about 1Password, and the potential recovery process and its vulnerabilities.
I think the recovery process works like this: my vault key is stored on the server encrypted with dad's public key. When the recovery process takes place, dad's client downloads the encrypted public key and decrypts it (they seem to suggest there's a way they can do this without him having the actual plaintext key and obviously he's not sending his private key to the server, so should ask about this. I think they messed up, page 34 says they use server policy to prevent "revealing the vault keys to anyone not authorized", but in 35 they say they have the key to the vault, and it makes sense that they would have the key to the vault because how else would they have been able to decrypt it in the recovery process? So shouldn't that be a client-level prevention? They say again in page 42 ", but since 1Password for Teams never has a copy of the unencrypted
vault key"), then the server sends me my plaintext vault key (which is obviously insecure). So then, I decrypt my vault using the key and then set a new account key and master password, and I presume (ask about this) re-encrypt my vault with a brand new vault key, and then encrypt that vault key with dad's public key and send it to the server so he can still (in the future) recover my account.
Account keys really are there to help if their servers get compromised (that's why they're never transmitted to the server). That way, it's really impossible to brute force anybody's master password even if it's weak.
Items in your vaults are encrypted and decrypted using a 256-bit key, generated on device (AES). Everyone has a (public, private) key, which itself is encrypted with a key encryption key (kek), which is derived from master password and account key. This key is called the master unlock key (muk). So you have master, account key -> muk (private key). The private key is really the king of the castle. Your public key is going to be used to encrypt everything you have access to. That's all for encryption, but for authentication "saying hey I'm the device I say I am" they use the account key and the master password to create a "SRP-x", which is a client secret used by the "SRP" protocol. Again, the secrets are never at any point sent to the server. Server policies are in place to prevent the people in the recovery group from getting access to any vaults they shouldn't have access to, or revealing the vault keys to anyone other than the owners of the vault (so, they at no point would have access to the vault key that has been encrypted with their public key; although this is dubitable and should not be trusted).
Each backup you make is secured with the master password that was used at that time, so if you change your password because the previous one was too weak, it's a good idea to delete all those encrypted backups.
Note: 1Password cares about clearing secrets from memory, but their ability to do so in Javascript is limited. Keep that in mind: the browser is technically less secure than native clients, probably.
Protecting FileVault's Encryption:
• There are some very important things we need to do to ensure that the unencrypted key can't be stolen from RAM while our computer is asleep (which is essentially impossible anyway since our RAM is soldered to the board and they can't extract any contents from the RAM without removing it because we have a firmware password set, so the can't put our disk in target disk mode anyway).
• Background:
⁃ By default, unless the computer is off, the unencrypted key will be stored in RAM.
⁃ There is also a state called hibernation mode, which occurs after the computer has been in sleep for three hours (by default). At this point, power is removed from RAM, but because of the hardware (specifically, capacitors) the RAM could still hold its data for several minutes or longer (and therefore still hold the key), so the OS should actively wipe the disk from RAM when hibernation kicks in.
• Essentially, the trade-off we're deciding is if the computer has been closed for a full 10 minutes (this number may change), then the key will be surely wiped from RAM (and we will experience a longer wake time).
• The hibernation mode will also only occur when nothing is plugged in (power or any other device).
• Moreover, the Firmware password still may not prevent the computer from passing its RAM contents to someone, so it's possible they wouldn't even have to remove the RAM to read its contents, making this even more important. However, this likely has been prevented in modern OS' (that is, RAM contents won't be passed if you have FileVault on and the screen is locked): http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-os-lion-filevault-2-encryption/. People use things like the program Inception to run this attack: http://www.breaknenter.org/projects/inception/