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