Cryptonoise: January 2019

· security digital rights cryptonoise 57north events
This blog post is more than two years old. It is preserved here in the hope that it is useful to someone, but please be aware that links may be broken and that opinions expressed here may not reflect my current views. If this is a technical article, it may no longer reflect current best practice.

On Thursday 17th January, we held the first Cryptonoise event of 2019. We had a good turn out and kicked off the discussion with a quick browse through Wikipedia’s list of data breaches.

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

The next Cryptonoise will be at 19:00 on the 28th February 2019 in the 57North Hacklab Social Room. More details will be sent closer to the time on the org-aberdeen and 57north-discuss mailing lists.

If you would like to contact me with comments, please send me an email.
If you would like to support my free software work, you can support me on Patreon or donate via PayPal.

This post was syndicated on: