.

Storing and Retrieving Strong Passwords Securely

<<

sil

User avatar

Hero Member
Hero Member

Posts: 551

Joined: Thu Mar 20, 2008 8:01 am

Location: ::1

Post Tue Jul 20, 2010 2:11 pm

Storing and Retrieving Strong Passwords Securely

After reading the post on "Storing Passwords" (http://www.ethicalhacker.net/component/ ... .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:

  Code:
strategos ~ # cat MASSIVE_WORDLIST
word-one
word-two
strategos ~ # for i in `cat MASSIVE_WORDLIST` ; do for j in `seq 1 5` ; do echo $i$j ; done ; done
word-one1
word-one2
word-one3
word-one4
word-one5
word-two1
word-two2
word-two3
word-two4
word-two5
strategos ~ # for i in `cat MASSIVE_WORDLIST` ; do for j in `seq 100 105` ; do echo $i$j ; done ; done
word-one100
word-one101
word-one102
word-one103
word-one104
word-one105
word-two100
word-two101
word-two102
word-two103
word-two104
word-two105


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?

  Code:
h0tm@!lth!$!$$3cr3t
tw!tt3rth!$!$$3cr3t
w0rk$!t3th!$!$$3cr3t
myb@nkth!$!$$3cr3t


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/info ... swords.htm
<<

hayabusa

User avatar

Hero Member
Hero Member

Posts: 1662

Joined: Mon Jan 29, 2007 2:59 pm

Post Tue Jul 20, 2010 3:26 pm

Re: Storing and Retrieving Strong Passwords Securely

Interesting methodology, sil.

And so long as you keep them long enough, character-wise, that a generated list doesn't quickly hit them, etc, it's quite an impressive way to 'memorize' all of your various codes / passwords / passphrases.  

I think I'd go one step further, in that I wouldn't, for instance, on 20 servers, necessarily use the domain names, etc, as a quick snooper, or keylogger, might quckly catch on to the methodolgy, if they spotted two (or more) servers that ended with such similar characters in their passwords.  I think I'd more likely use serial numbers or MAC addresses, as you'd noted, that at LEAST put more randomness into the scheme.  (If someone's got a keylogger on you, you've got worse problems, but the point being, too many extrmely similar codes might be a giveaway to methodlogies and conventions.)

But, definitely, for the most part, I think it's a concept worth noting, and using.

Thanks.
Last edited by hayabusa on Tue Jul 20, 2010 9:24 pm, edited 1 time in total.
~ hayabusa ~ 

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'


OSCE, OSCP , GPEN, C|EH
<<

Ketchup

User avatar

Hero Member
Hero Member

Posts: 1021

Joined: Fri Jul 04, 2008 7:44 pm

Location: Philadelphia, PA

Post Tue Jul 20, 2010 3:55 pm

Re: Storing and Retrieving Strong Passwords Securely

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.
~~~~~~~~~~~~~~
Ketchup
<<

UNIX

User avatar

Hero Member
Hero Member

Posts: 1244

Joined: Mon Apr 28, 2008 9:20 am

Post Wed Jul 21, 2010 2:02 am

Re: Storing and Retrieving Strong Passwords Securely

Nice write up, sil. Though personally I wouldn't go with hostnames or similar, nor I think that substituting the same characters every time is that good. As stated by hayabusa, once one or more passwords somehow got retrieved, it shouldn't be too hard to map it to others, which then again can easily be done in a automatic method, e.g. by using regex. Also you have to consider that bruteforce/ dictionary-attacks/ et cetera are not the only ways to retrieve a password.
Last edited by UNIX on Wed Jul 21, 2010 2:04 am, edited 1 time in total.
<<

sil

User avatar

Hero Member
Hero Member

Posts: 551

Joined: Thu Mar 20, 2008 8:01 am

Location: ::1

Post Wed Jul 21, 2010 8:01 am

Re: Storing and Retrieving Strong Passwords Securely (take 2)

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:

  Code:
misos:~# hostid
040ac340


For the MAC address:

  Code:
misos:~# ifconfig eth0 | sed -n '1p' | awk '{gsub(/:/,"");print $5}'
001422088E19


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:

  Code:
#!/bin/sh
host=`hostname`
mac=`ifconfig eth0 |sed -n '1p'|awk '{gsub(/:/,"");print $5}'`


printf "\n\nPlease enter a password\n\n"
read pass

clear ; echo "Creating password"
sleep 2 ; printf "\n\n"

printf "Your password is:\n\n"

echo `hostid`.$pass.$host.$mac | sed 's:a:@:g;s:e:3:g;s:i:!:g;s:o:0:g;s:s:\$:g'


Let's see it in action:

  Code:
strategos ~ # sh /tmp/leetpass

Please enter a password

test
Creating password


Your password is:

00ff0101.t3$t.$tr@t3g0$.001d09f25317


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?

  Code:
strategos ~ # echo password|md5sum
286755fad04869ca523320acce0dc6a4


The hash becomes my password:

  Code:
strategos ~ # passwd test1
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

strategos ~ # grep test1 /etc/shadow
test1:$6$HbcA2uDP$WRp6Zne8mK9vELSZGTrFX05GrXV6/QLH4PpjOr1X8vQppUSIpsTmBnxfsPPlCUOuuX8HvGydQ9PTtEJfarAQo/:14811:0:99999:7:::


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...
<<

yatz

Full Member
Full Member

Posts: 222

Joined: Tue May 25, 2010 2:58 pm

Post Wed Jul 21, 2010 8:18 am

Re: Storing and Retrieving Strong Passwords Securely

You could do that.....

Or just use a recommended lengthier-than-normal password with special characters and you'll be fine.

To me a password like sil.Is@wes0m3 will take the same effort to hack than any of the 20+ character passwords listed above.  They are all vulnerable to sniffers, pass the hash, and other tools, only a 20+ character password is harder to brute force.  I don't see a need to have overly complex passwords when the recommended with a little flair is all you really need.
"Live as though you would die tomorrow, learn as though you would live forever."

CCNA, MCSA, MCTS, Sec+, Net+, Linux+, CEH
<<

hayabusa

User avatar

Hero Member
Hero Member

Posts: 1662

Joined: Mon Jan 29, 2007 2:59 pm

Post Wed Jul 21, 2010 8:23 am

Re: Storing and Retrieving Strong Passwords Securely

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/
~ hayabusa ~ 

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'


OSCE, OSCP , GPEN, C|EH
<<

sil

User avatar

Hero Member
Hero Member

Posts: 551

Joined: Thu Mar 20, 2008 8:01 am

Location: ::1

Post Wed Jul 21, 2010 10:12 am

Re: Storing and Retrieving Strong Passwords Securely

yatz wrote:You could do that.....

Or just use a recommended lengthier-than-normal password with special characters and you'll be fine.


The issue with that is in the transport of the password. If at some point in time there is no hashing involved and your password is circulated unencrypted, you'd be hit. For example, here is an internal ticketing system for customer service in my department. They have the ability to use SSL - however, admins are too lazy to enforce this. So what can I gather here? (obviously I sanitized the name, etc)

awk '/username/{print $7}' /var/log/httpd/access_log
?username=jdoe&password=l33tp4ssw0rd&login=Login

See where the problem lies. Instant access. However imagine if I had no choice BUT to send cleartext:

awk '/username/{print $7}' /var/log/httpd/access_log
?username=jdoe&password=290191d96045747f84cb4ca71b9cba33&login=Login

echo "johndoe"|md5sum
290191d96045747f84cb4ca71b9cba33

Most attackers seeing that (290191d96045747f84cb4ca71b9cba33) would likely set out to break that thinking its a hash while in fact its the password.
<<

hayabusa

User avatar

Hero Member
Hero Member

Posts: 1662

Joined: Mon Jan 29, 2007 2:59 pm

Post Wed Jul 21, 2010 10:27 am

Re: Storing and Retrieving Strong Passwords Securely

<grin>  sil has an extremely valid point.
~ hayabusa ~ 

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'


OSCE, OSCP , GPEN, C|EH
<<

yatz

Full Member
Full Member

Posts: 222

Joined: Tue May 25, 2010 2:58 pm

Post Wed Jul 21, 2010 10:52 am

Re: Storing and Retrieving Strong Passwords Securely

sil wrote:Most attackers seeing that (290191d96045747f84cb4ca71b9cba33) would likely set out to break that thinking its a hash while in fact its the password.

I have to admit, this made me smile.

Actually I saw this idea once when I was reverse engineering an activation key for some proprietary software a little while ago.  It performed an encryption algorithm to get the activation key and then hashed the output of that to perform password comparisons (or something along those lines).  Problem was, all this was stored in the database in the same table where it was obvious one related to another.  With the provided dlls (Cryptography.dll??? <- again, nicely done vendor!) I was able to decrypt everything that could be decrypted and the hashes all came out nice and easy.

Back to the point though, what is the application of this?  The only time you need this level of obscurity is when something will be displayed in plain text.  I'd imagine you'll have to look up the password every time you use it, or perform the hash every time if you remember the hashed string, so additionally it will probably be for systems that you don't use all that often.

And if you want to use psychology to trick the attackers, often you will out think the users.  If the admins are using telnet when they could be using ssh, what's the point?  It's the same as forcing users to use complex passwords and in response they simply write it on a post-it and tape it to their monitor.

All I'm saying is that it's give and take.  It also depends on what you're protecting.  This may be preferred for top secret database admin credentials to a research lab, but for the average system a simple complex password should be sufficient.
"Live as though you would die tomorrow, learn as though you would live forever."

CCNA, MCSA, MCTS, Sec+, Net+, Linux+, CEH
<<

sil

User avatar

Hero Member
Hero Member

Posts: 551

Joined: Thu Mar 20, 2008 8:01 am

Location: ::1

Post Wed Jul 21, 2010 11:06 am

Re: Storing and Retrieving Strong Passwords Securely

yatz wrote:Back to the point though, what is the application of this?  The only time you need this level of obscurity is when something will be displayed in plain text.  I'd imagine you'll have to look up the password every time you use it, or perform the hash every time if you remember the hashed string, so additionally it will probably be for systems that you don't use all that often.

And if you want to use psychology to trick the attackers, often you will out think the users.  If the admins are using telnet when they could be using ssh, what's the point?  It's the same as forcing users to use complex passwords and in response they simply write it on a post-it and tape it to their monitor.


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.
<<

charliemong

User avatar

Newbie
Newbie

Posts: 27

Joined: Wed Aug 25, 2010 10:49 am

Location: UK

Post Fri Dec 03, 2010 11:12 am

Re: Storing and Retrieving Strong Passwords Securely

Have learned something new today thanks guys. Did not know about the 20+ character password brute force thing. Thanks guys will keep reading your posts and learning new ideas. As someone wise once said you have to keep learning.
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.
- Sun Tzu

Return to Physical Security

Who is online

Users browsing this forum: No registered users and 0 guests

.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software