Uhm.. sorry to rain on the parade here...

But unix standard crypt() (DES, iirc) has had this limitation since the dawn of time, and it's been well known and documented for just about forever.

Your problem is the 8 character limit of passwords crypted by the standard crypt() libraries. Try it, create a 10 character password, and simply type in the first 8 characters. You will be able to login.

This isn't news or a limitation in the way crypt() crypt's things as mentioned (has nothing to do with "most of the password being the same"). Standard crypt() has been around since the ancients, and back then 8 characters was considered extremely secure. These days, you can easily update this library (hint: it's not 'perl crypt' or 'php crypt' or 'apache crypt' - it's generally a C library on the system your applications are built against, or whatever crypt library the package maintainer built against).

So.. yes, unless you are using an updated crypt() library, you will be limited to 8 character passwords. Always have, and always will be.

-Phil

I haven't done diddly squat with crypt on my server, and it's password limit is 128 characters.

Must be those BSD underpinnings:1orglaugh

I think you mean that DES encryption has the 8char limit.... try MD5 or blowfish...

Just curious.. did you bother to man crypt?

Second paragraph...


By taking the lowest 7 bits of each of the first eight characters of the key, a 56-bit key is obtained.

:)

-Phil

Yes, I looked. "standard crypt" is generally meant "crypt based off of DES"

Obviously any OS distribution can change this to whatever they like (and most do, as well.. it makes sense since like 1999) :)

MD5 is generally what Linux uses as a replacement, however I'm unfamiliar with the *BSD's.

-Phil

Dude, you are so thick headed.

What you just posted is exactly why random salt means nothing:

"crypt() is a one-way hash function."

Exactly, that's why you have to encrypt the password the user tries to log in with and compare to the one you have on file. The salt is stored in the password so that you can't use a different salt to do the compare.:1orglaugh

Here, read and run this script:


#!/usr/bin/perl


print "Content-type: text/html\n\n";



$stored_encrypted_password = "jaZGhfOohPspE";

$typed_in_password = "janesmith123";

print " you can't unencrypt the password jaZGhfOohPspE !!!<br><br>";

print "# SO how do you get a match?<br><br>";

print " encrypt the typed_in_password and compare it to stored_encrypted_password<br><br>";

print "but you need salt<br><br>";

print " crypt() included the salt as the first 2 digits in the stored_encrypted_password<br><br>";

print " So in this case salt is 'ja' (jaZGhfOohPspE)<br><br>";


$salt = "ja";

$checkme = crypt($typed_in_password, $salt);

if ($checkme eq $stored_encrypted_password) {
print "<font color=red>The typed in password Matches. You are now logged in!</font><br><br>";

}


print " Now what if we changed the salt?<br><br>";

$salt = "12";

$checkme = crypt($typed_in_password, $salt);

if ($checkme eq $stored_encrypted_password) {
print "<font color=red>The typed in password Matches. You are now logged in!</font><br><br>";

}
else {

print "<font color=red>Failure to log in. You must use the same salt the password was created with</font><br><br>";

}



print " What you still don't get it?<br><br>";
print " OK pick a random salt and make a password<br><br>";

$salt = int(rand(99));
###make salt 2 digits
if ($salt < 10) {$salt = "0$salt";}

print "The random salt = $salt<br><br>";

$newencrypted_password = crypt('janesmith123', $salt);

print "New crypted pass = $newencrypted_password<br>Notice the first 2 digits are same as first 2 of salt?<br><br>";

print " now ignore the salt in the $newencrypted_password and compare the \'janesmith123\' using random salt<br><br>";

$salt = int(rand(99));
###make salt 2 digits
if ($salt < 10) {$salt = "0$salt";}
print "The random salt = $salt<br><br>";

print "If the new salt is not the same as the old salt, there is no match<br><br>";

$checkme = crypt('janesmith123', $salt);

if ($checkme eq $newencrypted_password) {
print "<font color=red>The typed in password Matches. You are now logged in!</font><br><br>";

}
else {

print "<font color=red>Failure to log in. You must use the same salt the password was created with</font><br><br>";

}



