Sunday, September 13, 2015

"level up" your passwords

Let's face it, passwords %@#$!

"Normal people" don't like dealing with them. "Security people" know they aren't even secure in the first place [1].

While there is research into replacing passwords with a better form of personal authentication in the future [2] [3] [4],  50+ years of the familiar "username / password" user interface [5] is deeply entrenched in computing and isn't going away any time soon.  So what can you do to make your personal passwords as secure as possible?

Today, in honor of the 30th anniversary of the classic video game “Super Mario Bros”, let's gamify your quest for secure passwords and see how far you can "level up"...


Level 1 : Don't share.

Simple enough, don’t intentionally share them with others.  But also be aware that you may unintentionally give them to others via social engineering, responding to phishing, or using them on a computer infected with keyloggers, spyware or other malware.  Also be careful when using them on public terminals or any computer you don’t trust as your own.

Level 2 : Don't save unencrypted.

We have a hard time remembering all of our passwords, so it seems natural to save them somewhere as a backup.  But saving them in a text file or spreadsheet that isn’t strongly encrypted allows others on the computer or malware to get access to them too.  That goes for your web browser “remember password” feature and saved password vault too, it isn’t secure so don’t use it.

Level 3 : Size DOES matter.

The next step is to make sure your password isn’t easy to guess.  Many know you shouldn’t use dictionary words or other common patterns, part of your name, important dates, and even "1337 speak" number substitution is easy for a computer to guess.  Many also know to use a good mix of character types including upper and lower case letters, numbers, and special characters.  But the most important factor is length.  Size matters, a lot.  All passwords can be cracked by a computer given enough time, using passwords (much like encryption) is really just a delay tactic.  The least easily guessed password would be a randomly generated string incorporating all types of characters that is as long as possible.  When creating passwords, they should be well into the double digit length territory.

Level 4 : Close backdoors.

So now that you’ve strengthened your password, what are ways an attacker could bypass it?  A common backdoor is the “forget your password” procedure on websites.  When using “free” online services, there is usually little to no real customer support.  So the same ways those services make it easier (read: cheap) to reset a forgotten password also make it easy for an attacker to take over the account.  Never use real answers to those security questions, they are often easily guessed or found online.  Treat them just like your password, random long values.

Level 5 : Break the chain.

Another common password recovery procedure is sending a password reset link to an email address or mobile text message.  This creates a chain of dependencies between multiple accounts, and like all chains the weakest link will compromise the rest.  Are all of your secondary account passwords just as secure as your primary one?  Think through what would happen if you lost your password and how you would retrieve it, can an attacker easily use that same process?  Even worse, usernames on these sites are commonly just an email address, probably the same email address the password reset links go to, just making it that much easier for an attacker to know which email account to target next.  A smart attacker will use information from one service to attack an account on another service.  When possible, use a unique secure email address unknown publicly by others for the single purpose of password recovery.

Level 6 : Don't reuse.

It seems like every day now in the news another popular website has been compromised and attackers publish all their customer’s usernames and passwords, or worse(?) the attackers stay quiet and keep the passwords for themselves.  As a customer, there isn’t much you can do about that.  However, you can minimize the impact by not using the same password for multiple accounts.  Contain the exposure to just that account, don’t allow an attacker to use that same password to compromise your other accounts.  But how can you possibly remember long, random, and unique passwords for the hundreds of computer and online accounts you have?

