Password one way encryption.

[xmakina]

yes, my suggestion uses encryption (my password translates to 5496655beb4dffbb74b6b289ca83dd2a68ba71db)

It also uses the username as a salt, meaning each person will have a unique password without having to store anything extra in the database. This should also slow down any crackers as they will look for the extra "salt" column, not see it and then assume I've just sha1'd the password without a salt!

 

[nanoman]

The best is to use several encryptions like I do:

<?php
sha1(md5($password))
?>

If you'll do this for example:

<?php
sha1(md5(sha1(md5($password))))
?>

The one who's going to be cracking the password will need a super computer to crack it till the unencrypted password. ^^

 

[Scoochi2]

The best is to use several encryptions like I do:

<?php
sha1(md5($password))
?>

If you'll do this for example:

<?php
sha1(md5(sha1(md5($password))))
?>

The one who's going to be cracking the password will need a super computer to crack it till the unencrypted password. ^^

That's a BAAAAD idea. More encryption is only likely to increase the chances of getting the same hash from multiple passwords. In other words, that would decrease your security.

 

[nanoman]

That's a BAAAAD idea. More encryption is only likely to increase the chances of getting the same hash from multiple passwords. In other words, that would decrease your security.

How can it get the same hash?

Example:
I am encrypting the word: x10hosting

First lets encrypt it in MD5 and the result is: d36fd615d1cc07a512453a54f5184435
Second lets encrypt the already gotten MD5 hash key into SHA1 and the result is: B6D2A1E11C338A88F1DB57516BFB5F2B905DA27A
Third, lets encrypt the gotten SHA1 hash into MD5 and the result is: E4A39A17B8E2223DD0DE0C27B196893F
Fourth, lets encrypt the gotten MD5 hash into SHA1 and the result is: BD2F9B01AE39E8DC5F44B68D174DFFBBD1B8D808

And now tell me how the heck are you going to get the first hash key from the last one, since you said that I will get the same result?! Think before you say!

 

[xmakina]

I *think* he was more referring to the chance of a password collision (that is, 2 phrases result in the same answer). Although with 40hex charachters in one and 32 in the other I imagine it's no more likely than plaintext.

Ultimately, sha1 and md5 have been tried and tested. There's not a lot of point to writing your own unless its as an exercise. As for going sha1->md5->sha1->md5->etc. it's, again, a matter of choice. If you Are going to go one then the other use this opportunity to keep salting each password, making it even more difficult to break and much less likely to be on a rainbow table

 

[vol7ron]

I suspect that the line I need to amend is ... to something like

$LoginRS__query=sprintf("SELECT USERNAME, PASSWORD, LEVEL, GROUPCODE, USERTZ, USERTF FROM CONTACTS WHERE USERNAME=%s AND PASSWORD=%s",
  GetSQLValueString($loginUsername, "text"), GetSQLValueString(crypt($password,$password) "text"));

i think this is what you want

$LoginRS__query=sprintf("SELECT USERNAME, PASSWORD, LEVEL, GROUPCODE, USERTZ, USERTF FROM CONTACTS WHERE USERNAME=%s AND PASSWORD=%s",
  GetSQLValueString($loginUsername, "text"), GetSQLValueString(crypt($password,$salt) "text"));

I think GetSQLValueString() is expecting two parameters, so both examples are missing a comma at the end. This may or may not have caused problems, based on PHPs ability to interpret, but I think it would. I'll fix the later one as it includes a mention of a salt.

$LoginRS__query=sprintf("SELECT USERNAME, PASSWORD, LEVEL, GROUPCODE, USERTZ, USERTF FROM CONTACTS WHERE USERNAME=%s AND PASSWORD=%s",
  GetSQLValueString($loginUsername, "text"), GetSQLValueString(crypt($password,$salt), "text"));

======================================================================
======================================================================

The best is to use several encryptions like I do:

<?php
sha1(md5($password))
?>

If you'll do this for example:

<?php
sha1(md5(sha1(md5($password))))
?>

The one who's going to be cracking the password will need a super computer to crack it till the unencrypted password.

Do not listen to this post, it is wrong. While it may seem to make sense (hashing a hash) the problem is that these are mathematically based processes. Performing them recursively could result in more than one word with the same hash. For instance the word "mom" and "world" could result to something like 0x00230AB4.

