Eingegebene Benutzerdaten für die Laufzeit geschützt ablegen?

KlyX · 5. Januar 2018, 23:29

Hallo zusammen,

wie ist das denn eigentlich: ich übergebe Logindaten (User in Klartext, Passwort als Hash) aus VB an ein PHP-Script (POST-Daten). PHP-seitig wird geprüft, ob die Daten korrekt sind und je nachdem ein entsprechender Return-Wert geliefert.
Da es sich um eine API handelt und zur Programmlaufzeit immer wieder (zusammen mit den Credentials) darauf zugegriffen werden muss, müssen ja Benutzername und Passwort-Hash in der Programmlaufzeit immer mal wieder verwendet und übertragen werden.

Macht es denn deshalb Sinn bzw. ist es überhaupt möglich, diese Daten - solange sie nicht genutzt werden - irgendwo "sicher" aufzubewahren? Ich kann sie einfach in globale Variablen legen - aber ist das sinnvoll?
Oder spielt es sowieso keine Rolle, da ich die Daten ja immer mal wieder nutze und sie somit in den Momenten eh abgegriffen werden könnten?
Falls es geht - und sinnvoll ist - womit macht man sowas? Hab nichts gefunden für klassisches VB

Danke und Gruss,
KyX

NoIde · 6. Januar 2018, 00:11

Wirklich sicher ist nichts. Du könntest SecureString verwenden, dann bleiben die Daten nur so lange im RAM wie du es bestimmst.
msdn.microsoft.com/de-de/libra…curestring(v=vs.110).aspx

Mehr ist wohl nicht drin. Klar kannst du die Daten auch kryptisch in variablen haben, vorm abschicken dann entkrypten, aber wirklich mehr sicherheit bringst nicht.

RodFromGermany · 6. Januar 2018, 17:02

KlyX schrieb:

Passwort als Hash

Ist Hash hier korrekt?
Das ist nicht in jedem Falle eineindeutig!Sollte da nicht eine Verschlüselung verwendet werden?

KlyX · 6. Januar 2018, 18:14

Wie bezeichnest du das?

VB.NET-Quellcode

Dim pwd As String = Password & Salt
Dim hasher As New Security.Cryptography.SHA256Managed()
Dim pwdb As Byte() = System.Text.Encoding.UTF8.GetBytes(pwd)
Dim pwdh As Byte() = hasher.ComputeHash(pwdb)
Return Convert.ToBase64String(pwdh)

Würde sagen, es ist verschlüsselt oder?

NoIde · 6. Januar 2018, 18:32

KlyX schrieb:

verschlüsselt

Nein ist es nicht, versuch das mal zu entschlüsseln. Ein Hash ist kein Verschlüsselung, da es nur in einer Richtung funktioniert.

@RodFromGermany

Warum sollte man ein Passwort verschlüsselt senden anstatt gehashed? Solange man HTTPS nutzt um die Daten ans PHP zu senden ist doch alles OK.

SpaceyX · 6. Januar 2018, 19:14

Warum solltest Du besondere Vorkehrungen treffen, solange sich das Passwort im Memory befindet? Ist doch eh alles nicht mehr sicher seit den neuesten "Enthüllungen". Jedoch würde ich mir Gedanken machen, ob Du überhaupt bereit dazu bist, eine "sicherheitskritische" Anwendung zu entwickeln, bzw. zu betreuen, da Du ja offensichtlich nicht mal den Unterschied zwischen Verschlüsselung und Prüfsummen kennst. Sollte ein Angreifer im System des Nutzers sitzen, hat er bestimmt nicht im Sinn, ein Passwort für eine API abzugreifen. Der Anwender hat dann weitaus ernsthaftere Probleme. Ferner macht es für Man-In-The-Middle-Attacken keinen Unterschied, ob Du das Passwort im Klartext oder gehashed übergibst, solange Du nur prüfst, ob der Hash, bzw. das Passwort korrekt ist. Da aber der Traffic in der Regel ohnehin verschlüsselt ist, langt es, die Prüfsumme des Passwortes zu übergeben, so hat ein Angreifer wenigstens nicht die Möglichkeit, das Passwort des Anwenders zu kennen. Soll ja Menschen geben, die nutzen überall das gleiche PW.

KlyX · 6. Januar 2018, 20:28

Also ich war ursprünglich der Meinung dass es ein Hash ist. Aber nach der frage von Rod war ich dann verwirrt in Bezug auf die Funktion die ich nutze.

Also Hash passt dann. Und ich kenne den Unterschied sehr wohl.

Übertragung erfoltg natürlich verschlüsselt - Verbindung über http wird vom Server abgelehnt. Bei der Verbindung wird zudem bei der Anfrage vom Server ein Token und ein Session-Cookie generiert. Auch diese beiden Elemente müssen passen. Sonst gibt die Api einen Error 401 aus.
wie könnte ich es sonst besser machen? Bzw. Was macht Sinn?

NoIde · 6. Januar 2018, 20:33

Also in der DesktopApp kannst nicht viel machen. Bietest du diese API selbst an? Falls ja könnte mann mal schauen wie du die Daten im PHP validierst.

KlyX · 6. Januar 2018, 21:49

Okay, gut zu wissen.
Die API biete ich selbst an, ja.
Ich nutze eine einfach REST-API aus diesem Projekt github.com/mevdschee/php-crud-api

