[Mriss]

How do I hash this script (login Script)

PHP код:

<?php
// checkLogin.php
session_start(); // Start a new session
require('conn.php'); // Holds all of our database connection information
// Get the data passed from the form
$username = $_POST['user'];
$password = $_POST['password'];
// Do some basic sanitizing
$username = stripslashes($username);
$password = stripslashes($password);
$sql = "select * from players where user = '$username' and pass = '$password'";
$result = mysql_query($sql) or die ( mysql_error() );
$count = 0;
while ($line = mysql_fetch_assoc($result)) {
     $count++;
}
if ($count == 1) {
     $_SESSION['loggedIn'] = "true";
     header("Location: loginSuccess.php"); // This is wherever you want to redirect the user to
} else {
     $_SESSION['loggedIn'] = "false";
     header("Location: loginFailed.php"); // Wherever you want the user to go when they fail the login
}
?>

[RajatPawar]

AFAIK, you can't hash a script. If you want to hash the passwords, hash the input using the hash() function in PHP, and also store it using the same hash when you register. Then you can simply check.

Also, mysql functions are somewhat deprecated - use PDO. The current code is poor.

[Mauzen]

PHP код:

<?php
// checkLogin.php
session_start(); // Start a new session
require('conn.php'); // Holds all of our database connection information
// Get the data passed from the form
$username = $_POST['user'];
$password = $_POST['password'];
// Do some basic sanitizing
$username = stripslashes($username);
$password = stripslashes($password);
$sql = "select * from players where user = '$username' and pass = SHA('$password')"; // Thats all
$result = mysql_query($sql) or die ( mysql_error() );
$count = 0;
while ($line = mysql_fetch_assoc($result)) {
     $count++;
}
if ($count == 1) {
     $_SESSION['loggedIn'] = "true";
     header("Location: loginSuccess.php"); // This is wherever you want to redirect the user to
} else {
     $_SESSION['loggedIn'] = "false";
     header("Location: loginFailed.php"); // Wherever you want the user to go when they fail the login
}
?>

You also need to do that when inserting the password into the database.
For further reading about more security, search for password salts, and javascript hashing before post, so the plain password is never sent to the server.
You should also use mysql_real_escape_string for $username and $password, else you got a perfect target for sql injection.

[Mriss]

So would this work?

PHP код:

<?php 
// checkLogin.php 

session_start(); // Start a new session 
require('conn.php'); // Holds all of our database connection information 

// Get the data passed from the form 
$username = $_POST['user']; 
$password = $_POST['password']; 

// Do some basic sanitizing 
$username = stripslashes($username); 
$password = stripslashes($password); 
function Whirlpool($str)
{
    return strtoupper(hash('whirlpool', $str));
}


$sql = "select * from players where user = '$username' and pass = Whirlpool('$password')"; 
$result = mysql_query($sql) or die ( mysql_error() ); 

$count = 0; 

while ($line = mysql_fetch_assoc($result)) { 
     $count++; 
} 

if ($count == 1) { 
     $_SESSION['loggedIn'] = "true"; 
     header("Location: loginSuccess.php"); // This is wherever you want to redirect the user to 
} else { 
     $_SESSION['loggedIn'] = "false"; 
     header("Location: loginFailed.php"); // Wherever you want the user to go when they fail the login 
} 

?>

> Thanks to ****** for his Whirlpool Function that works with SA:MP

[Kaperstone]

1. use mysqli.
2. ****** ported whirlpool to work with SAMP, he didn't make it.

Quote:

Just provides an implementation of the whirlpool hash algorithm for PAWN

3. An alternative to stripslashes() is mysqli_real_string_escape() which works better. this is why

Quote:

$password = hash("whirlpool",mysqli_real_escape_string($_POST["password"]));

[Mauzen]

Quote:

Originally Posted by ****** That's actually less useful than it sounds - you can never trust anything coming from the client, so you can't assume the javascript hashed correctly and wasn't compromised, or even that the JS ran at all (since people can have it disabled).

True, but actually you cant even trust the server, or ssl right now. The plain password can get compromised exactly the same way, it doesnt matter if attackers fake the password hash or the password itself. So I dont see any real disadvantages from this, but giving the user some more privacy is a pretty big advantage.
Edit: Sure, the hashing shouldnt be only on the client, but hashing it twice isnt a problem, its just about not revealing the users plain password.

[brent94]

Quote:

Originally Posted by Mauzen True, but actually you cant even trust the server, or ssl right now. The plain password can get compromised exactly the same way, it doesnt matter if attackers fake the password hash or the password itself. So I dont see any real disadvantages from this, but giving the user some more privacy is a pretty big advantage. Edit: Sure, the hashing shouldnt be only on the client, but hashing it twice isnt a problem, its just about not revealing the users plain password.

Why can't you trust SSL? The Heartbleed incident had to do with a vulnerable version of OpenSSL. As long as you don't use a vulnerable version, you're fine. I'd trust a website that actually uses SSL way more than a site that doesn't, but simply throws together some Javascript code that I could manipulate with ease.

@OP: As others have said, use MySQLi or PDO.

And although this is alright:

Quote:

Originally Posted by xkirill $password = hash("whirlpool",mysqli_real_escape_string($_POST["password"]));

I'd recommend doing it like this (using OOP):

Код:

$password = hash('whirlpool', $mysqli->real_escape_string($_POST['password']));

If you really want to boost security further, check out password_hash and password_verify

Edit: I looked over your code and noticed you don't protect against session fixation and session hijacking. It's quite a mouth full to explain, so I'll just send you here.

[brent94]

Quote:

Originally Posted by ****** Again, there's no need to escape a password you are hashing, since you are then hashing it which removes any additional characters anyway. If you REALLY want to worry about PHP security, check the input is a string not an array.

There are many parts to PHP security. We both mention different ones and IMO, they all should be used one way or another. We still haven't mentioned usernames. That's also user input. We'd definitely need to escape that, and also validate it (check for unacceptable characters, if it's in our set minimum and maximum length, etc.). A user authentication script in PHP is something that can't be thrown together in a day.

As for not needing to escape a password because it's being hashed anyway, it doesn't hurt to escape it. Sure, it's an extra step, but not a big deal.

[Mauzen]

Quote:

Originally Posted by brent94 Why can't you trust SSL? The Heartbleed incident had to do with a vulnerable version of OpenSSL. As long as you don't use a vulnerable version, you're fine. I'd trust a website that actually uses SSL way more than a site that doesn't, but simply throws together some Javascript code that I could manipulate with ease.

If passwords were prehashed everywhere, heartbleed would have had a way less impact on general security. You wouldnt have to change your passwords for non-openSSL services now.

Quote:

Originally Posted by ****** The downside is that locks out anyone without javascript, instead of relying solely on the server you control so know what is running.

In my opinion thats a matter of client security. People shouldnt use the same password for different services. But they do. For those guys prehashing would be a very easy way to provide extra security. I wouldnt call the javascript dependency a downside, the system would still work without javascript, those who dont want to use JS
just wouldnt benefit from it, but wouldnt have any disadvantages compared to the traditional hashing.
But those who use it (and Id say thats the majority, also most of the people who disable javascript wouldnt use non-unique passwords) would have additional securities.

[Kaperstone]

Quote:

Originally Posted by ****** The downside is that locks out anyone without javascript, instead of relying solely on the server you control so know what is running.

From : https://developer.yahoo.com/blogs/yd...led-14121.html

What are the chances that you'll have a visitor with JS disabled ?
out of 3bil internet users, the 1% of people will visit your website out of 1bil websites.


Relying on the information provided by this webiste