Storing and Retrieving Strong Passwords Securely

Viewing 11 reply threads
  • Author
    Posts
    • #5353
      sil
      Participant

      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

      http://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:

      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?

      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/informationtechnology/tp/Strong-Passwords.htm

    • #33859
      hayabusa
      Participant

      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.

    • #33860
      Ketchup
      Participant

      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.

    • #33861
      UNIX
      Participant

      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.

    • #33862
      sil
      Participant

      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:

      misos:~# hostid
      040ac340

      For the MAC address:

      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:

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


      printf "nnPlease enter a passwordnn"
      read pass

      clear ; echo "Creating password"
      sleep 2 ; printf "nn"

      printf "Your password is:nn"

      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:

      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?

      strategos ~ # echo password|md5sum
      286755fad04869ca523320acce0dc6a4

      The hash becomes my password:

      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…

    • #33863
      yatz
      Participant

      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.

    • #33864
      hayabusa
      Participant

      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/

    • #33865
      sil
      Participant

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

    • #33866
      hayabusa
      Participant

        sil has an extremely valid point.

    • #33867
      yatz
      Participant

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

    • #33868
      sil
      Participant

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

    • #33869
      charliemong
      Participant

      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.

Viewing 11 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2022 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.

Sending

Sign in with Caendra

Forgot password?Sign up

Forgot your details?