Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Friday, September 14, 2018

Speed Up and Secure SSH to Linux by Disabling GSSAPI-Authentication

Every time you try to connect with SSH after you enter your username, GSSAPI Authentication will attempt to authenticate you using the Kerberos protocol.

The problem with this is that nobody sets up GSSAPI Authentication services: this is both a waste of time and a security risk, as you are attempting to authenticate a service that you're not hosting, and is therefore prone to "Man in the Middle" attacks.

Unfortunately, GSSAPI Authentication with SSH in Linux is the default option. You can easily turn it off by doing the following. Open the SSH config file...

[user@localhost /]$ vi etc/ssh/ssh_config

And then find this line...

Host *
GSSAPIAuthentication yes

You may not have GSSAPIAuthentication set there yet, but you will want to find the line beginning with Host *. And then you can adjust it like so...

Host *
GSSAPIAuthentication no

Now your SSH will load instantly and securely.

Sunday, August 26, 2018

How do I Salt and Encrypt Passwords in PHP?

Salting a password occurs when you add text to a password to make it longer and more complex.

For instance, "myPassWord" would be "myPassWordSomeSalt". Since this is longer, when it is encrypted, it will become a more complex result.

Then when you compare the "salted password" to a user's password, you just append "SomeSalt" to the user's input. Your condition looks like...

if(COMPARE($_POST['password'] . 'SomeSalt', $db['password'])) {...}

While this was useful at one time, this concept of salting is now built-in to passwords in PHP. You can simply do...

$hash = password_hash($password, PASSWORD_DEFAULT);
if(password_verify($password, $hash) {
// password is valid!
}

This saves you time in coding, and also means that a more reliable, mathematically-based password salt is generated and used.

Source: http://php.net/manual/en/function.password-hash.php

Tuesday, August 21, 2018

Should Or Shouldn't I Use the MySQL_* functions in PHP?

There are a number of ways to access your MySQL server from PHP.

The first way, and the one originally taught, was to use the specialized MySQL functions in PHP, such as mysql_query(), mysql_connect(), and mysql_real_escape_string().

However, there are two problems with this function set.

First, it uses escaped strings, which are ultimately unsafer, slower, and less reliable than using Prepared Statements in MySQL.

Second, the developers behind the MySQL_* functions are no longer developing it, they no longer accept feedback on it, and they ask users to move onto something more reliable, with Prepared Statements, for MySQL uses.

This second reason is so strong, that all MySQL_* functions have been removed from PHP version 7.0 and up. Learn to do prepared statements, or these two reasons will perpetually haunt your code.

Monday, August 20, 2018

How do I prevent MySQL Injection with PHP?

We all know that you can make a simple form with some HTML, put together a quick PHP script, build a few MySQL tables, and you have yourself a full, working application in a matter of minutes.

Your PHP may end up initally looking like this...

$sql = "SELECT * FROM SomeTable WHERE id = " . $_POST['id'];

The HTML script would contain the necessary form and input elements, and SomeTable would be in the database. But this creates the possibility of a MySQL injection.

To prevent mysql injection, we send the SQL query and user input in SEPARATE statements, called Prepared Statements. Put a question mark where you want the variable to be...

$db_link = new mysqli($hostname, $username, $password, $database);
$sql = "SELECT * FROM SomeTable WHERE id = ?";
$statement = $db_link->prepare($sql);
$statement->bind_param($_POST['id']);

This will prevent users from submitting malicious data. Imagine, for example, if someone tried to submit an 'id' of value "0 AND DROP TABLES;", which would have a negative consequence on your app.