TIA Eingabe (z.B.: Passwort) verschlüssen

R

ReiniDerWemser

Level-2
Beiträge
9
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,
wir wollen an unserer Anlage die Benutzer mit ihrern RFID Tokens An- und Abmelden lassen. Dazu lesen wir den UID aus und vergleichen diese dann mit der Datenbank, die auf der Steuerung in einem DB hinterlegt sein wird.


Da der Kunde jedoch eine 2AF wünscht haben wir uns darauf geeinigt, dass jeder Benutzer sich beim An- und Abmelden noch mit seim eigenen Passwort den Vorgang bestätigen muss. Ob das Passwort dann in der Datenbank oder auf dem Token hinterlegt ist, ist noch nicht geklärt.


Da es seitens des Kunden auch gewisse Passwortrichtlienen gibt z.B. Groß- Kleinschriebung, mind. eine Zahl und ein Sonderzeichen UND dass das Passwort nicht in "Klartext" irgendwo gespeichert sein darf, stellt sich mir nun die Frage wie ich die Verschlüsslung auf der SPS realisiere.


Meine Idee wars auf dem HMI ein Eingabefeld für das Passwort zu erstellen und das Passwort dann den ASCII Zeichen in HEX umzuwandeln und dann anhand der HEX Zeichen zu ermitteln ob die Passwortrichtlienen erfüllt sind. (Zum Erstellen / Ändern des Passwortes)


Beim An- und Abmeldevorgang müsste ich dann das eingegeben Passwort in HEX umwandeln und das dann mit dem hinterlegten Passwort (Datenbank oder Token) zu vergleichen.
Nun habe ich die Beführchtung das dem Kunden die HEX Variante noch nicht ganz ausreicht, weil es ist zwar dann nicht in "Klartext" hinterlegt jedoch ist das Passwort auch nicht wirklich "verschlüsselt" sondern nur umgewandelt.


Leider konnte ich aber bis jetzt nicht herrausfinden, wie bzw. ob man ein Verschlüsslungsverfahren z.b. SHA-256 (Hash-Wert erzeugen) in der SPS durchführen kann. Kann mir da jemand weiterhelfen?


Die Eingesetzten Komponenten wären:
CPU ET200SP
HMI TP1900 Comfort
RFID-Leser RF310R
 
Vielen Dank für die Hinweise.

Jedoch wurde heute vom Kunden festgelegt, dass wir die Passwörter in mindestens SHA2 verschlüsseln müssen. Daher würde ich mit der MD5 Variante nicht weiter kommen. Besteht den überhaupt die Möglichkeit die Passwörter in SHA2 zu verschlüsseln auf der SPS?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ReiniDerWemser schrieb:
Besteht den überhaupt die Möglichkeit die Passwörter in SHA2 zu verschlüsseln auf der SPS?
Zum Vergrößern anklicken....

Warum nicht, die Berechnung ist nicht sonderlich aufwändig. Du nimmst z.B. einen entsprechende Referenzimplementierung in C und schreibst das nach SCL um.

Aber wenn schon beachtet wird dass MD5 nicht sicher ist, dann sollte man es auch komplett richtig machen.
Bei deinem Prinzip verschickst du so wie es sich anhört die Passwörter im Klartext an die SPS. Da bräuchte also jemand nur am Netzwerk mitlauschen und kann alles mitschreiben, solange die Verbindung nicht wirklich sicher ist.

Auch wenn das Problem mit deiner Passwortrichtlinie schon abgeschwächt wird, solltest du den Passworthash noch mit etwas Salz versehen. Andernfalls lassen sich durch die Geschwindigkeit des Hashalgorithmus sehr schnell sehr viele Passwörter durchprobieren und die Hashwerte mit den gespeicherten vergleichen, und für viele oft benutzte Passwörter existieren vorberechnete Tabellen. Ohne dieses Salz besitzen zwei gleiche Passwörter auch den gleichen Hashwert.
 
Thomas_v2.1 schrieb:
Warum nicht, die Berechnung ist nicht sonderlich aufwändig. Du nimmst z.B. einen entsprechende Referenzimplementierung in C und schreibst das nach SCL um.

Aber wenn schon beachtet wird dass MD5 nicht sicher ist, dann sollte man es auch komplett richtig machen.
Bei deinem Prinzip verschickst du so wie es sich anhört die Passwörter im Klartext an die SPS. Da bräuchte also jemand nur am Netzwerk mitlauschen und kann alles mitschreiben, solange die Verbindung nicht wirklich sicher ist.

