php[world] in Washington, D.C.

Verschlüsseltes Speichermodell

SSL/SSH schützt zwar die gerade auf dem Weg befindlichen Daten vom Client zum Server: SSL/SSH schützt jedoch nicht die dauernd in einer Datenbank gespeicherten Daten. SSL ist ein "auf-der-Leitung" Protokoll.

Hat ein Angreifer direkten Zugriff auf Ihre Datenbank (den Webserver umgehend), können gespeicherte heikle Daten aufgedeckt oder zweckentfremdet werden, außer wenn die Information von der Datenbank selbst geschützt ist. Die Daten zu verschlüsseln ist ein guter Weg, diese Gefahr zu mildern, doch bieten nur wenige Datenbanken diese Art der Verschlüsselung von Daten.

Der einfachste Weg, dieses Problem zu umgehen ist, erst einmal Ihr eigenes Verschlüsselungspaket zu erstellen, und dieses dann in Ihren PHP Skripten zu nutzen. PHP kann Ihnen in diesem Fall mit seinen verschiedenen Erweiterungen helfen, wie z.B. Mcrypt and Mhash, welche eine große Auswahl an Verschlüsselungsalgorhythmen abdecken. Das Skript verschlüsselt die Daten vor dem Speichern, und entschlüsselt diese wieder beim Erhalt. Siehe die Verweise für weitere Beispiele, wie Verschlüsselung arbeitet.

Im Fall von wirklich versteckten Daten, wenn deren unverfälschte Repräsentation nicht nötig ist (z.B. keine Anzeige), ist hashing ebenfalls überlegenswert. Das bekannte Beispiel für Hashing ist das Speichern des MD5 hash eines Passwortes in einer Datenbank, anstatt des Passwortes selbst. Siehe auch crypt() und md5().

Beispiel #1 Verwenden eines hashed Passwortfeldes

// Speichern des Passwort hash
$query  = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
            pg_escape_string($username), md5($password));
$result = pg_query($connection, $query);

// Afragen, ob der User das richtige Passwort übermittelt hat
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
            pg_escape_string($username), md5($password));
$result = pg_query($connection, $query);

if (pg_num_rows($result) > 0) {
    echo "Welcome, $username!";
} else {
    echo "Authentication failed for $username.";
}
add a note add a note

User Contributed Notes 4 notes

up
19
seigoryu at hotmail dot de
1 year ago
I would strongly recommend using SHA-2 or better the new SHA-3 hash algorithm. MD5 is practically unusable, since there are very well working rainbow tables around the whole web. Almost the same for SHA-1. Of course you should never do a hash without salting!
up
9
Reiner
3 years ago
Using functions to obfuscate the hash generation does not increase security. This is security by obscurity. The algorithm used to hash the data needs to be secure by itself.

I would not suggest to use other data as salt. For example if you use the username, you won't be able to change the values without rehashing the password.

I would use a dedicated salt value stored in the same database table.

Why? Because a lot of users use the same login credentials on different web services. And in case another service also uses the username as salt, the resulting hashed password might be the same!

Also an attacker may prepare a rainbow table with prehashed passwords using the username and other known data as salt. Using random data would easily prevent this with little programming effort.
up
3
somebody
7 years ago
A better way to hash would be to use a separate salt for each user. Changing the salt upon each password update will ensure the hashes do not become stale.
up
-1
Fairydave at the location of dodo.com.au
8 years ago
I think the best way to have a salt is not to randomly generate one or store a fixed one. Often more than just a password is saved, so use the extra data. Use things like the username, signup date, user ID, anything which is saved in the same table. That way you save on space used by not storing the salt for each user.

Although your method can always be broken if the hacker gets access to your database AND your file, you can make it more difficult. Use different user data depending on random things, the code doesn't need to make sense, just produce the same result each time. For example:

if ((asc(username character 5) > asc(username character 2))
{
   if (month the account created > 6)
      salt = ddmmyyyy of account created date
   else
      salt = yyyyddmm of account created date
}
else
{
   if (day of account created > 15)
      salt = user id * asc(username character 3)
   else
      salt = user id + asc(username character 1) + asc(username character 4)
}

This wont prevent them from reading passwords when they have both database and file access, but it will confuse them and slow them up without much more processing power required to create a random salt
To Top