Typically in OS's that check that passwords are not similar to previously used passwords there is a password history file that contains old passwords in an encrypted form (not one-way) that can be compared against what is entered. Find the password history file, blow it away and create a new one with the touch command and you will have no password history. Phil

-----Original Message----- From: kclug-bounces@kclug.org [mailto:kclug-bounces@kclug.org] On Behalf Of Dave Hull Sent: Saturday, February 17, 2007 9:33 PM To: cragos@gmail.com Cc: kclug@kclug.org Subject: Re: Quick security question

Interesting question.

Mathematically, the hashes of "testpass" and "tespass" are very different, so obviously the passwd program isn't comparing hashes. What is it comparing?

When a user runs the passwd program, they are prompted for their old password and the password program stores that value, then the user is prompted for a new password and the new value is compared to the old value. The hashes themselves are not being compared.

When root runs the passwd program, it doesn't prompt for the old password value so there's no comparison.

On 2/17/07, cragos@gmail.com <cragos@gmail.com> wrote:

...

Can someone more familiar than I with the math behind one-way hashes explain how a hashed string is compared with a string in plaintext? I had a typo in the text I fed to passwd, and, when I went back in to fix the typo, I got an error message that read: "BAD PASSWORD: is too similar to the old one"

Of course, that was easy enough to override as root, but it raises an interesting question. Anyone game to explain the math behind how it was able to tell?

Thanks, Sean _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug

-- Dave Hull _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug

On 2/19/07, Dave Hull <dphull@gmail.com> wrote:

It's interesting that the passwd program when run as a normal user on RHEL (I assume other distros too), prompts for the user's "UNIX" password.

There's a very good reason to do this. From inside the software that I support at work, a user can theoretically have three different login credentials: 1. A Windows username/password just to get into their PC/workgroup/domain 2. A Unix username/password to get into the server 3. An application user NUMBER/password. This is complicated by the fact that some parts of the country would routinely set up Unix users with names like 'user12' for the person who logs into the app as '12'. The passwords for these things are, of course, set in different ways, and managed in different places. It's possible for our app to have a custom menu option that calls passwd to set the Unix password for a user; it's important that the person understand this distinction. (The actual passwd binary probably was originally written as a gnu drop-in replacement for the SysV passwd.)

This has been informative. A related query has been raised by my study of the concepts in password security. The windows os past a certain date makes use of the "ctrl-alt-delete" keyboard sequence as part of login procedure. I have a basic understanding of it that's not more detailed then the explanation given in their help screens. Other than the seemingly simple concept of making remote attacks need to simulate the keystrokes. The tie-in to the original post- much of our world's hardware has a "paperclip reset" or "on board shorting jumper" reset. Intended to either reset a password or return to shipped values. The security model relied upon physical access to the hardware as granting presumption of authority. Blunt simple logic. If you are touching it, you are presumed to be authorised. Can the "ctrl-alt-delete" method currently provide a Linux system with reasonable assurance that a user is physically in front of their computer? If not, some other method of convincing the os that the person seeking entrance to the password file is in possession of that computer, and presumed to be allowed access upon proving that. The implications of course open up a new thread and I am doing so.