Using a secure password safe/manager is the best solution today.  It allows you to store all of your passwords, account information, and other sensitive data in a small database using strong encryption.  To decrypt the data you must setup a (yes, yet another…) password, but this “master password” is the only one you really need to remember going forward, all of the others stored in the safe can be accessed when needed and purged from your brain.  These tools also make it easy to generate strong random passwords with very long lengths, and since you don’t need to remember them anymore, why not max them out?  Popular personal password safe tools include: Password Safe [6], KeePass [7], 1Password [8], and my favorite LastPass [9].  Since most of us need to access our passwords from multiple devices and locations, many of these tools will sync your password safe between devices via cloud services.  Yes, keeping a copy of all your passwords in the cloud sounds risky, and certainly does open up a new threat, but it also makes them more available which means you’re more likely to keep using the tool and thus keep your multitude of password accounts secure.  Since that “master password” is so important, especially in the cloud, a good tool like LastPass will employ TNO “trust no one” encryption where the cloud service doesn’t know your decryption key password, IP address access controls, audit logging and alerting, multi-factor authentication, checking for duplicate, weak, or passwords that haven’t been changed in a long time, and many other layers of security features.  Many security experts have found that an acceptable risk for the security benefits it provides, but at the end of the day it is a personal decision.  Lastly, because that master password is so important, think through ahead of time what you’d do if you lost it, again the chain of dependencies.  You wouldn’t want to lose all access to all your accounts, so it might be the rare time when keeping a physically written copy of the master password offline in a secure locked location is a very good idea.

Level 7 : Change often.

As mentioned already, no matter how strong your passwords are, passwords are just a delay tactic, given enough computing time any password can get cracked.  Eventually it will get brute force guessed, the website with weak encryption it was stored on hacked, or maybe you've fallen for a phishing attack, social engineering, or keylogger/spyware malware and you don’t even know it.  So reset that ticking clock by changing your passwords periodically.  Some of the password safe tools support automatically changing them for you.  If you aren’t already using randomly generated passwords, the act of changing your password can get very emotional.  There is a certain psychology behind the passwords people create and the emotional bond they have with them as described in an interesting article [10], which can lead people to never change them.  Break that cycle, especially with your safe’s master password.

Level 8 : Use Multi-Factor Authentication.

Multi-factor authentication, also known as two-factor authentication, two-step verification, login verification, or login approval, has been around for a while but has really gained mainstream popularity recently.  We’ve already concluded passwords are insecure, and not going away anytime soon, but multi-factor authentication is a good compromise for now.  A "factor" is a type of authentication method, commonly either a knowledge factor (something you know), a possession factor (something you have), or an inherence factor (something you are, biometrics or location based usually).  Using "multi-factor" authentication, requiring two or more of the previously mentioned factors to be verified successfully, offers a much higher level of assurance.  When using multi-factor authentication an attacker must both steal your password and also something the you physically have in your possession or impersonate who you are physically, much less likely to occur.  Common implementations include a hardware dongle that generates a one time use code every minute, or an app you install on your mobile device to approve logins, or a one time use code sent to your phone via a text message.  This is such a huge improvement over simple passwords it is advised to turn it on for every account that supports it, especially for password safe accounts like LastPass or any account used in your account password reset chain described earlier.  But again first take some time to think about what you’ll do if you lost ability to use your second factor device, that you have a Plan B backup in place, and that it is just as secure from attackers.


Well, how did you do?  Which level did you get to?  Did you save the prince/princess (by securing your personal passwords) or is he/she in another castle?


[1] "Kill the Password: A String of Characters Won’t Protect You" - http://www.wired.com/2012/11/ff-mat-honan-password-hacker/
[3] "Secure Quick Reliable Login" - https://www.grc.com/sqrl/sqrl.htm
[4] "Your Brain Waves Could Replace Passwords" - http://techcrunch.com/2015/06/04/your-brain-waves-could-replace-passwords/
[5] "The World’s First Computer Password? It Was Useless Too" - http://www.wired.com/2012/01/computer-password/)
[7] KeePass - http://keepass.info/
[9] LastPass - https://lastpass.com/


Sunday, August 18, 2013

Huell Howser Roku Channel

