Something seriously wrong with the password?!

U

urbee

Verified User
Joined
Mar 27, 2009
Messages
118
Hi,

i've noticed a serious admin password issue.

Lets say my admin password is '123' - if i log in with the password 123, it works. I change it to '1234'. I'm able to log in with '123' still, aswell as '1234' and '12343ofskgjfdggdg'. ANYthing will work, as long as it includes the original password in the beggining. What tha hell is going on?

Also, when i try to login to webmail with a users username i can see the admins emails (either that or the user is getting backup notification emails).
 
Ok, i've just checked on two additional directadmin servers - same issue!!!

This is making me doubt in directadmin security.
 
couldnt duplicate

I tried to get this to happen on my servers running Centos.... wouldnt let me in unless everything was as it should....
 
Hello,

Check your password encryption setup on your box to see which encryption it's using. We want to see MD5 and not DES:
http://help.directadmin.com/item.php?id=248

If it's not clear, please paste us (via email, not the forum) your actual password and the crypt value from the /etc/shadow file so we can test the crypt to see what it's set to.

Try this to see what password work and which don't:
http://help.directadmin.com/item.php?id=288

Also test this with sshd as admin to see if the same thing happens there, or if it's just with DA.

Which OS version are you using?
http://help.directadmin.com/item.php?id=318

John
 
Same issue with logging in on sshd.

I'm using Debian 5 (lenny) 32bit.

It was not set to MD5. Is this the issue?
 
After changing #MD5_CRYPT_ENAB no to MD5_CRYPT_ENAB yes like in the guide and restarting the server, same issue.
 
You did not mention that you also changed the password after restarting. Did you do that?
 
I think its OK now.

But why does debian not use MD5 by default? Isnt that just lame?
 
I'm not sure of the thought processes uses by the Debian creators.
Which encryption method was used by default?

John
 
There was neither DES or MD5 enabled in /etc/login.defs. How is that possible?
 
Hello,
If nothing is specified in the login.defs, it would default to some encryption, I'm not sure which.
There are other encryption types like sha-512, etc, if it's not MD5 or DES.

If you check your /etc/shadow file, check to see what the first 3 characters of the crypt are (the crypted password, 2nd column, colon separated)

If it's $1$, then it's MD5.
If its $6$, then it's sha-512
If there are no $ characters in the crypt, then it's the old DES.

Note that the old values can still be present, even after you've set the new default in the login.defs. Only until a password is saved will they be set. Note that DA will always create MD5 passwords when it can, but sometimes DA calls a "passwd" binary from the OS which would may use the format in the login.defs, so it might not always be consistent.

Regardless of the encryption used, assuming the binary doing the password match has that encryption included in the compile, any encryption type can be passed to the crypt() function and it should still work fine.

John
 
DirectAdmin Support said:
Hello,
If nothing is specified in the login.defs, it would default to some encryption, I'm not sure which.
There are other encryption types like sha-512, etc, if it's not MD5 or DES.

If you check your /etc/shadow file, check to see what the first 3 characters of the crypt are (the crypted password, 2nd column, colon separated)

If it's $1$, then it's MD5.
If its $6$, then it's sha-512
If there are no $ characters in the crypt, then it's the old DES.

Note that the old values can still be present, even after you've set the new default in the login.defs. Only until a password is saved will they be set. Note that DA will always create MD5 passwords when it can, but sometimes DA calls a "passwd" binary from the OS which would may use the format in the login.defs, so it might not always be consistent.

Regardless of the encryption used, assuming the binary doing the password match has that encryption included in the compile, any encryption type can be passed to the crypt() function and it should still work fine.

John
Click to expand...

Hmm i'm sorry to bump an old topic like this, but i got a question:
My servers have "MD5_CRYPT_ENAB yes" and the passwords in shadow start with $1$, so that is ok. But I have the same problem that as long as the given password to login in DA starts with the REAL password, and has some extra characters, it's accepted.

My tested examples:
The real password is "Testing"
succesful: "TestingGjhsu7"
succesful: "Testing1"
unsuccesful: "Testin"
unsuccesful: "asdH5Testing"

how can this be?
 
Some extra info:

-bash-3.2# cat /etc/redhat-release
CentOS release 5.5 (Final)

-bash-3.2# uname
Linux

-bash-3.2# uname -r
2.6.36

