Little 418

The resulting entity body MAY be short and stout

Personal Information Spring Cleaning: Connected Apps & Sessions

Posted by Jen Tong on May 18, 2017

This is the second entry in a series about Spring Cleaning for your Internet-connected 21st century lifestyle. Confused? Check out the first entry about authentication and passwords.

This entry is all about user connected apps and sessions.

Connected apps / OAuth tokens

You know when you log in somewhere with Facebook, or click on a button that gives a website access to your profile photo on Google? That’s called a connected app, or in techie jargon OAuth.

OAuth is a wonderful protocol. It gives you the power to selectively share your data between websites and mobile apps.
But that convenience comes with a wrinkle of complexity: it’s easy to forget about all the apps you’ve connected. To make matters worse, some of these app connections will keep working after you reset your password.

So, take some time and review all of your connected apps. Don’t recognize something? Disconnect / revoke / remove it.

Here’s a list of places you might have connected apps:

If you have more than one account at any of these providers, don’t forget to check each one.

Browser sessions & Devices

Some online services keep a memory of previously authenticated web browsers and mobile apps. This phenomena goes by many names including trusted computers, sessions, devices, and recognized browsers.

Trusted devices and browsers have easier access to your account. Sometimes they bypass multi-factor auth, sometimes they are completely trusted. In any case, they’re another gateway to you account that you should keep tidy.

  • Apple iCloud - Listed as ‘My Devices’ and ‘Sign Out Of All Browsers’
  • Apple Id - Listed as ‘My Devices’ and may list different devices than iCloud
  • Dropbox - Listed as ‘Session’ and ‘Devices’
  • Facebook - Listed as ‘Where you’re logged in’
  • GitHub - Listed under ‘Sessions’
  • Google - Listed as ‘Recently used devices’
  • Twitter - Listed as ‘Your devices’

App Passwords

App passwords are a weird consequence of multi-factor authentication. They are passwords that allow you to sign in from applications that do not support multi-factor auth, even if your account it set to require it for all access. This may seem silly, but you might have used it for an old desktop email client. They typically give full, unrestricted access to your account, so it’s important to keep them tidy too.

  • Apple Id - Listed under ‘App-specific passwords’
  • Google
  • GitHub - Listed under ‘Personal Access Tokens’

SSH Keys

While you’re in there, go ahead and clean out any old / unused SSH keys too. These are not as common, but if they get out bad things can happen. You may have accidentally leaked one when you sold an old laptop on Craig’s List.

As a general practice, never reuse SSH keys. Generate a new one for each device / service connection.

  • GitHub
  • Any servers you used SSH to log into

Conclusion

There are more ways into your accounts than just your password. Keep them tidy too!

Did I miss any services that you use? If so, please tell me on Twitter.

In the next blog entry, I’ll move away from authentication (as exciting as it is), and into a more meaty part of the series: almost forgotten social media posts and other uploaded data. I promise an exciting journey down memory lane.

Personal Information Spring Cleaning: Auth and Passwords

Posted by Jen Tong on May 12, 2017

Back in the olden times the custom of spring cleaning was about scrubbing the soot from your wood burning stove off of the walls. But we live in the 21st century, and our heaters don’t leave much soot behind. We do, however, leave bits and pieces of our personal information all over the Internet.

A couple of years ago I adapted the custom of spring cleaning to my Internet life. I do things like audit my passwords, delete abandoned online profiles, expunge embarrassing tidbits of angst-ridden teenage blogging, and generally tidy stuff up.

It’s a wonderfully cathartic practice, and it makes online life safer to boot. So, I’m going to share my spring cleaning regimen with all of you. It’s a grouped checklist, and it’s pretty long, so I’ve broken it up into a few entries.

This entry is all about user authentication and passwords: the gateway to your personal information.

Check for breaches

Data breaches happen constantly. I try to stay on top of them, but sometimes I miss one. Luckily someone else stays on top of them, and he runs a tool for checking your accounts: haveibeenpwned.com.

  • Enter your favorite email addresses and usernames.
  • If your accounts have been impacted, tend to those accounts first: delete them, or update logins and passwords.

Multi-factor auth

Multi-factor auth, also known as two-factor auth, is awesome. Are you using it wherever it’s available? You should be. It’s a wonderfully effective tool for personal info security.

When setting up accounts, favor the most secure option available. Generally, U2F hardware tokens are best, followed by mobile apps, and finally SMS.

  • Go through all of the providers on which you already use multi-factor auth. Can any of them be upgraded to a more secure option? If so, upgrade.
  • Scan the services listed on twofactorauth.org. Look for accounts where you can enable multi-factor auth, and do so.

Passwords