In honor of Huell Howser, I wrote a free private Roku Channel to stream his episodes.  It was my first stab at Roku development, but I think it turned out quite well.  It provides a nice interface on your TV to access the videos archived by Chapman University (http://blogs.chapman.edu/huell-howser-archives/).  You can search for episodes, or my favorite just click the random button to roll the dice and marathon episodes in random order.

To add it to your Roku, login to your account at https://my.roku.com/account/add and type in "Huell" on the Add Channel screen or go to https://owner.roku.com/add/Huell













Thursday, December 16, 2010

WebPasswordSafe

What began as just a pet project to keep current with software development technologies, to a pet peeve I had with specific tools (or lack thereof) in the IT Security space, to a desire to contribute something beneficial to society via open source in some of my spare time, WebPasswordSafe is targeted for an official 1.0 release around Christmas 2010!  Follow news I post about it specifically on its own blog: http://webpasswordsafe.blogspot.com

Tuesday, September 19, 2006

Mac OSX Tiger unix groups

Step 1 in setting up the development environment on my Mac OSX Tiger system was to make the common directories needed for development shared among both developers. By default, Tiger will create files/directories as writable by only your user and your group (same as username). So for both developers to be able to use tomcat for example, I added group read/write to all tomcat files and directories. Also had to chgrp all files/directories to a common group for both of us as well. At first I read that I could use the "staff" group, because as I read all users should be added to this group by default. On my Tiger installation though, I was sad to see that only the user root was a part of that group.

Adding new groups and associating users to groups using the Mac OSX UI is very difficult, if not impossible. When adding a user I was surprised there was no option to specify the groups that user should be a part of. Tiger has an application until the Utilities folder called "NetInfo Manager" which manages what unix people would recognize as the /etc/passwd and /etc/groups files among other things, from here you can add new user and group, but there was no clear way to associate multiple users to a group using the tool (for current ones, it displayed a comma-separated list of users within parenthesis, and a drop down denoting the users, but I could not create a drop down using the tool). Another dead end. Finally I found the answer in a couple of obscure command line programs (can be found in Mac OSX for Unix Geeks) called nicl and nireport. Here is what I did to add both users to the "staff" group, and created a group just for development of our project called "developer" and it worked...

To add user1 and user2 to the group "staff":
# nicl / -merge /groups/staff users user1 user2

To get a list of all current groups and gid's (so you know which gid to assign next, use the max here + 1):
# nireport . /groups gid name

To create a new group called "developer" (assuming the highest gid in the previous step was 502):
# nicl / create /groups/developer gid 503
# nicl / create /groups/developer passwd '*'

To add user1 and user2 to the group "developer":
# nicl / -merge /groups/developer users user1 user2

Next time you login to the shell, type "groups" and the new groups should show up for either user1 or user2.

Monday, September 18, 2006

New Blog

I've decided to point my main website to this new blog for now, and link my specialized project page, resume, links, etc from it back to my old server. My old homepage hadn't been updated in ages, and I figured it would be easier this way to keep my public and professional persona updated and current.

Also to keep my skills sharpened, I'm starting a couple of new projects that I will use to play around with some new technologies. As you can see I haven't written a complete personal project from beginning to end in years, Chinese Polar Races and PoopieWars! included. I wrote a live recording review site in a day and a half for my old Live Garbage Hub website, it was a quick and dirty tomcat/jsp/mysql application. One of my first projects will be to refactor this quick and dirty site using Hibernate/Spring/Spring MVC. I plan to put this onto Google Code or SourceForge eventually as well. Afterwards, I may explore writing a JSF version as well, but we'll see, as I'm not sold on JSF completely yet. Also a project after getting the hang of Spring/Hibernate will be to write a Web Files type web application that allows one to upload documents and files, but rather than having a strict directory structure, files are tagged (ala flickr and delicious) since documents can have multiple categories and users can search based on these. Along with the Spring/Hibernate backend, I'll move away from the usual http form post/response communication architecture and try out some AJAX (probably Google Web Toolkit, GWT) as the front-end. As the projects mature I'll probably create separate blogs for them on their public source download site, but for now I will post any insights I come across on this blog. I'll be doing Java development on my Mac OSX Powerbook, using Tomcat 5.5.x and MySQL 5 and Eclipse 3.2.