You got hacked!!! Heres the reason why...password encryption!!
 

You got hacked because you "protected" your passwords!

I discovered that the encryption of passwords make it much easier for
hackers when users pick "bad" password.

Look at the cgi method in the script below that is used by most, if not all,
websites. Upload it to your sever and name it something.cgi and run it.

Try this cgi scipt:



#!/usr/bin/perl


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


$out1 = crypt('longpassword123', 'lo');
$out2 = crypt('longpasswordabc', 'lo');
$out3 = crypt('longpassword456', 'lo');
$out4 = crypt('longpassworddef', 'lo');
$out5 = crypt('longpasswordxyz', 'lo');
$out6 = crypt('longpassword789', 'lo');

print "out1 = $out1<br>out2 = $out2<br>out3 = $out3<br>out4 = $out4<br>out5 = $out5<br>out6 =

$out6";

exit;


Did you see that?


Perl crypt works by using a 2 digit value called the "SALT".
The salt in the script below is "lo" which is the first 2 digits of the password.

The salt used to encrypt the stored password must be used again to match
the stored password. So either the SALT is hardcoded into the routine so its
always the same or it is taken from the first 2 digits of the password.

So what we put into our password routines is this:

$stored = crypt($password, $password);

The crypt fucntion only uses the first two digits so it doesn't matter that
the salt entered is longer(ie the full password)


Then to check the password we do this"

$check = crypt($enteredpass, $enteredpass);
if ($check eq $stored) {$let_the_user_in = "TRUE";}



** Notice that all the passwords that were entered in the script('longpassword...')
matched the stored encrypted password!


So let's consider a lady named Jane Smith.
Jane is smart and does the following math:

0 thru 9 is 10 characters;
a thru z is 26 characters;
A thru Z is 26 characters;(Capitalized)

for a total of 62 characters

Jane knows she can make 238,328(62*62*62) unique charaters sets from the 62 charaters
if she uses a 3 character set(ex. abc, efg, 123, 45b.....)

So even though her name is very common she figure it will take about 200,000
guesses at her password before anyone even gets close to figuring it out.

So she makes her password this "janesmithMdY"

To be clever she adds a couple of caps "M" and "Y".



Now run the following cgi script:


#!/usr/bin/perl


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


$out1 = crypt('janesmithMdY', 'ja');
$out2 = crypt('janesmithabc', 'ja');
$out3 = crypt('janesmith456', 'ja');
$out4 = crypt('janesmithdef', 'ja');
$out5 = crypt('janesmithxyz', 'ja');
$out6 = crypt('janesmith789', 'ja');

print "out1 = $out1<br>out2 = $out2<br>out3 = $out3<br>out4 = $out4<br>out5 = $out5<br>out6 =

$out6";

exit;









OMFG!!!!!!!!





Jane is wrong because instead of the hacker having to guess 200,000 times he has
a choice of 238,328 passwords that match!! So he only needs to try one password
from the the 238,328. But hey he doesn't know how many digits she used so he still
has to do one more thing.


He has to try the following passwords:

janesmith
janesmith1
janesmith12
janesmith123 and FRIGGIN POW!! He's in!!!

Jane would have been correct if her password had not been encrypted but
too bad...she lost all the money in her bank account instead.




What if jane had used this "bh6janesmith"?



#!/usr/bin/perl


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


$out1 = crypt('abcjanesmith', 'ab');
$out2 = crypt('123janesmith', '12');
$out3 = crypt('efkjanesmith', 'ef');
$out4 = crypt('bh6janesmith', 'bh');
$out5 = crypt('opjjanesmith', 'op');
$out6 = crypt('897janesmith', '89');

print "out1 = $out1<br>out2 = $out2<br>out3 = $out3<br>out4 = $out4<br>out5 = $out5<br>out6 =

$out6";

exit;



Well she would have been a little better off because the "SALT"
would not have been known to the hacker...remember the salt is the
first 2 digits of the password.

so 62*62 = 3844 (2 digits 62 chars) and the hacker would have to
guess up to 3844 times. Not hard to do with a script!





Conclusion:

* encrypting passwords can make it easier for hackers if you choose bad passwords.

* did you notice that the "salt" was included as the first two digits of the encrypted
password? So 3 letter passwords can be hacked by employees in 62(using only alpha-numeric)
guesses even though
encrypted; since they can look at the encrypted password and see the first 2 chars!