Strong individual passwords are important, but general password hygiene is even more important.

One of the tricky parts here is remembering all of websites on which you have accounts. I probably have hundreds. Here are places you can scan to jog your memory.

  • Your password manager
  • Your cookies: go into your web browser settings, and scan the domain names of your cookies.
  • Account confirmation emails: search your email for words like ‘registration’ and ‘verification’.

Once you have an idea of where all you have accounts, fix those passwords up.

  • Are you using a password manager? If not, get one. 1Password is pretty good, but there are free and open source options too, like Padlock.
  • Have you used the same password on any two websites? If so, fix that now.
  • Go though your most sensitive or important accounts (banks, email, cell provider), and change those passwords for good measure.

Conclusion

There, don’t you feel better already? That’s just step one. There’s still lots of cleaning to do, but that will have to wait for a future blog entry.

Migrating CloudBleed impacted static websites to Firebase Hosting

Posted by Jen Tong on February 24, 2017

So CloudBleed is a thing, and it’s a bummer for a lot of big websites. But, it’s also a bummer for countless tiny websites that use Cloudflare for Flexible SSL. You know, all those static websites for side projects and silly artsy things. Many of them follow this recipe:

This recipe is awesome for so many reasons. It’s on your own domain, CDN delivery just works, and it’s almost free: all you pay for is the domain registration. I used it a lot myself. But in light of CloudBleed, it’s a good time to consider other options. Here’s the recipe I’m pitching:

  • Static HTML site, likely generated by Jekyll (nothing changes here)
  • Hosted on Firebase Hosting
  • Domain mapped to a your custom domain name
  • Https provided by Firebase Hosting

Why Firebase Hosting

I’m biased (I work for Google), but honestly I don’t know of any other options for free static website hosting that also provide domain mapping and SSL. But here are some cool things about Firebase hosting anyway:

  • The Firebase part is free, so it won’t cost you any more[1].
  • You get real TLS, so you don’t have to feel dirty about using Flexible SSL any more.
  • You get redirects and rewrites!
  • You can lift-and-shift your site with minimal effort, and probably be done by later this evening.

[1] It’s free for sites under 1GB of stuff, and 10GB of traffic. This more than covers all my side projects.

Migration instructions

Oh? So I’ve convinced you to give it a spin? Follow me on a dinosaur filled adventure of static site migration as I migrate dinopacks.com, a silly art experiment with ~10 mb of HTML and images. Once in a blue moon it’ll get a spike of traffic from who knows where, but it generally matches the traffic patterns of my other side project websites.

The files for Dinopacks were previously hosted on Google Cloud Storage, but in an earlier incarnation the files lived on GitHub Pages. It also used Cloudflare Flexible SSL.

Migrating website data

There’s no reason your site can’t be published twice, so start by copying your website data to Firebase Hosting. Once you verify it works, you can move traffic over.

I was able to stick to the Firebase Hosting docs through the whole process.

  1. Go to the Firebse Console, and sign up if you haven’t already.

  2. Create a new Firebase project. You need one for each static website.

  3. This is where you could upgrade to a pay account, but if your site is low traffic like Dinopacks. The free Spark plan will work fine.

  4. Attempt to install (or in my case update) the Firebase CLI.

    $ npm install -g firebase-tools

  5. Fix your npm permissions, which always seem to get weird on macOS.

    $ sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}

  6. Successfully install the Firebase CLI

    $ npm install -g firebase-tools

  7. Authenticate the Firebase CLI.

    $ firebase login
  8. Change into your Jekyll project directory
  9. Make a tiny change to your website, like adding an HTML comment somewhere. This is a marker you can use later to verify that all of your traffic is going to the new host

  10. Init Firebase hosting. You probably only need to diverge from the Firebase CLI defaults once: tell it that your public HTML is in Jekyll’s default directory, _site.

     $ firebase init
 🔥🔥🔥🔥🔥 🔥🔥🔥🔥 🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
 🔥🔥        🔥🔥  🔥🔥    🔥🔥 🔥🔥       
 🔥🔥🔥🔥🔥   🔥🔥  🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
 🔥🔥        🔥🔥  🔥🔥    🔥🔥  🔥🔥        
 🔥🔥      🔥🔥🔥🔥 🔥🔥     🔥🔥 🔥🔥🔥🔥🔥   ...
            
 You're about to initialize a Firebase project in this directory:
    
     /code/dinopacks.com/
    
 Before we get started, keep in mind:
    
     * You are currently outside your home directory
    
 ? What Firebase CLI features do you want to setup for this folder? Database: Dep
 loy Firebase Realtime Database Rules, Hosting: Configure and deploy Firebase Hos
 ting sites
    
 === Project Setup
    
 First, let's associate this project directory with a Firebase project.
 You can create multiple project aliases by running firebase use --add,
 but for now we'll just set up a default project.
    
 ? What Firebase project do you want to associate as default? dinopackscom (dinop
 ackscom)
    
 === Database Setup
    
 Firebase Realtime Database Rules allow you to define how your data should be
 structured and when your data can be read from and written to.
    
 ? What file should be used for Database Rules? database.rules.json
 ✔  Database Rules for dinopackscom have been downloaded to database.rules.json.
 Future modifications to database.rules.json will update Database Rules when you run
 firebase deploy.
    
 === Hosting Setup
    
 Your public directory is the folder (relative to your project directory) that
 will contain Hosting assets to be uploaded with firebase deploy. If you
 have a build process for your assets, use your build's output directory.
    
 ? What do you want to use as your public directory? _site
 ? Configure as a single-page app (rewrite all urls to /index.html)? No
 ✔  Wrote _site/404.html
 ✔  Wrote _site/index.html
    
 i  Writing configuration info to firebase.json...
 i  Writing project information to .firebaserc...
    
 ✔  Firebase initialization complete!
 $
  11. With that done, you should verify that your site works by going to http://<your project>.firebasepp.com. For example, I went to https://dinopackscom.firebaseapp.com to make sure Dinopacks made it up successfully.