The best performing encryption to use, as I mentioned in an earlier post, is 256b AES, which even the government uses. MD5 was promising at the beginning, but now it's been cracked.

 

[xPlozion]

I used to do sha1(sha1($salt).sha1($pass)), but that was before I used FluxBB for my forums and the user database behind the system.

My idea was that if they crack the sha1, that they would have a longer string that makes no sense and harder to crack, but i guess i could have been wrong

 

[natsuki]

yeah i think doing multiple encryption increases the possibility of words having the same hash, it's because these encryption system uses multi-pass algorithms, but since this is still plain text (actually they just look like hex numbers) and different encryption systems uses different algorithms, who knows one might end up decrypting the other (we don't know)

I found a site before that can decrypt md5, it takes some time to do it but it does.

 

[freecrm]

vol7ron makes a good point with the comma but my issue still remains the same.

The script I attached earlier is stupidly complex and, as xPlozion points out, hard to follow, but from what I can gather, it uses the $_POST values from the login form to simply create a recordset from the user table and enter those details into session. If the values entered do not match any records, it simply won't return any values and can't log you in.

Whilst this works fine, it is not making any direct comparison, so the stored, encrypted $password isn't being accessed to provide the salt information.

As a result, I cannot make a reference to this value for a salt when encrypting the $_POST form value before making a comparison.

i.e. - original registration process was $StoredEncryptedPassword = crypt($_POST['RegistrationPassword']) - insert record.

login should have something like

if ($StoredEncryptedPassword == crypt($_POST['LoginPassword'], $StoredEncryptedPassword))
{
login & store to session
}
else
{
go away
}

I can look at the mechanics of differing salts later - I need to get this bit working first.

 

[freecrm]

At last, I've cracked it...

Fully commented solution below.

<?php
if (!isset($_SESSION)) {
  session_start();//start session
}

$loginFormAction = $_SERVER['PHP_SELF'];//run this script after posting
if (isset($_GET['accesscheck']))
{
  $_SESSION['PrevUrl'] = $_GET['accesscheck'];
}

if (isset($_POST['username']))//if there is a form value entered
{
  $loginUsername=$_POST['username'];//assign variables
  $MM_fldUserAuthorization = "LEVEL";
  $MM_redirectLoginSuccess = "../crmcontacts/updatemycontact.php";//where to go if successful
  $MM_redirectLoginFailed = "loginfail.php";//where to go on fail
  $MM_redirecttoReferrer = false;
  mysql_select_db($database_freecrm, $freecrm);//db connection
  
  $LoginRS__query=sprintf("SELECT USERNAME, PASSWORD, LEVEL, GROUPCODE, USERTZ, USERTF FROM CONTACTS WHERE USERNAME=%s", GetSQLValueString($loginUsername, "text")); //get values from db where username is the post value
  
  $LoginRS = mysql_query($LoginRS__query, $freecrm) or die(mysql_error());//return the query
  $loginFoundUser = mysql_num_rows($LoginRS);//count rows
  
  if ($loginFoundUser)//if theres a row
  {
  	$salt = mysql_result($LoginRS,0,'PASSWORD');//gain salt from db
	$password = crypt($_POST['password'],$salt);//encrypt posted password
	if ($password == $salt)//if posted value equal to db entry
  	{
  		//declare two session variables and assign them
    	$_SESSION['MM_Username'] = $loginUsername;
    	$_SESSION['MM_UserGroup'] = mysql_result($LoginRS,0,'LEVEL');

		//groupcode declaration
		$_SESSION['MM_GroupCode'] = mysql_result($LoginRS,0,'GROUPCODE');
		//timezone/format preferences
		$_SESSION['MM_UTZ'] = mysql_result($LoginRS,0,'USERTZ');
		$_SESSION['MM_UTF'] = mysql_result($LoginRS,0,'USERTF');      

    	header("Location: " . $MM_redirectLoginSuccess );//specify re-direct
  	}
	else//if they don't match
	{
   		header("Location: ". $MM_redirectLoginFailed );//specify re-direct
  	}
  }
}
?>

Thanks for all your persistence. :biggrin:

All I have to do now is to manually encrypt all previously registered users!

Admin - you can definately close this thread!

 

[mattura]

