Little 418


The resulting entity body MAY be short and stout

Personal Information Spring Cleaning: Auth and Passwords

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

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.


Moving around the filesystem in vim

I’m a bit of a vim junkie. Many years ago I was forced to use it in my CS101 class because it was the only text editor available. The first month was pretty rough, but that was probably because we were writing Java without an IDE. Anyway, once I got the hang of it, I was hooked.

I never studied how to be effective with vim, but instead I’ve added a trick here or there over the years. Even 16 years later, I’m still adding tricks to my vim quiver.

My latest new trick is navigating around the file system inside a vim buffer. It feels a bit awkward at the first, but once you get the hang of it, it’s a lot faster than using the OS GUI to find files.

Moving between files

I used open a new vim process from bash, make edits, :wq, find the next file, and repeat. It turns out there’s been a better way the whole time – the edit command: :e.

You give it a file name, and vim switches the buffer that file in the current directory. If the file does not exist, vim will create a new file when you write it.

:e dinosaurs-are-awesome.txt

You can also give it a path to edit a file somewhere else.

:e /secret-stuff/embarassing-fanfics/harry-potter-and-the-cursed-meteorite.md

And use escape sequences to cope with filenames that contain spaces.

:e ~/Downloads/ProposalDeck\ finalVersion\ Copy\ 2.doc

If you made some edits in your current buffer, but want to ditch those changes, add a ! just like you do in a :q!, a.k.a. the only vi command that emacs users know.

:e! philosoraptor.meme

Oh, and if you’re not using tab completion here, you’re missing out. Tab completion works for filenames and directories. Consider it an added incentive to start your commonly edited files and git repos with distinct letters.

Moving between directories

If you know where you want to go, use the :cd command. If you kind of know what you want, use :cd and abuse tab completion.

:cd /tmp

If you have only a vague idea of what you want, you can navigate around directories with the :e command.

:e .

Which yields a screen like this:

Pressing enter opens whatever is under the cursor.

You can move around with arrow keys, but that’d be a sin against vim. Instead, use your vi file navigation-fu. Most of it works, including moving to line number (:42), regex searches (/[hHarry]), and even macros (qa↑↑↓↓←→←→q).

Setting a different default directory

By default vim will start it’s directory context in your home directory. This is a reasonable default, but if you want something different, just add a :cd command to your .vimrc.

:cd ~/dinosaur-fanfics/

Conclusion

So yeah, so that’s how you can move around in vim. It’s also a core feature that I somehow avoided for 16 years.

vim users: Are you still picking things up? If so, tell me about something you picked up recently :)

Non-vim users: 1) why are you still reading? 2) How do you tolerate other text editing interfaces?