Cryptonoise: January 2019
Our first topic of discussion was relating to how we all used passwords and how password reuse can very quickly become problematic if it happens that your password is leaked.
Over time, the probability that any entity holding a large store of sensitive private data will remain both competent enough to protect it adequately and honest enough to want to goes to zero. –@mattblaze
In good news, everyone was already aware of the risks of password reuse. The vast majority of the attendees were using pass as a password manager. One attendee used a method to derive unique passwords for services from a hash function, a salt, a master password, and a memorable name for the service. Between us we were not able to come up with any shortcomings in the strategy except for those that had already been considered but a password manager still looked to be the easier option.
We talked a little about how some passwords are more important than others and that some passwords, such as your email password, might be proxies for other passwords, e.g. by password reset emails. I learned of a feature of pass that I did not know about before that allows you to encrypt different subfolders of your password store to different keys allowing for passwords to be selectively available in different locations. This would allow you to protect the most important passwords while allowing others to be used more freely.
As so many of us are using pass, we also talked about the possibility of future collaboration on pass extensions and swapping hints and tips. Two areas we identified were in obfuscating the accounts list and being able to see how old a password is and so have an idea when it should be rotated.
No one had any set schedule for rotating their passwords, so this is hopefully something that we will be thinking about some more and we might discuss more at future events.
Following from the password manager discussion we talked about the use of two-factor authentication. Some were using email or SMS second factor authentication but not really using cryptographic second factors such as a time-based one time password app on a phone or a hardware token like a YubiKey.
Many of us are using a YubiKey for GPG, which we then use for pass. As only the password would be required to access a service and the YubiKey only unlocks the password, this isn’t really two factor authentication. The oathtool command can be used to generate one time passwords and the key for this can be stored in pass. As the key is just a password that allows you to generate a two factor authentication code this may just be a two password arrangement if your pass database is compromised. If just the password is compromised though this may still provide some security as an attacker cannot use the password alone to log in.
Our last discussion topic was disk encryption. We discussed the trade offs between full disk encryption and encrypting only your home directory. If a machine only has an encrypted home directory then it would still be able to boot and perhaps you would have a chance to locate it if you can access it remotely. An attacker would have the ability to modify the contents of the disk however, including the operating system. Given that an attacker could insert backdoors into a laptop in a number of locations (firmware, hardware implant, rootkit, etc.) it may be that you wouldn’t want the laptop back after it has been suspiciously missing even if you did track it down.
Signed binaries may in the future remove the threat of modification of the disk contents as an attacker’s modifications would just never get run. Of course this is only in the case that the user has some control over the system.
We had a quick session at the end to discuss topics for future sessions this year. So far we have:
- Securing your communications in hostile networks
- Securing your communications at home
- The differences between BSD and Linux
- Best practices for working with Windows
- GnuPG, web-of-trust, and keysigning
This post was syndicated on: