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
It runs what you type through the hash function and compares the output. Hashing is very simple. If what you type produces the same hash output that is stored in the passwd file, then you (probably) typed the same password. One way hashes are just that, one way. Thus, when it need to compare anything to the stored hash it mush also be hashed for the comparison to work.
Jon.
On 2/17/07, [email protected] [email protected] 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 [email protected] http://kclug.org/mailman/listinfo/kclug
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, [email protected] [email protected] 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 [email protected] http://kclug.org/mailman/listinfo/kclug
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: [email protected] [mailto:[email protected]] On Behalf Of Dave Hull Sent: Saturday, February 17, 2007 9:33 PM To: [email protected] Cc: [email protected] 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, [email protected] [email protected] 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 [email protected] http://kclug.org/mailman/listinfo/kclug
-- Dave Hull _______________________________________________ Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
Good point, some systems are configured to keep password histories. On my default RHEL install, there is no such file. In fact, I don't think I've used any version of Linux that was configured this way. There's probably some PAM configuration that will keep password histories, but by default, I don't know of a Linux distro that does.
The passwd program does compare the current password that the user gives when she runs the passwd program against the user's newly entered password. A look through the source of the passwd program confirms this.
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.
On 2/19/07, Phil Thayer [email protected] wrote:
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: [email protected] [mailto:[email protected]] On Behalf Of Dave Hull Sent: Saturday, February 17, 2007 9:33 PM To: [email protected] Cc: [email protected] 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, [email protected] [email protected] 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 [email protected] http://kclug.org/mailman/listinfo/kclug
-- Dave Hull _______________________________________________ Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
On 2/19/07, Dave Hull [email protected] 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.)
Most of the OS's currently on the market can use a single sign-on capability with Kerberos or something similar to that. Using a single sign-on functionality is convenient to the user as well as reducing the systems administration tasks involved with create/modifying/deleting users.
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.
Actually, IIRC, the Ctrl-Alt-Delete login process is meant to thward phishing attacks. When you press Ctrl-Alt-Delete, Windows ALWAYS intercepts it. Therefore, you know Windows itself is presenting your login dialog, not some viral program. You can send Ctrl-Alt-Delete remotely since at least Win98 (though in DOS-based Windows, it will freeze any network processes).
If you want to determine if a user is local, use a USB dongle :)
-
cragos＠gmail.com -
Dave Hull -
Jon Pruente -
Luke -Jr -
Monty J. Harder -
Oren Beck -
Phil Thayer