Encrypt / Decrypt MYSQL / PHP autoincrement ID

Without being rude, but already being: if you can decrypt something, your encryption algorithm sucks.

Today's most secure algorithms are one-way . That means you can not go back. Once encrypted, you can not "decrypt".

What applications do is compare the hashes of what is encrypted, if it gives a match okay, if not sorry.

What you can do at most is to encrypt the ID being sent on the form. The hash generated will be compared to the hash saved in the database and there you do what you want. Remember that you have to use the same encryption functions.

If you saved the ID in the database with SHA256, you must encrypt the form with SHA256.

In PHP:

<?php

$hash_id_do_formulario = hash("sha256", $_POST['id_do_formulario']);

// Procura no banco de dados pelo mesmo hash depois
$query = "DELETE FROM minha_tabela WHERE ID = :hash_formulario";

$statement = $minha_conexao_pdo->prepare($query);

$statement->bindParam(':hash_formulario', $hash_id_do_formulario);

$statement->execute();

Search for the hash function in PHP.

Description of the PHP documentation:

string hash ( string $algo , string $data [, bool $raw_output = FALSE ] )

I believe that what you are looking for would be to actually use what they call UUID (Universal Unique Identifier ), something like this token that you have decided to use.

Take a look at the UUID () function in MySQL, you might find it more interesting to use it.

The correct answer has some errors, in my opinion, that I have decided to give another answer.

mt_rand() (and str_shuffle() ) is predictable, a person with access to some response may be able to get the seed used, for example using UnTwister or the PHP_MT_SEED Cracker , out of many other ways.

Your code is public, so something like (date('s') + date('i') * 10000) is useless, after all the chances of our watches being different is negligible.

The strrev() will not add any security, this is worse than Cesar's Cipher because it had at least "some key."

When you execute SELECT , such as SELECT * FROM tabela WHERE token = $token , you are clearly vulnerable to timing-attack, a user can get information through the time consumed to execute the queries.

One solution would be to create two identifiers and search for them, one of them being compared securely with hash_equals.

Create two identifiers:

$pesquisar = random_bytes(8);
$confirmar = random_bytes(24);

Then insert it into the database, like:

INSERT tabela ('pesquisar', 'confirmar') VALUES ($pesquisar, $confirmar)

Remembering that both must be unique, $pesquisar has the same capacity as an int64, or BIGINT in the case of MySQL.

Search by value:

To search, use pesquisar as the main parameter, such as:

SELECT * FROM tabela WHERE pesquisar = $pesquisar

Then compare confirmar using hash_equals , like:

$stmt = $mysqli->prepare('SELECT confirmar FROM tabela WHERE pesquisar = ?')
$stmt->bind_param("s", $_GET['pesquisar']);

$stmt->execute();
$stmt->bind_result($confirmar);
$stmt->fetch();

if(hash_equals($confirmar, $_GET['confirmar']) === false){
    echo 'Valor de "confirmar" é incorreto';
}

For me this would be minimally safe. Of course, assuming you are using a safe operating system, random_bytes is set to /dev/urandom .

There are scenarios where obfuscating the ID can make sense. Sequential IDs can reveal a lot of your data set. An example is the Integrated Store, which shows the purchase ID at the end. It is a sequential number that reveals the amount of purchases already made in a particular store. A competitor could make small purchases over time to find out how the competitor's store sales are going.

Another example would be a URL with the customer ID. Someone with system access could be joking around with the IDs to know how many clients exist in the database.

This post describes in more detail: Auto-Incrementing IDs: Giving Your Data Away

In addition, it shows solutions for obfuscating the IDs in some languages, among them PHP: Tiny

Note that it obviously needs to be something reversible, otherwise you will not be able to get the ID back and update some information based on it yourself.