Thursday, July 31, 2014

Password utopia - finally!

Passwords - what a pain.

Bajillions of websites, different usernames, work projects and their environments and their passwords...how the hell are you supposed to keep track of all of it. And then a dozen different machines that you work on... and need access to your passwords

Each of us have their own mechanisms - plain text file 'hidden' some place to slightly more advanced ones. For the longest of times, I used to have a GPG encrypted text file sync'ed over my github repository. It was simple and did the job though used to be a little painful to get started off on a new machine (needed to have my gpg keys etc and git set up and so on.). Also, it didn't help in the password generation department

In between, I've played with other tools like pass - but then cross platform is a must and that didn't work. Purely command line is good but a pain to deal with.

So here's what my password-utopia looks like:

  1. passwords are automatically synced
  2. accessible anywhere - linux, windows, android and CLI interface
  3. Key secured if possible with GPG
  4. search over saved passwords
  5. Browser helpers to automatically fill in usernames/passwords
  6. Generate strong passwords

Keepass2 does all of the above - after initially dabbling with it, I've now moved all my passwords on to it. you can use Dropbox, Google drive or any other cloud sync tool to sync your passwords across machines. kpcli provides cli access and you have KeepassDroid on android. There's a mono version for Linux but I found that slow and clunky. KeepassX nightly ppa has support for kdbx database files and while a little lacking in features, it works much better for me on Linux.

Securing the Keepass2 database - you can use a password and a key file combination. You could also use your windows account but then I think cross platform compatibility is lost. anyway, random key file + strong master password is quite ample for my needs.

Sunday, May 18, 2014

Weekend with yeoman, grunt, bower and oh so much more

Weekend with Yeoman

So it started with a post on reddit (something that I spend too much time on.) about an interactive Angular JS tutorial. It's been some time since I played with Angular and decided to spend some time on it. One website led to another and I eventually got around to Yeoman. So ended up digging into Yeoman a lot more than anything else. Given our status at work building brewmaster and scheduler, and our architecture where the front end is just consuming REST services, we might be able to move to a pure Nodejs front end. The ever present question of course is doing a rewrite vs adding features!!!

Anyway, plan to spend some more time with Yeoman and friends and on Angular too.

Hey - and did I mention - I also flew kites with my kids - awesome fun! Brought back my childhood memories of running around the streets of Lucknow trying to catch kites!

Wednesday, May 14, 2014

Nginx reverse proxy with SSL offloading and authentication

What's it

Recently we've started down the ElasticSearch/Kibana road and also had a handful of other node.js apps. Setting up access control for these was becoming a pain - especially with ES which doesn't come with any authentication/security out of the box. General advice on the interwebs is to let upstream server handle authentication and SSL + basic auth is good enough.

Install nginx

  1. sudo apt-get install nginx apache2-utils Apache2 utils is for generating the htpasswd file for use later.

Configuring nginx

There's a few things to handle:

  1. we want SSL offloading to happen
  2. Each application is going to be set up as it's own virtual host - so think app1.mydomain.com, app2.mydomain.com
  3. All apps will be served on SSL. HTTP requests will be forwarded to HTTPS automatically.

Password db

You can create the password db with

htpasswd -c /etc/nginx/passworddb <username>

You'll be asked to confirm a password for the user and you're all set.

Reverse proxy server variables

See the last one setting a few other server variables - X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto? You'll need this if the app you're serving is written to be reverse proxy aware - in that case, it would use these headers to generate any links in the html it generates (so that it doesn't return a document with http://internalhost:port/path - and instead returns http://reverseproxyhost/path). If the app you're proxying doesn't do this, then you're in the realm of output content rewriting (basically regex the output content and replace link - ughhh!)