* the problem with "crypt" is that when a non-unique string(ex. "janesmith") is longer
than an included "unique" string (ex. "MdY") it mostly encrypts the larger portion
of the string which is not unique.


So "jane186" is far better than "janesmith186" or "186janesmith"

Try it:

#!/usr/bin/perl


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


$out1 = crypt('janeMdY', 'ja');
$out2 = crypt('janeabc', 'ja');
$out3 = crypt('jane456', 'ja');
$out4 = crypt('janedef', 'ja');
$out5 = crypt('janexyz', 'ja');
$out6 = crypt('jane789', 'ja');

print "out1 = $out1<br>out2 = $out2<br>out3 = $out3<br>out4 = $out4<br>out5 = $out5<br>out6 =

$out6";

exit;




* So like most websites say the best password is something like "bG7ei5Ma".


If you thought this was informative and maybe will save your butt one day and you'd like
to make a small donation for my reseach you can

Paypal me (webmaster at econfirmpro DOT COM) or
epassporte me (webmaster at iLLsex DOT COM)



Thanks in advance.

Oops!!!

You have to change the "&lt;" to "<" and the "&gt;" to ">" in the scripts.

I thought the wouldn't print on this board.

Oops!!!

You have to change the "&lt;" to "<" and the "&gt;" to ">" in the scripts.

I thought the wouldn't print on this board.

Uhhmm.. NO.. A small percentage might use that kind of programming, but most do not.
Anyways.. This just goes to show that people should use an experienced programmer..

Could somebody translate this post into plain english please?

Ehm, are you talking about system passwords here or script-generated passwords?
Who the heck uses standard crypt-based passwd generation and auto salt generation in their scripts anyway?

Any perl programmer worth the money hes being paid would be using, Digest::SHA or something similar, and not perls built in crypt function....

You're out of your mind!!

And you missed the point totally if you think an experienced programer could change this.

Password encryption has to be used with .htacess for members areas!
Only the dumbest programmers are not using htacess on unix servers.

I using .htaccess password encryption so i dont give damn.

Everybody who uses htacess!

System passwords are created with the same crypt function and with the script because perl executes the system function when you "call" crypt.


Don't take my word for it.

Create a account somewhere and use "janesmith456" as the password and see if you can get in by using "janesmithabc".

Ok, create me an account with "janesmith..." as the password and see if I can hack it.
put any 3 alpha numeric chars after "janesmith".

WTF?!

eg (using janesmithMdY as password for user test):
A look at the htpasswd file shows:

test:Y4EmFPv1PTVJ2

So, where's the security hole???

Yeah; well tell all these programers that they suck

http://www.google.com/search?hl=en&l...pt&btnG=Search

Further, tell my how you know how a good a programer was that built a website you joined.

And from your example, who says they all used the standard salt???? Who the frikkin hell doesn't provide a salt in the script?

I think you should stop here. You simply don't get it.

OK:


janesmith:j/VTQYM4JMtC.
:321GFY

Countdown has commenced.

Nope, you are absolutely 10 years behind! I dont use htaccess for storing login info in any way whatsoever, as it's easy as hell to get into for newbie programmers, obviously. Who the hell in their right mind is going to use default encryption anyways??

You need to read what I said again.

You can change the salt to whatever and it's still the same problem.

The salt used to encrypt must also be used to compare the typed in password or they won't match.

The hacker doesn't have to know the salt!

The salt can change for each password but you have to recover the salt you used for each password; so no matter what the hacker types in your program retrieves the correct salt.


See, you illustrate why programmers don't know why this is a problem. You think changing the salt means something.

If I us "ab" as salt to crypt the password I have to use "ab" as salt again when you login using your password.

Changing the salt is like changing the lock but giving you the new key to it because your program always give up the salt no matter what you used or where you got it from.

Give me the URL and of course this is only relevent if the site uses perl crypt.

This discussion is about perl crypt.

this one is way over my head

The 'salt chars' should randomly selected. If someone is dorky enough to use the same salt chars for obvious passwords then a database can be build of what the crypted passwords look like.

But, you still have to be able to read the .htpasswd file to even see what the crypted passwords are - if a hacker is able to download your .htpasswd file you have bigger problems than crypt fn shortcomings.

At risk of being wrong it would seem best if users set their own passwords to something truly hard to guess by using RoboForm's "generate password" feature.

Good for you if you are not using perl crypt; but many people are and thats why I posted this.