Good stuff.

As for the discussion about multiple encryptions, hashing hashes DOES NOT increase your security. I know it may seem like a good idea at first, but mathematically, you can only increase the 'security' of a hash by adding more bits to it (eg 256 is better than 128).

Imagine a 2-bit hash function - what ever your input, you can only produce one of the following outputs (binary):
00, 01, 10, 11
So let hash("x") = '01', hash(hash("x")) might be '11' for example, but it will still take four guesses to guarantee the correct answer (ie the same as the single hash). You are just wasting processing time.

And md5 has not been 'cracked', a hash function cannot be 'cracked', although there are readily available reverse hash tables, which people can lookup hashes and find possible words/phrases which generate them.
This is why it is a good idea to add a salt. These lookup tables use common English words/predicted passwords, so if you add something unusual to the user's chosen password before hashing, you ensure that if they choose a guessable password, a reverse hash table will still be of no use.

 

[vol7ron]

Mattura, at work I downloaded a lengthy paper written by some people at MIT that described the nature of the MD5 algorithm and the loophole in it. While it might have been wrong to say "cracked" as opposed to "hacked," the point is flaws have been found.

As a quick Google search has mentioned here: http://www.governmentsecurity.org/archive/t10777.html the Chinese and French also found flaws.

I would like to confirm that the number of bits is important in addition to the the algorithm used to hash. However, people should know that you should not go with a 1024b encryption just because it has more bits. While it probably is better, you have to realize this is still the internet where transaction time is important. 256b is that sweet spot that it'll take too long to brute force your way in and still maintain fast encryption checks. AES is still a better standard/encryption methodology to use over MD5.

As a good practice, it's generally better to have a symmetric algorithm and an asymmetric key. You should generally use a tough algorithm to encrypt the key. Therefore 256b AES, with a 1024b encrypted key.

 

[natsuki]

the maximum possible values you get in a hash function having n bits is 2^n. The probability that it gets cracked is 1/2^n. If you use m algorithms that hashes into n bits then you're increasing the chance of having a similar hash by m and hence the probability of collision increases to m/2^n . But if you use another algorithm giving a different number of bits then you increase your security exponentially.

But it is still unreasonable to use a 1024b unless you are the pentagon or something since as the number of bits increases the time and resources it takes increases (probably exponentially or worse).

 

[dickey]

why not pad your hashes with random hex numbers. let's say take the username and convert its characters to hex, then half it and pad it to the beginning and end. or use your imagination like somewhere in the middle.
Edit:
But as to the original question I think it was answered already. still it is nice to know that many people consider security for their sites.

just a thought though if you want to hard code your site.

using md5 and sha1 is quite acceptable as it hasn't been cracked yet. It's randomness makes it secure. Crackers would have to predict the unpredictable. Yet if there's a will there's a way. And it may not even be your hashing or encryption algorithm that will be targeted but by searching for exploits in your page.

 

[vol7ron]

I wish I could find the article. I thought for sure they found a way to crack md5. It was drawn out and very mathematically oriented, but I thought they found something more than a collision.

Padding is somewhat useless as once a pattern is found, it does nothing, but yes, that is another cryptographic method. If you're making it random, then what you're talking about is having more than one algorithm. Putting them together is the same effect as is splicing and joining more than one algorithm, which is a topic I'm getting ready to write about. What that comes down to is something more secure, but also more timely.

I think sha1 is better than md5, but both are good for quick protection until you've learned more about the cost/benefits from using them.

 

[mattura]

vol7ron, what you say in your last 2 posts is right, but it should be considered that most here are not looking to encrypt credit card info or anything that some malicious user would spend lots of time and money on trying to break. Therefore the ultimate security is not necessarily needed. As you say, it is about balancing security against the time taken to process the encryption.

md5 and other hashes have been found to have some flaws I know, but these are not useful when trying to crack passwords. Indeed the link you gave only pertains to hash collisions, not any other 'flaws'. The implications of this are when md5 and other hashes are used to verify contents (checksums), and that there is a possibility of different data producing the same checksum, meaning that checksums as proof are inadmissible in court.

Also I would point out that in the US and some other countries, encryption above a certain level is actually illegal, so you should check before using complex encryption algorithms. md5, for example, is fine in the US as it is 128 bit encryption.