Dieses Add-On nutze ich zur Absicherung/Authentifizierung gegenüber der API: github.com/mevdschee/php-api-auth
Die Absicherung basiert beim Addon auf in PHP Hard-coded username und passwort. Hier habe ich in die Auth.php noch eine Funktion eingebaut, die mir anhand des Benutzernamens den in der DB gespeicherte Password-Hash ausliest. Statt den hardcoded-Daten werden dann Benutzername und Passwort-Hash abgeglichen.
Rest ist gleich geblieben.

NoIde · 6. Januar 2018, 22:16

Also für's erste schauts OK aus. Konnte auffe schnelle nichts kritisches finden.

KlyX schrieb:

noch eine Funktion eingebaut, die mir anhand des Benutzernamens den in der DB gespeicherte Password-Hash ausliest.

Hier kann aber was drin sein. Wenn du magst kannst du den geänderten Code zeigen, dann können wir schauen.

KlyX · 6. Januar 2018, 22:42

Gerne doch - mein PHP ist leider nicht sonderlich gut

Das hier ist die zusätzliche Funktion, mit der ich über die DB den PW-Hash auslese.
Die Funktion ist in der auth.php der Authentifizierungs-Addons eingebaut, aber außerhalb der großen Klasse in der auth.php.
In der Auth.php ist sie drin, weil dort die Post-Daten ankommen.

Für die DB-Abfrage habe ich PDO mit einem prepared statement verwendet.

PHP-Quellcode

function getpasswordhash()
{
include 'db_connect.php';
$benutzername = $_POST["username"];
$statement=$pdo->prepare("SELECT * FROM users WHERE username= ?");
$statement->execute(array ($benutzername));
while($row = $statement->fetch()) {
$password_hash = $row['password'];
}
return (array ($benutzername, $password_hash));
}

Ja, ich weiss - das while kann noch weg

In der API.php rufe ich zusätzlich zu Beginn diese Funktion auf und benutze später die beiden Variablen für Username und <PW-Hash statt dem fest eingetragenen String:

PHP-Quellcode

require 'auth.php';
//Ruft Benutzername und Passwordhash aus der entsprechenden Funktion der auth.php ab
list ($username,$password_hash) = getpasswordhash();
//Statt hardcoded benutzername und Passwort, werden hier die oben gelesenen Variablen verwendet, um Username und Passwort(hash) zu prüfen.
$auth = new PHP_API_AUTH(array(
'authenticator'=>function($user,$pass) use ($password_hash, $username) {
if ($user==$username && $pass==$password_hash) $_SESSION['user']=$user;
}
));
if ($auth->executeCommand()) exit(0);
if (empty($_SESSION['user']) || !$auth->hasValidCsrfToken()) {
header('HTTP/1.0 401 Unauthorized');
exit(0);
}

Nach dem Code folgt dann die API.
Das ist soweit alles.

Wenn ich irgendwie noch was besser absichern kann/soll/muss, nur heraus damit.
Und ja, ich will mich genau deswegen an eine Anwendung wagen, die einen Login verwendet und auf eine externe MySQL-DB zugreift schreiben. Genau weil ich mich seit Jahren nicht mehr damit befasst habe und mein Wissen nicht mehr State of the Art ist. Nur muss ich sowas selbst ausprobieren - am besten mit Projekt

Die Anwendung soll ein Tool in der Firma ersetzen, welche die Zugangsdaten zur MySQL-DB hart codiert hat...

Übrigens: das letzte Mal, dass ich mit Passwort-Hashs gearbeitet habe war, als man noch mit MD5 gehasht hat

NoIde · 7. Januar 2018, 09:44

Es scheint so OK zu sein, werde nach einem 2. Kaffee noch einmal schauen. Was ich persönlich nicht schön finde ist, das du auf SuperGlobals direkt zugreifst, ich nutze bei SuperGlobals immer filter_input, da du Prepared Statements nutzt ist das hier weniger tragisch. Auch finde ich den Mix aus MySQLi und PDO in einem Projekt wenig gut. Bisher also nur kleine "Schönheits"-Sachen zu bemängeln.

KlyX · 7. Januar 2018, 22:00

Danke für den Typ mit filter_input. Kannte ich gar nicht

Wie gesagt, PHP hab ich nicht wirklich drauf

Aber filter_input klingt einfach. Kann ich ja noch anpassen.
Was PDO angeht: ich hab mal gelernt, PDO ist sicher. Aber wie es scheint, ist MySQLi alternativ auch okay. Aber solange es nur ein Schönheitsfehler ist kann ich damit leben

Deine 2. Tasse Kaffee muss übrigens ganz schön gross sein

NoIde · 7. Januar 2018, 23:19

KlyX schrieb:

Deine 2. Tasse Kaffee muss übrigens ganz schön gross sein

Au ja, XXL-Format(Anhang). Ich hatte schon einen genaueren Blick darauf geworfen, hatte mich aber ablenken lassen, so kam ich nicht mehr bis zum Ende, hohle ich morgen mit einer kleineren Tasse Kaffee nach, sorry.

@KlyX konnte nicht mehr finden, scheint gut.

KlyX · 8. Januar 2018, 09:32

Haha
alles gut, musste nur etwas schmunzeln

so wichtig ist das hier auch nichr

Eingegebene Benutzerdaten für die Laufzeit geschützt ablegen?

Eingegebene Benutzerdaten für die Laufzeit geschützt ablegen?

KlyX schrieb:

VB.NET-Quellcode

KlyX schrieb:

KlyX schrieb:

PHP-Quellcode

PHP-Quellcode

KlyX schrieb:

Ähnliche Themen

4 Benutzer haben hier geschrieben