Telling me that something else works is meaningless since I'm talking about sites that don't use "something else".

dcortez put the point more clearly than I. You're example gave the salt as the first two letters of the passwd. Maybe I missed something.

In any case I won't put the passwd on a test site so you can wwwhack it to hell.
If I did, then maybe I'd include a 10-guess timeout limit.

htaccess hardening isn't difficult.

Went right over your head!

The salt is randomly generated! That doesn't matter!
It's usally the first 2 digits of the password you entered, which unless everyone is using the same password, is random!

The hacker doesn't type in the salt!!!!!!!!!

The hacker types in the password and your program uses the salt.

See, you can't "un-encrypt" the password in the file.
You can only encrypt the "TYPED-IN" password and crypt it to see if it matches the real password. If the salt changes at this point you can never login since you need the original salt to encrypt and get a match.


This is exactly why I posted this info...people don't understand it.

:1orglaugh :1orglaugh :1orglaugh

It only takes ONE guess!!

Do it yourself.

Use the janesmith example followed by 3 random chars.

Or choose another 9 char name followed by three chars.

The number of chars is important because the name must be longer than the random chars.

if you're using perl crypt I don't give a shit where you get the salt from you'll be able to log in with janesmithwad, janesmith3er, janesmith...any three charaters.

Don't let surfers pick their own user/pass :2 cents:

Don't use "common" type password.. Use something random.. Need some passwords? use this tool: http://awmstuff.com/password-generator.html

Prove you not stuck in the past...
Post a perl cgi script that does password encryption and see if I can't hack it.

Don't bother to post a script that uses arrays and substitues values in for the password. These are easy to figure out.

You gotta remember why the passwords are encrypted...so that anyone reading the file cannot use the passwords. If nobody ever read the file it wouldn't make a difference if they were not encrypted!!!!!!
Anyone reading the file with some cheezy array encryption can simply create an account and figure out which chars are subsituted by looking at their own password. The crypt function, however can not be un-encrypted.

That's why people use crypt but as I pointed out it creates non-unique encryptions. Which is one reason you can't unencrypt!
The damn thing could un-encrypt to 1000's of unique password.

That is the solution.

Glad you understand this.

Other people here that think they can change the salt and get around this simply do not understand how to do password programming.

And I'm sure I can do this with other good encryption routines.
I might have to use a much longer string than "janesmith" but eventually I would find where the encryption became non-unique.

Uhm...Everyone uses AT LEAST htaccess with htpasswd nowadays right? And most ppl are even using more advanced systems...

Not sure what you're on about. Crypt provides a different encrypted string for each of your examples.

jay1BKgVKubu6
jaADnt7Hb0P5Q
jace8qGfWs8I.
jaekAkfj7Nz12
ja/rCsVM3tuVE
ja4dR4i3ymgQI

Sorry, I missed this post earlier.

Now do the same thing using "janesmith123" and see if your htpassword file also has "Y4EmFPv1PTVJ2"

if so, then there's the hole!

You'll be able to log in with "janesmith...any-three-chars".

Hey sunshine:

crypt PLAINTEXT,SALT

Creates a digest string exactly like the crypt(3) function in the C library (assuming that you actually have a version there that has not been extirpated as a potential munitions).

crypt() is a one-way hash function. The PLAINTEXT and SALT is turned into a short string, called a digest, which is returned. The same PLAINTEXT and SALT will always return the same string, but there is no (known) way to get the original PLAINTEXT from the hash. Small changes in the PLAINTEXT or SALT will result in large changes in the digest.

As I said before,the salt chars should be randomized when the passwords are encrypted.

The user does NOT enter the salt chars - the software which converts the plain text password to the stored crypted password should use random salt chars.

Congrats on your 200th post, and if you don't mind my suggesting, stick to explaining solar operated beenies to bats.

Well, thank you for running the "corrected" example...now run the ones that show the problem.

I provided differrent exampes to show how to better choose a password.

Just realized that. It's an easy fix either way, just split the password at the 8 character limit and crypt in chunks.

I'm frikkin lost what your problem is....what server you testing this shit on anyway???

so, passwd is janesmith123 and now htpasswd shows the encrypted passwd as:

test:4/2DtEWlT7NMo

OK, go on, do your proof-of-concept:

log in here

here's the .htpasswd file:

test:t.YB1KMM5IMI.

3 alpha numeric character passwd

.....
no f'ing fancy script was used to generate the passwd file

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