After reading the post on "Storing Passwords" (http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,5766.msg30644/) I decided to come up with a quick and dirty write-up for engineers/admins to always remember their password. I'll call it "Storing and Retrieving Strong Passwords Securely" so should anyone want to copy it or bookmark it feel free to do so.

First and foremost, the biggest hard drive on the planet is your mind. Reliance on technology - while almost second-nature at this point - isn't always the best option. Hopefully this will assist you in being able to 1) create a strong password 2) remember multiple passwords (to the tune of dozens even hundreds) 3) Secure those passwords (after all no one can pick your brain).

For those searching for "password storage systems" there are no shortages to find many helpful even free programs [1,2,3,4]. There are also no shortages on documents explaining why or how to create strong passwords [5]. What I noticed in most documents and even programs is their lack of creativity. Let's be realistic, no one wants to remember $#.()p@%//\\- as a password. This would be an interesting form of mental punishment. Not only would it be mental punishment, but imagine for a moment the following scenario: You need a key safe to store your keys. You go out and buy the strongest one and lose the key... Now what?

Let's take a look at a small shop, say 20 servers. All have a distinct role and we want to keep all machines with a different password on each. We want to do so in the event someone compromises the machine, they're stuck to that specific machine. Or, maybe we just want to torture ourselves and have different passwords. Let's lay out the framework for this company we'll now name Forgetful Inc.

Forgetful Inc. has ten servers running database instances for 5 credit card companies with each server having a redundancy. Let's name them:

Company1.forgetfulinc.com, Company1BU.forgetfulinc.com, Company2.forgetfulinc.com, Company2BU.forgetfulinc.com, Company3.forgetfulinc.com, Company3BU.forgetfulinc.com, Company4.forgetfulinc.com, Company4BU.forgetfulinc.com, Company5.forgetfulinc.com, Company5BU.forgetfulinc.com

The also have 5 other servers for WWW, Mail, Active Directory, ClientServer, Knowledgebase

WWW.forgetfulinc.com, WWWBU.forgetfulinc.com, Mail.forgetfulinc.com, MailBU.forgetfulinc.com, AD.forgetfulinc.com, ADBU.forgetfulinc.com, ClientServer.forgetfulinc.com, ClientServerBU.forgetfulinc.com, KB.forgetfulinc.com, KBBU.forgetfulinc.com

Twenty servers, each with a unique password. Each with a strong password we'd never have to keep stored anywhere other than our brains. Where should we start?

For starters we will need (drum roll): A strong password. The rest is simple. It really boils down to creativity from here.

We'll use password as our framework. (Seriously, password will be our guide here). Using character substitution we'll replace the a with an @ sign, the s with a dollar $ign, the o with a zer0. Typical  "leet speak" leaving us with the password of:
p@$$w0rd and this will be a starting point. Because many experienced security engineers, hacker and crackers will likely have a good list of variants on words, we now move on to making this password more secure.

Using the fictitious domain name, we will do the same. The letter o becomes a zer0, any a becomes an @ sign, the letter i will become ! and so on. We now create f0rgetful!nc from forgetfulinc and we have the second piece. Third piece? You got it, the hostname. Mail becomes m@!l and we're ready for a strong password that can't be forgotten:

m@!l.f0rgetful!nc.p@$$w0rd aka mail.forgetfulinc.password

We now have something that is extremely difficult almost impossible to guess let alone run ANY kind of wordlist against. We also have something extremely difficult to forget, after all if you forget your hostname and domain name, you need more than a password keeper.

For each server we will go through the motions. 20 different servers, each with a unique password almost impossible to crack. The key is to find a suitable password combination. You could use MAC addresses, passwords, etc., whatever you need to do to remember it. It gets easier after a while.

So how does this apply elsewhere. On the personal side of things, let's look at what I perceive to be the average amount of passwords a typical person would have. I'd say 1 for work, 1 for personal e-mail, 1 for say a social networking site, maybe another for Twitter or some other site. Let's say 4 passwords. An issue with people is one of "ease of use" which is where the person will think "no one would ever guess my password is...", since many here are in the security field, I will tell you some of the things I've done to my wordlists which are GB's in size:

Reversed entire words
Massive amounts of regular expressions 's:a:A:g;s:a:@:g;s:a:4:g;s:e:E:g;s:e:3:g;s:e:/=:g' and the list goes on.
Massive amounts of compound words using paste
Massive rehashing of the above with numbers before and after. E.g.: for i in `cat MASSIVE_WORDLIST` ; do for j in `seq 1 2010` ; do echo $i$j ; done ; done

Let's see how the last line works for those curious:


So imagine a 500 million wordlist with most numbered combined or appended to them. For those thinking about appending numbers and getting away with it, its not quite safe. Anyway, back to the password game here. On the personal side of the spectrum, I stated that I needed to remember 4 distinct passwords. Using the same context, here is a fictitious list of sites I have passwords for: Hotmail, Twitter, Worksite, MyBank. Using the same principles:

Hotmail becomes h0tm@!l
Twitter becomes  tw!tt3r
Worksite becomes w0rks!t3
MyBank becomes myb@nk

My password? Thisissecret: th!$!$$ecret Combined?


An eyesore? We could further add a period for a little more complexity:

h0tm@!.lth!$!$$3cr3t
tw!tt3r.th!$!$$3cr3t
w0rk$!t3.th!$!$$3cr3t
myb@nk.th!$!$$3cr3t