print "See it doesnt matter if you choose random salt because the salt is stored in the password<br>";
print "and you cant log in unless you use the same salt<br>";

print "Now if you could use a random salt in the compare then this would do what you want<br>";
print "But as you can see it only works one way";



exit;

the man page (below) doesn't say anything, but I tested the htpasswd site I set up for yer man to crack with a 9char passwd and only the 9char passwd will work...


man crypt
ENIGMA(1) FreeBSD General Commands Manual ENIGMA(1)

NAME
enigma, crypt -- very simple file encryption

SYNOPSIS
enigma [-s] [-k] [password]
crypt [-s] [-k] [password]

DESCRIPTION
The enigma utility, also known as crypt is a very simple encryption pro-
gram, working on a ``secret-key'' basis. It operates as a filter, i.e.,
it encrypts or decrypts a stream of data from standard input, and writes
the result to standard output. Since its operation is fully symmetrical,
feeding the encrypted data stream again through the engine (using the
same secret key) will decrypt it.

There are several ways to provide the secret key to the program. By
default, the program prompts the user on the controlling terminal for the
key, using getpass(3). This is the only safe way of providing it.

Alternatively, the key can be provided as the sole command-line argument
password when starting the program. Obviously, this way the key can eas-
ily be spotted by other users running ps(1). As yet another alternative,
enigma can be given the option -k, and it will take the key from the
environment variable CrYpTkEy. While this at a first glance seems to be
more secure than the previous option, it actually isn't since environment
variables can also be examined with ps(1). Thus this option is mainly
provided for compatibility with other implementations of enigma.

When specifying the option -s, enigma modifies the encryption engine in a
way that is supposed to make it a little more secure, but incompatible
with other implementations.

Warning
The cryptographic value of enigma is rather small. This program is only
provided here for compatibility with other operating systems that also
provide an implementation (usually called crypt(1) there). For real
encryption, refer to bdes(1), openssl(1), pgp(1), or gpg(1). However,
restrictions for exporting, importing or using such tools might exist in
some countries, so those stronger programs are not being shipped as part
of the operating system by default.

ENVIRONMENT
CrYpTkEy used to obtain the secret key when option -k has been
given

EXAMPLES
man enigma | enigma > encrypted
Enter key: (XXX -- key not echoed)