Yay! The content is migrated. That was easy, wasn’t it? Now for the fun part: monkeying around in DNS.

Custom domain stuff

Assuming you want to preserve all those juicy inlinks, you need to migrate your domain name. This part will take a little longer.

  1. Go back to the hosting console for your project, click the Custom Domain button, and fetch the special TXT domain verification record.

  2. You can keep using Cloudflare for DNS, and their fast updates make this process quicker. Go to Cloudflare and add the TXT record. Use an @ to specify TXT records on the root domain.

  3. Wait a few minutes for the TXT records to propagate. You can verify them using the dig command. Correctly set up records should look something like this:

    $  dig TXT dinopacks.com
   
; <<>> DiG 9.8.3-P1 <<>> TXT dinopacks.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
   
;; QUESTION SECTION:
;dinopacks.com.			IN	TXT
   
;; ANSWER SECTION:
dinopacks.com.		300	IN	TXT	"google-site-verification=xWOK-correct_XHorSe09bHSbaTTeryXStapLEA"
   
;; Query time: 53 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Fri Feb 24 15:21:15 2017
;; MSG SIZE  rcvd: 108
  4. Return to the Firebase Hosting console and click Verify.
  5. You have a couple options now: You can add a second TXT record and have a seamless transition (Advanced), or be lazy and accept a security warning for a few minutes (Quick setup). I opted for quick setup, and the warning was gone within a few minutes.
  6. Next, change your A records at Cloudflare to point to the IP addresses provided by Firebase Hosting. Make sure they’re configured to ‘DNS Only’, and not using the reverse proxy. If you have any CNAME aliases, remove them.
  7. Wait for them to propagate. Remember that marker you added up above? It’s a good way to know that things have migrated when viewed from mobile devices. This is also a good time to click around and make sure everything still works.

Cleanup

You’re done! Well, mostly. You could stop now, or you could take a moment to clean up all the clutter you left behind.

  1. Remove those TXT records that you added for domain verification. They’re benign, but they don’t need to be there any more.
  2. Delete the files at your old host. For me this involved deleting the Google Cloud Storage buckets that previously served my content. I could have done this with the command line interface, but I opted to do it from the console’s web interface.
  3. Update your deployment scripts to use firebase deploy.

What ifs?

Call me paranoid, but I’m always cautious about using free services. I do a ‘what if’ thought exercise on their limitations.

  • What if I get a huge spike of traffic and I exceed the Spark plan transfer limit?
    • Pay a few bucks to upgrade to a paid Firebase plan.
    • Or, since Cloudflare is probably still your DNS, you can enable their reverse proxy to reduce load. And yes, I realise the irony of that suggestion.
  • What if I run into a weird problem and I can’t find a solution on Stack Overflow?
    • Use one of your support tickets. (Something I actually did when migrating mimming.com, which had some legacy Firebase weirdness from past adventures.)

Conclusion

So now you’re migrated to another provider, you’re probably not paying any more, and you’re using proper SSL. Doesn’t that feel great? And if you decide you don’t like it, it’s just as easy to move to a different provider later.

If you found this tutorial helpful, let me know! If you have a better place to move your side project static websites, let me know that too. I’d love to share more options with people.

Update

I asked you all for other hosting recommendations, and provider got lots of recommendations: Netlify. I haven’t used them, but they look like another great option to consider.