Definitely an eyesore, will take some getting used to, but we can create memorable, secure passwords for individual accounts, never store them and always recall them. It's that simple. The hardest part is sticking with a regex you will always recall. Too much complexity will leave you banging your head however, I'd even go as far as making a post-it (purposely because I'm a glutton for punishment) with the regexs and keeping THAT stored somewhere. E.g.: a@, s$, i!, e3 The one thing you can never forget is a password. Meaning don't be afraid to pick your favorite sports team, do it wisely, e.g.: @$tr0$.p@$$w0rd.h0tm@!l

Remembering passwords? Piece of cake. On my laptop, I have a 38 character password combination. Pain to type, easy to remember. Secure as heck. EVERY SINGLE account I have access to, all have a different password. All are well over the 20 character mark and I can recall them at will. Takes some getting used to sure, but remember... You're brain is the safest storage system you have.

Encryption... Different story altogether.

[1] http://passwordsafe.sourceforge.net/
[2] http://keepass.info/
[3] http://www.accessmanager.co.uk/
[4] http://www.passwordsafe.com/
[5] http://operationstech.about.com/od/informationtechnology/tp/Strong-Passwords.htm

This is definitely a good methodology, sil.   I use something similar.  I am a big fan of using sentences I can easily remember.  To me, remembering a word vs remember a sentence requires about the same amount of effort.  Of course, I do add some complexity to the sentences I use. 

Still, I find myself locking out my accounts quite a bit.  While my brain remembers the 20 character password, my fingers don't always cooperate. 

Again, great write up.

Attacking the password(s) by inference can be minimized using a couple of methods here. Using the same password foundation, let's take a look at two different ways to create compensating controls for this using HostID and the MAC address maybe even lowly. MD5 For a descriptive explanation of what HostID is, I suggest the following: "What is a Host ID or Machine ID? How do I find my Host ID (Machine ID) in order to activate or get passcodes for my license?" [1]

Because HostID is unique to a machine, we can use this bit of information for our "leet password" framework. It is something that will not change unlike an ethernet card:


For the MAC address:


These are two bits of information each unique to each machine. The likelihood of someone determining that a password is based on say "HostID"+"MAC"+password is low. Even on an inference attack. But let's assume they did (if they actually did you have bigger issues, but I won't go there), how can we overcome this issue of inference attacks. The answer for me would be "security through obscurity" right about now.

Let's have a view of what someone is doing: "Trying to crack your password" It's almost a given they'll be seeing a hash of some sort and trying to break that hash. How about, a password that IS A HASH.

Let's whip something up really fast and dirty. I'll call it leetpass:


Let's see it in action:


Now, the concern is with someone deducting HOW I created this if they saw it somehow. For starters, they have to enumerate the network and get a list of MAC addresses. Not a difficult thing to do, but what about the HostID field. This is something a bit more difficult to obtain since they'd need to have access to the machine to do so. If they DID and they have the HostID, you'd still be hit. Problematic? Sort of.

What about good old and broken MD5? Most attackers cracking a password are cracking a hashed password. They're going to be encrypting a value and comparing the hash to the hash they have obtained from somewhere: shadow, NTLM, etc. What about if the hash was in front of them the whole time? What if the hash WAS the password?


The hash becomes my password:


Even if they managed to crack it, they'll see another hash. What are the odds of them being confused about this. Cracker: "What the... I just broke that hash!?" ... Runs cracker against another hash. Forget the technology for a moment and jump into psychology for a moment: "Certainly no one would make their password: 286755fad04869ca523320acce0dc6a4" I can see an attacker stating this. So what you've done is you're buying yourself some time here. Let's take this even a step further and use the hash as a password being sent in cleartext. Most attackers would see this and try to find the word that was used to create 286755fad04869ca523320acce0dc6a4 however, the word is pointless since the actual hash IS THE PASSWORD. Security through obscurity? Absolutely. Guaranteed to trick even the most experienced crackers (these are the ones who will look at that hash and know right away its MD5). Think about that for a moment, you're an attacker and you see the following going through the wire in clear text:

286755fad04869ca523320acce0dc6a4
b1946ac92492d2347c6235b4d2611184 (echo hello | md5sum)
ce1ddd1a46197cab6b2c03f8d5526d09 (echo easy | md5sum)

Sure they ran distributed John against the hash to find that ce1ddd1a46197cab6b2c03f8d5526d09 is "easy" however trying to log in using "easy" would get them nowhere really fast.

I've said it once, will repeat, creativity...

I agree with you both, and sil, your points have been well made, throughout.  My only refernce, earlier, was that the hostname / domain name might be a bit easier to guess, particularly if they spotted the similarities in many that someone has entered.  I COMPLETELY agree with where you've gone next, as far as MD5's, etc.

Good writeup, and again, thanks for sharing/

<grin>  sil has an extremely valid point.

Understood which is why I specified: "Let's take a look at a small shop, say 20 servers. All have a distinct role and we want to keep all machines with a different password on each. We want to do so in the event someone compromises the machine, they're stuck to that specific machine. Or, maybe we just want to torture ourselves and have different passwords.

The original write up was geared towards the security engineer/admin/personal(skilled user). People will always be the weakest link period. There is no changing this ever. There is minimizing it (training, etc.) but from an engineering standpoint, for the admins of a server farm, this could work pretty well. From a personal level, it would work too however it all boils down to the personal user and their retention abilities.

A beauty about something like this is one could create a script to recall their passwords and place it on a different machine. E.g. make a low level VMWare Linux machine, write a script, call the script if the password is forgotten. Think of it as a "digital" notepad. Even on an internal basis, one could create an internally visible PHP page to enter a machine name and either create a password or recall a password.

In fact, outside of OTP's, one could create a pretty cool framework where rubber hose crypto wouldn't work as the only method someone could retrieve a password would be to visit the page to see what was generated. The likelihood of someone remember say a 40char password is low. So I definitely understand where you're coming from Yatz, but there is always a solution to most technical problems. If you can't find them (not you per-se) you haven't taken alternative approaches.