This will create an encrypted form of this man page, and store it in the
file `encrypted'.

enigma XXX < encrypted

This displays the previously created file on the terminal.

SEE ALSO
bdes(1), gpg(1), openssl(1), pgp(1), ps(1), getpass(3)

HISTORY
Implementations of crypt are very common among UNIX operating systems.
This implementation has been taken from the Cryptbreakers Workbench which
is in the public domain.

FreeBSD 5.4 May 14, 2004 FreeBSD 5.4

Hey Stupid! htaccess and htpasswd uses the encrypted pass words I'm talking about.

No wonder people still get hacked thru passwords.

so you hacked the 3-char passwd yet?

borked,

yep, FreeBSD does not use standard DES crypt, which is explained in the man page. Which was basically my entire point :)

For systems that DO use standard DES crypt (the majority, I would assume), there is absolutely an 8 character limit. This is what the OP was running into, not some strange "salt doesn't matter" etc. issue. Just a well known, designed in, and documented character limit.

Just to re-iterate since my point seems to be entirely lost.

THE PASSWORD HASHES ARE THE SAME BECAUSE THE PASSWORD IS THE SAME.

Again.

THE PASSWORD HASHES ARE THE SAME BECAUSE THE PASSWORD IS THE SAME.

12345678 is EXACTLY THE SAME as 12345678abcdefg for standard DES crypt.

There is no security issue here, if you don't like the 8 character limit either run a different OS (FreeBSD) or simply use different a compatible but different crypt() function (yes, Apache's htpasswd can be updated, as well as perl's, whatever)

Peace,

-Phil

This problem only concerns the crypt function, using another form of encryption is a differrent story. I brought this up because plenty of programs do use the crypt method to put passwords in to htpasswd file and they should switch to a direct htaccess creation like you. I assume your site is working, I didn't get to try it.

Anyway enough of this I got other stuff to do.
But it was interesting for me to actually see how bad crypt() could be with a bad password.

You haven't shown anything. You asked for someone to put up a 3-char password and you'd crack it in 1 try.

Yes, the 8-chra limit for some OSs has been shown, but so fucking what?
First you started out saying the salt added to the passwd, which was shot down sinc enoone uses standard salt. Then you said noone understands. Then you asked for a proof-of-concept 3char passwd to crack. Then you said you've had enough and you're off to bed?????

Ehm, :error

Thankfully, nobody hires you to programme for them.

Yep, you're on crack :thumbsup

Well, you're right!

The limit is 8 chars.

I only got into the salt debate because someone posted that the problem could be fixed with random salt.

The only fix is to limit passwords to 8 chars or use something other than crypt()



Well, at least I discovered some really smart people in this post which made it all worth my time.

Thanks for all the replies and "battles" hehehe!

If you generated the password with anything other than crypt() than I can NOT hack it.

Nope, I still don't get you.
You were the one that went on and on about the salt and how it is the first two letters of the password.

Then you said your janesmith123 janesmith321 whatever encrypted passwords were all the same. Well, for me they're not.

Then you said So if that's the case my 3char passwd must be a frikkin doddle. I even gave you the encrypted password - salt and all.

Where the hell did you find that bullshit text to copy and paste from?

it was generated by crypt().
The truth.
Now crack it. All of 3chars.
You said you'd do it in one try.

From Netcrafts homepage as of today

Four of the 10 most reliable hosters run their sites on FreeBSD, while two use Linux, and Windows Server 2003, Windows 2000 and Solaris 8 all make one appearance.

Let me guess where you fall?

"Thankfully, nobody hires you to programme for them"

If you've been around for a while you probably already bought one of my scripts...so pop that non-sense.


Nobody put up a link that had a 9 digit password encrypted with crypt()!
And it wasn't me who went off on a tangent about salt.
The only reason I brought up salt was to show how crypt made a password.
I said over and over again that salt was NOT the problem; yet you sound as though you think crypt() can be fixed by not using standard salt; and if that's what you still think then you didn't understand the problem.

The fix is to use a short password less than 9 characters.
Forget about salt.


But anyway thanks for posting some good stuff.

Nope, it was you who kept harping on about salt in your original post. Now you're changing your stance to "any 9char passwd"

Well, I aint saying anything until you crack my piss easy 3char passd.
Again, just to quote you:
If jane186 (7chars) is a better passwd than the other two (which even with an 8char OS crypt() limit, are effectively 8chars), then you'll have no problem cracking a 3char passwd.


I'm off to bed. You have until the morning to crack it.
Hopefully this thread will now die as it should do, kneejerker.

and I have never bought a script in my life,so I doubt it!
I programme low level code. I can back-end script with my eyes closed, so why would I need to buy shitty htaccess perl scripts from you?

Hat's off to you. Quality post 4 sure!

Well, I never said it was hard....:helpme

I did it with pencil and paper

:pimp

borked - whats your contact info - email

I finshed dinner so now:

Like I said; I only need one guess for a 3 char encrypted password.

Go here and create passwords or use crypt($passwd, $salt).
http://www.htaccesstools.com/htpasswd-generator/


Run script:




#!/usr/bin/perl


print "Content-type: text/html\n\n";


$alphadata = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLM NOPQRSTUVWXYZ";
@one = split(//, $alphadata);
@two = @one;
@three = @one;

$passencrypted = "QVK7qHfRnSw3M";
$salt = substr($passencrypted, 0, 2);
print "salt = $salt<br>";

$a = 0;
foreach (@one) {

if ($a >= 80) {

print "abort<br>";
exit;
}
$b=0;
foreach(@two) {
$c = 0;
foreach (@three) {

$pw = "$one[$a]$two[$b]$three[$c]";

$check = crypt($pw, $salt);
if ($check eq $passencrypted) {
print "$pw - is a possible password<br>";


}
$c++;
}
$b++;
}

$a++;
}

print "Ended OK";

exit;



:1orglaugh :1orglaugh :1orglaugh

So much for encryption!

PS: That little hack I just wrote for you assumes passwords without special characters...I could easily add all special charaters to the alphadata string.

And, I could do the full eight charaters but not on MY SERVER!
Too much resources.

Wow, you code like you draw dude! :thumbsup

I didn't really go into it but I think I get what you are saying - basically people are using the password as salt and they should use a random salt?

generally i think people are a bit stupid about security in this industry

:1orglaugh :1orglaugh :1orglaugh


BRUUUUUUUUUUHAHAHAHAHAHAHAHAHAHAHAHAHA!!


HAHHAHAHAHAHAHAHAH!!!

*sigh*


Theres no know way...hehehehe!

Unless you can write 20 lines of FUCKING CODE!!!


BRUUUUUUUUUUHAHAHAHAHAHHAHAHAHAHA!


Lets see; please count these lines:

$alphadata = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLM NOPQRSTUVWXYZ";
@one = split(//, $alphadata);
@two = @one;
@three = @one;
$passencrypted = "QVK7qHfRnSw3M";
$salt = substr($passencrypted, 0, 2);
print "salt = $salt<br>";
$a = 0;
foreach (@one) {
$b=0;
foreach(@two) {
$c = 0;
foreach (@three) {
$pw = "$one[$a]$two[$b]$three[$c]";
$check = crypt($pw, $salt);
if ($check eq $passencrypted) {print "$pw - is a possible password<br>";}
$c++;}
$b++;}

$a++;}
print "Ended OK";





hehehehehe....hohohohoh....HAHAHAHAHAHAHA!

*sigh*

Where my dogs at?

perl is sooooo 80's :winkwink:

this thread makes me giggle. :helpme

Well judging by all the modules that continue to pour into CPAN, perl is still very much in style;)

Or use a salt like: $1$<8 random chars>

Then you'll get an MD5 encrypted password, which is much better than crypt. Don't ever use the password as the salt value, it has to be random chars.

Yeah, the 80's...back when programmers went to college and actually had brains before trying to run a business.

No matter how much "new" shit comes out I have yet to find something that could not be done in perl already.

ASP = SSI with perl cgi
Java = Object oriented perl (Java does come with easy tools though)
PHP = If you can't learn perl
C, C++ = Perl without the cool shit for text munipulation
...etc...

I think the reason webmasters sought solutions other than perl is that they didn't have good knowlege of libwww

libwww contains tons of modules that allow perl to do, well, MAGIC!
Any new thing done on the internet can be programed into a perl module and added to libwww. The modules can be written in differrent languages also, with C++ being one of the most used.

Libwww allows perl to grow as a language without actually changing perl.
This is not true with most of the "new stuff".

If development of libwww continues in a positive direction then I suspect that in the future webmasters will migrate back to it as they will find that they can learn 5 new languages to get the project done or they can just use perl with all it's libraries.

The only draw back I see for perl is client-side applications. The client has to make an http request for perl. But Javascript can handle a lot of that and SSI can use perl to deterime what javascript to send the client.

You should read my post above where I "UNENCRYPT" your password no matter what salt you use. Run the code...than talk to me.:disgust

That's not 'unecrypting', that's cracking. If someone can read your crypted passwords, you have bigger problems than an 8 character limit.

whats this thread about ?
8chr crypt passwords had been crackable since ages

All of your employees in the computer programming department can read your customers encrypted passwords!

All your server admins for your hosted sites can read your surfers encrypted passwords.

When one of the above gets fired and decides to fuck up all you member/customer accounts, you will then understand why I brought this issue up.

That's the only reason they are encrypted.

The hackers and surfers have to "break in" to read these files so like you said, if they can read the files you have bigger problems. But that's not the issue.


The issue is that there is a beliefe that the crypt files can not be used to return the original password. I have shown this to be a myth.

PS: "unencrypting" is a subset of "cracking".:)