Protecting Linux Login with 2FA

This is definitely not the first time I’ve tried getting this working, but glad I was finally able to. Looks like if I had read a bit more, I never would have run into issues…

By the second or third time I ran into problems, I at least figured out why: with my home directory being encrypted, the “secret” 2FA files could not be accessed & verified.

Now for the fun part… It looks like Google had the instructions for encrypted home directories in the README the whole time.

Encrypted home directories
If your system encrypts home directories until after your users entered their password, you either have to re-arrange the entries in the PAM configuration file to decrypt the home directory prior to asking for the OTP code, or you have to store the secret file in a non-standard location:

auth required pam_google_authenticator.so secret=/var/unencrypted-home/${USER}/.google_authenticator

would be a possible choice. Make sure to set appropriate permissions. You also have to tell your users to manually move their .google_authenticator file to this location.

In addition to “${USER}”, the secret= option also recognizes both “~” and ${HOME} as short-hands for the user’s home directory.

When using the secret= option, you might want to also set the user= option. The latter forces the PAM module to switch to a dedicated hard-coded user id prior to doing any file operations. When using the user= option, you must not include “~” or “${HOME}” in the filename.

The user= option can also be useful if you want to authenticate users who do not have traditional UNIX accounts on your system.

So, after getting through that tedious “reading” thing, I followed their suggestion, & created the “unencrypted-home” directory, moved the ~/.google_authenticator file there, edited /etc/pam.d/common-auth & included the path to the file at the encrypted location. After that… Working as expected!

user@Hostname:~$ cat /etc/pam.d/common-auth | tail -n 1
auth required pam_google_authenticator.so secret=/var/unencrypted-home/${USER}/.google_authenticator

Password “Complexity” Requirement

I actually forget what web site this one, but found this little gem while trying to setup a new account:

I guess my password doesn’t meet their requirements?
Then I decide to use this instead.

No, I didn’t actually make my password “password123” but I would have thought a site warning my against it wouldn’t allow “password”+< something >. The fact that it wouldn’t accept my random password probably should have been my first hint that it was not going to go well.

Moving from Authy to Another 2FA App

Despite the convenience of having Authy’s ability to sync across devices, I decided I wanted to change my 2FA app to Android’s andOTP. To do this (without unenrolling & re-enrolling myself in 2FA for my 50+ services), I needed to find a way to export my secrets from Authy. I did find a few posts on the topic, but didn’t have any luck with those guides. Most seemed to be a variation on the same process of getting the secrets from the Authy Chrome extension.

GitHubGist: Generating Authy passwords on other authenticators

What I did end up finding that finally worked, was to pull the XML containing details on each entry in Authy, thanks to this post: GBATemp: extract your totp keys from authy using chrome:

Good job, this tutorial is great for people who need to extract their keys out of Authy without needing a rooted Android/Jailbroken iPhone to grab them from the mobile app.

For people with rooted Android phones, the totp keys are stored here:
/data/data/com.authy.authy/shared_prefs/com.authy.storage.tokens.authenticator.xml

The filepath is what I was looking for

In the past, when I was using Google Authenticator, you had the ability to pull the database from the Android app, assuming you were rooted. The above process seems to be similar, just for the Authy app, instead of Google Authenticator: /data/data/com.google.android.apps.authenticator2/databases/databases.

This post is for my own reference, & for anyone else that may want to move from Authy, to another authenticator app.

Scammers Using Microsoft’s Support Site

I just came across this video (posted yesterday), where scammers are leveraging Microsoft’s legitimate support site at https://support.microsoft.com/help. This was after I received a fake Microsoft support call. Unfortunately, I didn’t have a dummy VM ready to waste their time, but glad I found out about the use of Microsoft’s site. Because Microsoft uses LogMeIn, their support site seems to just forward the code to LogMeIn to start the session.

See the video below for how the site is used:

ANOTHER GOOD article about passwords

Very glad to see another post by a site, giving good information on handling passwords, security question answers, & the recommendation to use password managers. I last had a post about this in July, when Dreamhost also put out a good article about creating strong passwords for account security. The link to that article is below as well.

Lifehacker: Use Your Password Manager for Security Answers, Too

Dreamhost: How to Create Strong Passwords to Keep Your Website Safe

FINALLY: A Good Password Management Article

DreamHost recently posted an article on their site about password management: DreamHost: How to Create Strong Passwords to Keep Your Website Safe. Just the list of points is much better than what I’m used to seeing:

  1. Make your password long.
  2. Don’t use a common phrase.
  3. Test your password.
  4. Don’t reuse your password.
  5. Use a password manager.
  6. Don’t store passwords in your browser.
  7. Follow the rules every time.
  8. Use two-factor authentication.
  9. Consider the Passphrase/Diceware Method.
  10. Use security questions wisely.
  11. Keep an eye on your smartphone.

I still have to actually read the specifics for each, but that list alone is a great guide on modern password management.

iOS’ USB Restricted Mode “Loophole”

Everyone seems to be trying to point out this “loophole” as a huge deal, getting in the way of the new feature in iOS 11.4.1 that disables the USB port for anything but charging if the device has been locked for more than an hour (or S.O.S. mode is activated on the device).

The “loophole” that people are calling a flaw is that if certain Lightning-connecting accessories are connected within the one-hour window, the timer is stopped. This does not apply to all lightning accessories, as the Lightning-to-3.5mm jack accessory does not reset the count. Apple’s Lightning-to-USB 3 Camera Adapter, however, is one of the accessories that stop the countdown. This makes perfect sense, as it allows the user to connect an accessory without the need to unlock first. If the device is in a pocket, then said accessory can just be connected. It would be one thing if Lightning accessories were trusted the same way as computers are, but that is not the case here. There is no cryptographic key exchange when connecting accessories so the device doesn’t know one accessory from another, without manufacturers making changes to their products.

This is a great step forward, making it much more difficult for attackers & warrant-skipping authorities from having virtually unlimited time to try & crack a device. Here I’m specifically thinking of the GrayKey device & any other services offered by shady companies for unlocking iOS devices.

Screenshot showing the new USB Restriction setting.

Apple’s Warning Against Jailbreaking

Seeing as how the Electra 11.3.1 jailbreak is supposed to be released soon, it looks like Apple put out a statement on why you shouldn’t jailbreak: Apple: Unauthorized modification of iOS can cause security vulnerabilities, instability, shortened battery life, and other issues. I definitely find that ironic…

  • Security Vulnerabilities: I’ve seen jailbreak developers release patches for devices with Cydia before Apple puts them out
  • Instability: Okay, sure. But if an occasional crash is the cost of having things like themes & hooks into Springboard, it’s a price I’m willing to pay. Especially because iOS isn’t that much more stable without being jailbroken.
  • Shortened Battery Life: This coming from the company that was secretly throttling older device “to save battery life”. Sorry if I don’t believe this one.

I have not yet read the rest of the page, but I’m sure it will be much of the same above. I’m not interested in Jailbreaking to download free apps; it’s for the ability to customize the device i own & want to do with as i please.