so how would i crypt() this then
Password Encrytion Try something else
you could try changing this line.
GetSQLValueString($HTTP_POST_VARS['Password'], "text")); to this in the insert script
md5(GetSQLValueString($HTTP_POST_VARS['Password'], "text"))); and this line in login
$FF_valPassword=$HTTP_POST_VARS['password']; to
$FF_valPassword=md5($HTTP_POST_VARS['password']); but dont promise it will work
just switch the md5() with the crypt() function.
Ok got this to work for my form which enters the username and password into the database this is what i did
//i did md5(%s) works fine
$insertSQL = sprintf("INSERT INTO tb_clients (Username, Password) VALUES (%s, md5(%s))",
GetSQLValueString($HTTP_POST_VARS['Username'], "text"),
GetSQLValueString($HTTP_POST_VARS['Password'], "text"));
NOw all i need to do is get the log in form to recognize it,,, can't get it to work...
i tried
$FF_valPassword=md5($HTTP_POST_VARS['password']);any other sudjestions.....
try
$FF_valPassword=$HTTP_POST_VARS['password'];
$FF_valPassword=md5($FF_valPassword);
also have you increased thae size of your password field in database to allow for increase in password lenght due to md5
Thank you sidney that worked!!!!!!!!!!!!!!!!!!
now just one more thing 
I added this to the loged in page,, it restricks access to that page
via username and the password and access level,,,, how do i get this to red the md5 password as well....
Heres the code.......
<?php
// *** Logout the current user.
$FF_Logout = $HTTP_SERVER_VARS['PHP_SELF'] . "?FF_Logoutnow=1";
if (isset($HTTP_GET_VARS['FF_Logoutnow']) && $HTTP_GET_VARS['FF_Logoutnow']=="1") {
session_start();
session_unregister("MM_Username");
session_unregister("MM_UserAuthorization");
$FF_logoutRedirectPage = "login.php";
// redirect with URL parameters (remove the "FF_Logoutnow" query param).
if ($FF_logoutRedirectPage == "") $FF_logoutRedirectPage = $HTTP_SERVER_VARS['PHP_SELF'];
if (!strpos($FF_logoutRedirectPage, "?") && $HTTP_SERVER_VARS['QUERY_STRING'] != "") {
$FF_newQS = "?";
reset ($HTTP_GET_VARS);
while (list ($key, $val) = each ($HTTP_GET_VARS)) {
if($key != "FF_Logoutnow"){
if (strlen($FF_newQS) > 1) $FF_newQS .= "&";
$FF_newQS .= $key . "=" . urlencode($val);
}
}
if (strlen($FF_newQS) > 1) $FF_logoutRedirectPage .= $FF_newQS;
}
header("Location: $FF_logoutRedirectPage");
exit;
}
// *** Restrict Access To Page: Grant or deny access to this page
$FF_authorizedUsers=" 1";
$FF_authFailedURL="sorrytryagain.php";
$FF_grantAccess=0;
session_start();
if (isset($HTTP_SESSION_VARS["MM_Username"])) {
if (false || !(isset($HTTP_SESSION_VARS["MM_UserAuthorization"])) || $HTTP_SESSION_VARS["MM_UserAuthorization"]=="" || strpos($FF_authorizedUsers, $HTTP_SESSION_VARS["MM_UserAuthorization"])) {
$FF_grantAccess = 1;
}
}
if (!$FF_grantAccess) {
$FF_qsChar = "?";
if (strpos($FF_authFailedURL, "?")) $FF_qsChar = "&";
$FF_referrer = "Restricted Area";
$FF_authFailedURL = $FF_authFailedURL . $FF_qsChar . "accessdenied=" . urlencode($FF_referrer);
header("Location: $FF_authFailedURL");
exit;
}
?>
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<p> <a href="<?php echo $FF_Logout ?>">Log
Out</a></p>
<p> </p>
<p>guess what this worked </p>
</body>
</html>
Any ideas???????????
Erkilite, crypt() is no more secure then md5 when used in this way.
tomclaessens got it right by saying "Not because of the algorithm, but because of its use"
By using crypt in this way, you are duplicating the use of md5 as mentioned.
Considering that crypt() may also select a hashing algorithm based on the salt, I think that there may be problems with determining how much space is required to store the password, on different systems.
As such, it would be better to go with md5 immediately, with 32 chars required in hexadecimal string form.
Or if the version of PHP supports it, use sha1 which is less prone to hash collisions, with 40 chars required in hexadecimal string form.
Laserlight,
The problem with MD5 as a password function is
that it is very fast. This means anyone trying to
brute-force passwords can do so relatively quickly.
Crypt does lots of iterations, to slow the process
down. It is designed specificly for use with
passwords, unlike MD5.
The problem with crypt though is that is
system-dependent, so if you move your site to
another server your stored crypt'ed passwords may
not work anymore.
Define "brute force passwords".
Remember, again back to old discussions, that it is possible to delay the page when an incorrect password is entered, perhaps by using sleep().
To speak about "lots of iterations" is rather silly, since md5 does "lots of iterations" too.
On the other hand, if one were to try and brute force by finding a hash collision, md5 would be relatively weaker than crypt.
Still, it is much easier to intercept the plaintext transmission of the password since the hashing or encryption is done serverside.
Based on crypt() being system dependent, sha1() would then be a better alternative if one want to use such a function this way.
By "brute force" I mean offline password guessing
after stealing the database of hashes, like with
"crack" or "john the ripper" or whatever the
program of choice is these days. The programs
work by attempting common passwords and
variations, running them through the function until
they find a hash that matches (note that this is
NOT the same as finding a hash collision). This
type of attack was demonstrated in the thread
you linked to.
This attack requires stealing the database of
hashes first, but presumably that is part of the
threat model; as far as I know this is the only
reason to store md5/crypt hashes instead of
plaintext passwords.
It's possible to burn through passwords far faster
with plain MD5 than with a modern crypt function.
In fact, I think the MD5-crypt (from various BSDs,
and I think Linux now too) is 1000 iterations of
MD5, which should make it about 1000 times
slower. I think the classic DES-based crypt is only
a few times slower though.
Well thanks again for the help everyone.....
Got everything working fine now... if anyone wants the code for it there welcome to it...
just post a reply...
i have the log in page
and the loged in page
and the form the puts the username and password into the database...
The programs
work by attempting common passwords and
variations, running them through the function until
they find a hash that matches (note that this is
NOT the same as finding a hash collision).
Um, this is hash collision, i.e. the same output value is obtained from multiple different input values.
md5 is definitely weaker in this case since it doesnt depend on a (presumably unknown) salt, and there is no way to slow down the attacker.
This attack requires stealing the database of
hashes first, but presumably that is part of the
threat model; as far as I know this is the only
reason to store md5/crypt hashes instead of
plaintext passwords.
Indeed. My point is that the weakness in the system doesnt lie so much in the hashing/encryption done on the data, but in that the data is transmitted in plaintext.
Generally, in these sort of situations, if your database has been compromised such that the table containing the hashed/encrypted passwords can be obtained, then you're in a fair bit of trouble anyway.
trinitywave, sorry for not being able to help you much.
If you can try to explain your code more clearly, perhaps by using comments and choosing a common indent and naming style.
If you decide to release your code, maybe you could consider releasing it under an Open Source license such as the modified BSD license or the GNU GPL.
Erkilite, crypt() is no more secure then md5 when used in this way.
from the php manual
crypt() will return an encrypted string using the standard Unix DES-based encryption algorithm
I did not mention to use a 2 character salt but ... I think the DES encryption is a little more secure than the MD5 hash.
any one know for sure how much more secure DES is than md5?
The problem with crypt though is that is
system-dependent, so if you move your site to
another server your stored crypt'ed passwords may
not work anymore.
I have transferred DBs from windows 2k to FreeBSD to RedHat and the encryption is still the same. It may not be guaranteed machine independant but it works on the systems i have tried.
Originally posted by laserlight
Um, this is hash collision, i.e. the same
output value is obtained from multiple different
input values.
No, it is not a hash collision. The same output
value is obtained from the same input value.
Look at the thread Erklite linked to earlier for an
example. Epimeth posted an MD5 and guyryan100
used a brute-force approach to determine that the
word "nothing" was the original input. This is far
easier than producing a hash collision, because
people almost always use weak passwords.
Also, being able to produce hash collisions usually
doesn't make password cracking any easier.
Producing a collision usually means "find two
inputs with the same output", which is a much
weaker requirement than "find an input with the
same output as $foo".
The same output
value is obtained from the same input value.
Point taken.
On the other hand, this does not really matter much concerning the discussion, since by this time the attacker already has the hashed/encrypted password.
The point for keeping the passwords in the database not in plaintext form is so that the original passwords of the user cannot be easily obtained if the database is compromised.
It does not increase the security of the login system per se, since the transmission of the password is still in plaintext.
If a dictionary attack on the hashed password can be made without requiring a hash collision to obtain the same hash, then the password is weak enough such that hashing it for storage was quite useless in the first place.
Originally posted by laserlight
If a dictionary attack on the hashed password can
be made without requiring a hash collision to
obtain the same hash, then the password is weak
enough such that hashing it for storage was quite
useless in the first place.
No, not useless at all. You seem to be falling into a
"fallacy of the excluded middle".
If it takes days or weeks to break a password,
that's still far easier than producing a collision, but
if you can alert your users that your password
database has been stolen then a few days or
weeks could be enough time for most of your
users to change their passwords. It may even be
time consuming enough that the attacker won't
bother (maybe he'd rather spend his resources
cracking somebody else's password).
How long it takes to break a password is usually a
product of the strength of the password, multiplied
by the amount of time it takes to hash a
password, divided by the speed of the attacker's
hardware. So having a strong password, and a
slow hash (not vanilla MD5), is much better than
just having a strong password.
How long it takes to break a password is usually a
product of the strength of the password, multiplied
by the amount of time it takes to hash a
password, divided by the speed of the attacker's
hardware. So having a strong password, and a
slow hash (not vanilla MD5), is much better than
just having a strong password.
Actually there's more, since characteristics in a given algorithm may allow for the password breaker to save time.
In this respect from what I remember from some online articles, md5 does have some problems.
Nonetheless the fact is that this particular scheme of merely storing the password in hashed/encrypted form is inherently insecure.
If the salt in crypt() were used more effectively, or some other relatively random factor used to periodically make a given hash useless (assuming one used md5 or sha1), then it would be more viable security-wise.
If one really wished to have properly security, then something along the lines of SSL should be used.
MD5 has problems, but nothing that would affect
it's use as the basis of a password hash algorithm
(though using a stronger algorithm certainly
wouldn't hurt). As I mentioned earlier, being able
to find a collision doesn't necessarily help you to
crack passwords. If can produce a collision, you'd
have to somehow convince the user to use one of
those two inputs, then you could use the other
input as an alternate password... but if you can
convince the user to use a specific password then
you really don't need any cryptographic tricks at
all.
Salt is important for a password hashing scheme,
in that it prevents people from creating a
pre-computed dictionary of hashes and
passwords, and simply taking a hash and looking
up the password in that dictionary (they would
need a seperate dictionary for each salt value). It
doesn't make the more common brute-force
cracking against a single password any more
difficult though.
As for SSL, that is a completely different issue.
Security of the communications channel, versus
end-point security. SSL will prevent user
passwords from being sniffed over the wire, but it
won't prevent someone from gaining access to
your stored database of (plaintext|hashed)
passwords, nor will it make cracking the hashes
any more difficult. They really are seperate issues,
and you should use both (SSL, and strongly
hashed passwords).
but if you can
convince the user to use a specific password then
you really don't need any cryptographic tricks at
all
Social engineering doesnt count, neither does peeling off the poor fellow's password list from under his keyboard and using it
They really are seperate issues,
and you should use both (SSL, and strongly
hashed passwords).
Now we have an agreement 
Swosh! Part of that just went over my head.
Have a LOT to learn about security!
But from what I have read, Crypt is a little bit better then MD5 if used in a propper way!
But of what I could read, password typed in by the user is stored in the hash.... so how can I make the hased "plain text" password secure???
I recon this is how it kind of works:
- User goes to login page
- User types inn password
- Password is (so far) in plain text
- User clicks login button
- The system reads the typed (un-encrypted) password, encrypts it by using MD5 or Crypt and sends it off to the server
- Encrypted password is checked against stored (encrypted) password on server.
- PAssword is approved / rejected.