A True Hacking Story

History

When I first setup my 550 MHz PIII computer to dual boot FreeBSD 5.2.1 along with the Microsoft Windows XP operating system, one of the first things I did was set up an SSH daemon. I could access all of my files remotely and with complete confidence of security. Life was gravy.

One of the next things I noticed was the mammoth amount of password guessing that was taking place every 15 minutes or so by computers all over the world. Eventually I learned that this was a worm trying to get into any computer with SSH open, but it made me start thinking "what if someone guessed the password to my computer?

The Program

It was this thinking that lead me to design a second security system inside the shell. While at it, I wished to investigate the possibility of using a constantly changing password. After a day of fiddling with different techniques, shells, and password protections, it was done. The only question was, did it work?

I knew that letting someone inside of the shell at all was a huge security risk, but I felt that I locked everything down in such a way that the user would be required to go through my additional security program. Confident in that at least it would be a stumbling block, I released my server's location, a valid user name, and a valid password to Freeshell users.

The security program itself was very cryptic. I've heard the argument that "obscurity is not security" as many times as the next guy, but I would argue that it definitely helps. The login process was as follows:

Login: crackme
Password: ********

Welcome.
[user entry]
abregqzxom
[user entry]
--Connection Killed--

What was happening was this: First the user 'crackme' would log in with the password I provided. That triggered my security program to run, which opened with 'Welcome.' and paused there for a user input. This first entry was actually another password!

Regardless of the correctness of the password the user was presented with a random string of letters. This string of letters was the answer to the second entry, a varying password! This worked much like a DST challenge code is used to start vehicles whose keys have a microchip implanted in them.

In this particular case I was simply using my memory system as a hashing algorithm to quickly convert the above text to a number. In the above example the answer would be: 94770703. The conversion is fast and easy to perform (it takes under 10 seconds to perform), while providing a very strong password.

The beauty of the above system is that it makes password guessing almost entirely impossible. The attacker could try to guess at the password for all eternity, but since it changed each use the attacker would not stand a chance. Then, just to further deter the attacker, there are two passwords. What makes the task even more impossible is that, because of the obscurity and cryptic nature of the setup (i.e. it's entirely unique and therefore has no standard), the attacker is left in the dark as to if he is making any headway.

Results

Obviously I really did not expect that anyone could possibly get through the added password protection. What I expected was for someone to find a way around it.

Someone did find a way around it. In fact, it turned out to be the system administrator of freeshell, Stephen Jones! It took him less than 15 minutes to discover that all he had to do was use sftp to replace the .login file (which called the security program) with a standard .login file.

I was actually on the computer at the time it happened, and was very surprised to get a message from him. He later helped me turn SFTP off on that account and after that no one else was able to break through.

Conclusion

A randomly varying password is considerably more secure than the common passwords we use everyday. They come at a price of that the individual must design their own password algorithm in order for it to be effective, which means that they will probably never become common.

More importantly, the most secure place to add advanced password protection is on the outside before the user has been given access to the shell. Security on the inside of a shell is going to be much easier to crash than that which is on the outside, as 'smj' (Stephen Jones) was able to prove.

Finally, I would say that this experiment provided 'proof of concept', hopefully causing a few others to make their own while keeping in mind the lessons learned here. Eventually, I would like to try this again by integrating this concept into my SSH daemon's source code.

© 2005 Nic Reveles
Updated

Valid HTML 4.01 Transitional

Valid CSS!