-bash-3.2# uname -m
x86_64
 
Which binaries are are you using?:
Code: 
cd /usr/local/directadmin
./directadmin o
also, I'm assuming you're using the DA login?
Try testing in php to see if you can get the same results:
http://help.directadmin.com/item.php?id=288

I've tested on our CentOS 5, 64-bit box, but wasn't able to reproduce that.

I know that many years ago, before using MD5 ($1$), DES was used. DES had an 8 character limit, so any characters after 8 were accepted (although, "Testing" is only 7, making it very strange)

John
 
DJSnels said:
Hmm i'm sorry to bump an old topic like this, but i got a question:
My servers have "MD5_CRYPT_ENAB yes" and the passwords in shadow start with $1$, so that is ok. But I have the same problem that as long as the given password to login in DA starts with the REAL password, and has some extra characters, it's accepted.

My tested examples:
The real password is "Testing"
succesful: "TestingGjhsu7"
succesful: "Testing1"
unsuccesful: "Testin"
unsuccesful: "asdH5Testing"

how can this be?
Click to expand...

Well, this is strange, I checked this on my server, and guess what.. I got the same problem!
I am using MD5 (verified /etc/shadow and /etc/login.defs), when I try to login with a different password starting with the same characters I can login..
 
DirectAdmin Support said:
Which binaries are are you using?:
Code: 
cd /usr/local/directadmin
./directadmin o
also, I'm assuming you're using the DA login?
Try testing in php to see if you can get the same results:
http://help.directadmin.com/item.php?id=288

I've tested on our CentOS 5, 64-bit box, but wasn't able to reproduce that.

I know that many years ago, before using MD5 ($1$), DES was used. DES had an 8 character limit, so any characters after 8 were accepted (although, "Testing" is only 7, making it very strange)

John
Click to expand...

Compiled on 'CentOS 5.0 64-bit'
Compile time: Sep 15 2011 at 16:51:44
Compiled with IPv6

and the response from the php-test:

$1$asdf1234$7amUjHHdQx2N3dPJsKgUg0
for both tests, just as told.

Yes i am talking about the login on DA (domain.com:2222)

1 notice:
I have written "Testing" but this was just an example :)
I'll try to test if the problem resists if I use a 7 digit password.
 
Hello,

Hmm. Ok. If php is also returning the same chopped results, then the issue (as suspected) is with the library itself. You could see if there are any updates for your OS using yum.
The crypt header file is unistd.h, which shows up in a few different rpms:
glibc-headers
glibc-kernheaders

so, you'd likely want to update everything, eg:
Code: 
glibc
glibc-devel
glibc-common
glibc-headers
glibc-kernheaders
It's odd though, how on our build system which uses Cent OS 5.0, it's not affected, eg:
Code: 
[root@es5-64 ~]# cat /etc/redhat-release
CentOS release 5 (Final)
[root@es5-64 ~]# uname -m
x86_64
[root@es5-64 ~]# php
<? echo crypt('Testing','$1$boy8afj7$'); ?>

<? echo crypt('TestingGjhsu7','$1$boy8afj7$'); ?>

<? echo crypt('Testing1','$1$boy8afj7$'); ?>

<? echo crypt('Testin','$1$boy8afj7$'); ?>

<? echo crypt('asdH5Testing','$1$boy8afj7$'); ?>

$1$boy8afj7$gRHJpd5VsYRtGmuRuD0yw/
$1$boy8afj7$hj6R4v85oSOtG.fW2ROOQ/
$1$boy8afj7$k6HHbJKRUGBCEeOGUMyaF.
$1$boy8afj7$h6wJdZ6VmA1TJioEATTPh1
$1$boy8afj7$uq7ghz61kXdlP2nJHv3Sa1

[root@es5-64 ~]#
All of the crypts are different.

John
 
Ok,
If i alter the password encryption in /etc/pam/d/system-auth-ac to md5 and change the admin password back and forth the new password is encrypted. So if the password is
Testing12345
I cannot login with
Testing12345!
So that is good.

But after changing this i cannot ssh into my box (and i'm forced to restore to a backup)
Eventhough logging in through DA works fine.

any clues?
 
Try changing your password in directadmin and you should be able to get in ssh. All the system passwords will have to be changed to work with the new algorithm.
 
You must log in or register to reply here.
Back
Top