Auch wenn das Problem mit deiner Passwortrichtlinie schon abgeschwächt wird, solltest du den Passworthash noch mit etwas Salz versehen. Andernfalls lassen sich durch die Geschwindigkeit des Hashalgorithmus sehr schnell sehr viele Passwörter durchprobieren und die Hashwerte mit den gespeicherten vergleichen, und für viele oft benutzte Passwörter existieren vorberechnete Tabellen. Ohne dieses Salz besitzen zwei gleiche Passwörter auch den gleichen Hashwert.
Zum Vergrößern anklicken....

Vielen Dank für Antwort.

Das verfahren mit dem Salz ist mir bekannt, jedoch weiß ich noch nicht wie man die Umwandlung von C in SCL macht. Weil in C habe ich ja ganz andere Biblotheken als in SCL.

Wenn ich jetzt zum Beispiel diesen Quellcode nehme: https://www.youtube.com/watch?v=AU-4oLUV5VU
Da ist ja die Biblothek "System.Security.Cryptography...." in der schon das Verfahren zum Hashen vorgesehen ist.
Wie wandelt man den sowas dann in SCL um?
 
Thomas_v2.1 schrieb:
Warum nicht, die Berechnung ist nicht sonderlich aufwändig. Du nimmst z.B. einen entsprechende Referenzimplementierung in C und schreibst das nach SCL um.

Aber wenn schon beachtet wird dass MD5 nicht sicher ist, dann sollte man es auch komplett richtig machen.
Bei deinem Prinzip verschickst du so wie es sich anhört die Passwörter im Klartext an die SPS. Da bräuchte also jemand nur am Netzwerk mitlauschen und kann alles mitschreiben, solange die Verbindung nicht wirklich sicher ist.
Zum Vergrößern anklicken....
Für diesen SHA-Berechnung anstatt SCL in den SPS, VBS in den HMI ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine 2 Factor Authorisation macht ja nur Sinn, wenn das Passwort nicht in Klartext and die PLC übertragen wird (HEX ist Klartext). Das kommt aber immer mit einer Menge Haaken und Ösen, wenn man es richtig machen will. Deshalb sollte man sich anschauen, was man hier eigentlich absichern will - den Zugriff auf das Panel, oder den Zugriff auf die PLC?

1) Beim Panel, genügt es wie Jesper empfoheln hat forzugehen. D.h. den Passwort-Hash generieren, persistieren und vergleichen finden lokal auf dem Panel statt.

2) Bei der PLC, hat man gleich einen Sack voll von extra Problemen.
Unabhängig davon ob ein Passwort verhashed ist oder nicht, wenn es über eine unverschlüsselte Kommunikation zur PLC gesendet wird, kann es jeder mitlesen. Denn ja, ein Hash ist kein Klartextpasswort, aber halt immer die selbe Bytewurst. Was im Sinne der lokalen Vergleichbarkeit auch sinnvoll ist. Nur will man soetwas nicht über eine ungesicherte Verbindung schicken. Weil es dann jeder mitlesen und später in einer Attacke auch an die PLC schicken kann. Der Angreifer ist ja nicht gezwungen das Klartext-PW durch den Hashgenerator zu jagen.
Deshalb braucht man die verschlüsselte Kommunikation.
Die verschlüsselte Kommunikation benötigt zumindest am Anfang ein asymmetrisches Verschlüsselungsverfahren für den Key Austausch, welches nach dem Key-Austausch durch ein symmetrisches Verfahren abgelöst werden kann.
Ein Angreifer könnte sich aber trotzdem noch zum Panel als PLC ausgeben und zur PLC als Panel. Dann kann er auch am Verschlüsselungsverfahren teilnehmen und kann dann alles mitlesen. Deshalb bringt Verschlüsselte Kommunikation ohne Authentifizierung gar nichts. D.h. PLC und HMI müssen sich gegenseitig Authentifizieren, also nachweisen, dass sie wirklich sie selbst sind.

Ich fasse nochmal zusammen: Hash, asymmetrisch verschlüsselte Kommunikation, Authentifizierung

Wie man einfach sieht, ist von der Komplexität der Umsetzung "C-Code nach SCL" noch das allergeringste Problem im Fall, dass die PLC abgesichert werden soll.
 
Zurück
Oben