mikrocontroller.net

Forum: PC-Programmierung OpenSSL, Problem mit decrypt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Meun,

ich komme mit OpenSSL nicht weiter.

Kunde meint:

"wg. Beschränkungen in PHP 5.5 (ist leider veraltet) kann ich leider 
kein OpenSSL Pub- und PrivateKey Verschlüsselung mit AES-256-CBC nehmen. 
Es wird openssl_encrypt und openssl_decrypt mit AES-256-CBC und feste 
Schlüssel implementiert.

Spricht: bei Dekodierung bitte nutzen Sie von Ihnen gelieferten PubKey 
als Schlüssel. iv ist auch mitgeliefert."

OpenSSL scheint mir zum Decodieren zwingend einen private-key
zu verlangen (ist ja auch richtig so), binde ich das in mein
Programm ein stürzt es bei EVP_OpenInit() kommentarlos ab wenn
ich einen public-key verwendet. Beim private-key erhalte ich die
Meldung :

"5672:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs 
decoding error:.\crypto\rsa\rsa_pk1.c:273:
5672:error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check 
failed:.\crypto\rsa\rsa_eay.c:602:
"

Der angeblich iv ist also der erste Teil vor dem ':', die codierte
Nachricht der Rest ab ':'+1. Da würde mir aber der encrypted key fehlen.

Mit dem cmdline-Tool OpenSSL.exe ist dem Ding auch nicht beizukommen.

Ich habe mir die Quellen von PHP runtergeladen, die Funktionen
unter einem anderen Namen in mein Programm eingebaut und das
gleiche nochmal von openssl. Es knallt dann an einer Stelle wo
openssl zwingend einen private-key erwartet.

Im WWW finde ich auch nichts und die OpenSSL-Doku ist auch etwas
dürftig.

Wie kann ich da weiterkommen ?

Die keys haben wir hier selbst erzeugt. Auch mit OpenSSL.

Win10, GNU-Compiler, OpenSSL 0.9.81

: Bearbeitet durch User
von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Ich habe mir die Quellen von PHP runtergeladen, die Funktionen
> unter einem anderen Namen in mein Programm eingebaut und das
> gleiche nochmal von openssl. Es knallt dann an einer Stelle wo
> openssl zwingend einen private-key erwartet.

Du hast also verschiedene Varianten der Funktionen von OpenSSL unter 
unterschiedlichen Namen gleichzeitig in Dein Programm gelinkt?

Das wird ziemlich sicher schief gehen. Denn OpenSSL ist ziemlich 
komplex. Es hat eigene lokale Variablen, Zustände, etc. die Du von 
"außen" nicht so leicht siehst, die aber dennoch im Namensraum vorhanden 
sind und beim dynamischen Linken schnell mal verwechselt werden. Das 
alles komplett sauber zu trennen und unter vollständig unterschiedlichen 
Namen bereitzustellen ist gar nicht so einfach.

Du solltest tunlichst nur eine einzige Version von OpenSSL in ein 
Programm linken.

Ich würde als erstes mal die Umgebung des Kunden so gut wie möglich bei 
Dir nachstellen, inkl. dem Code fürs ver- und entschlüsseln. Dann kannst 
Du Stück für Stück Teile davon ändern bis Du bei Deiner Umgebung bist. 
Wenn zu viel auf einmal geändert wird bzw. unterschiedlich ist, ist es 
nicht so einfach die Ursache für die Probleme zu erkennen.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Die Namen der Funktionen hatte ich geändert ;)

Nachstellen isat so eine Sache, dann müßte ich mir PHP auf
meinen Webserver legen. Normalerweise fasse ich das nur mit
der Beißzange an ...

Der Kunde (Wirtschaftsing. (FH)) hat PHP 5.5 (uralt) und will
unbedingt AES-256-CBC und ich soll das mit dem public-key
entschlüsseln. Die PHP-Funktion "openssl_open" schluckt aber
mittels EVP_OpenInit nur private keys. Irgendwie stimmt da
etwas nicht und ich habe halt kaum einen Plan von Verschlüsselung.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Der String den ich über CGI bekomme, hat den Aufbau:

envelopekey + ':' + nachricht.

Den iv müßten dann doch die ersten 16 Byte von nachricht sein,
das Chiffrat dann ab nachrift+16 ?

Das dann mit EVP_OpenInit( ctx, cipher, envelopekey,
Länge envelopekey, iv, private_key) öffnen. Da haut's
es raus mit:

2492:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs 
decoding error:.\crypto\rsa\rsa_pk1.c:273:
2492:error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check 
failed:.\crypto\rsa\rsa_eay.c:602:

cipher: EVP_get_cipherbyname( "aes-256-ebc);
private_key: pkey aus dem privaten Key
Andere Laufzeitfehler habe ich nicht.u

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:

> "wg. Beschränkungen in PHP 5.5 (ist leider veraltet)

PHP 5.5 ist seit über 3 Jahren EOL und wird nicht mehr mit 
Sicherheitsupdates versorgt. Statt da jetzt noch was reinzufrickeln, 
wäre ein Update auf eine neuere PHP-Version angesagt.

Bei Einsatz solch komplett veralteter Software sind auch die drohenden 
Geldbußen aus der DSGVO mit einzukalkulieren, wenn es zum Hack kommt.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
PHP 5.5 ist kundenseitig. Denen ist das egal.

von sym (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

AES ist ein symmetrisches Verschlüsselungsverfahren und hat entsprechend 
nur einen Schlüssel, der für Ver- und Entschlüsselung verwendet wird 
(Dieser soll ja wohl fest im Code eingebaut werden). EVP_OpenInit() wird 
für asymmetrische Verschlüsselungen verwendet. Einfach mal nach "C 
openssl decrypt aes" suchen...

Viele Grüße

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Danke, ich suche gleich mal ... ;)

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
sym schrieb:

> AES ist ein symmetrisches Verschlüsselungsverfahren und hat entsprechend
> nur einen Schlüssel, der für Ver- und Entschlüsselung verwendet wird
> (Dieser soll ja wohl fest im Code eingebaut werden).

Erstens baut man keine Schlüssel fest im Code ein. NIEMALS.

Zweitens funktionieren ALLE asymmetrischen Verschlüsselungsverfahren so, 
daß nicht die eigentlichen Daten asymmetrisch verschlüsselt werden, weil 
das viel zu langsam wäre. Stattdessen wird asymmetrisch nur ein 
symmetrischer Schlüssel ausgetauscht, mit welchem dann die eigentlichen 
Daten verschlüsselt werden.

Worum es hier also geht, ist die Nachrüstung von AES-256-CBC für diese 
letztere Phase, und nicht darum, mit einem fest codierten Schlüssel 
symmetrisch zu verschlüsseln.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Hi Nop,

ich bin Opfer, nicht Täter.

Diese Firma mit dem Wirtschaftsinformatiker (FH) hat unserem
Kunden eingeredet, man müsse bei einer https-Verbindung ein
eingegebenes Passwort nochmal berschlüsseln damit's sicher
wird. Die gleiche Firma besteht auf ihrem Uralt-PHP 5.5.

Asymetrisch kann er halt nicht.

Symmetrisch bekommt heute Lieschen Müller geknackt. Ich weiß es,
Du weißt, er glaubt es nicht, der Kunde glaubt ihm halt.

Du kennst "Rache per Rechnung" ?

Mich hält der Mist von wichtigeren Sachen ab, erst der Blödsinn
mit sscanf() und GNU, jetzt dies.

Ich möchte es halt vom Tisch haben und habe OpenSSL unterschätzt.

von Hinter (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Danke, damit probiere ich gerade herum.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
ciphertext müsste die chiffrierte Nachricht nach dem ':'
sein, das Teil vorher der iv. Der key könnten die ersten
16 (?) Byte des Chiffrats sein. Ich probiere.

Im Moment:

3124:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong 
final block length:.\crypto\evp\evp_enc.c:520:

bei EVP_DecryptFinal()

von Hinter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat die Nachricht denn eine valide Größe?

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Weiß ich nicht.

Komplett sind es 85 Btye,
der Teil vor dem ':' sind 16 Byte, der danach 60.

von Heiko L. (zer0)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Symmetrisch bekommt heute Lieschen Müller geknackt. Ich weiß es,
> Du weißt, er glaubt es nicht, der Kunde glaubt ihm halt.

Du siehst aber schon noch den Widerspruch, dann der symmetrischen 
Verschlüsselung der Verbindung trauen zu wollen?
Ich weiß es nicht.

von vn n. (wefwef_s)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Nachstellen isat so eine Sache, dann müßte ich mir PHP auf
> meinen Webserver legen. Normalerweise fasse ich das nur mit
> der Beißzange an ...

Für sowas hat man Testumgebungen.

Nop schrieb:
> PHP 5.5 ist seit über 3 Jahren EOL und wird nicht mehr mit
> Sicherheitsupdates versorgt. Statt da jetzt noch was reinzufrickeln,
> wäre ein Update auf eine neuere PHP-Version angesagt.
>
> Bei Einsatz solch komplett veralteter Software sind auch die drohenden
> Geldbußen aus der DSGVO mit einzukalkulieren, wenn es zum Hack kommt.

Richtig. 87 Sicherheitslücken allein seit 2017.
https://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Es dekodiert mir jetzt da etwas (leider Unsinn).

Vermutlich stimmt der key zum Entschlüsseln nicht.
if ( 1 != EVP_DecryptInit_ex( ctx, EVP_aes_256_cbc(), NULL, key, iv))
        handleErrors( __LINE__);

if ( 1 != EVP_DecryptUpdate( ctx, plaintext, &len, ciphertext, ciphertext_len))
        handleErrors( __LINE__);
        plaintext_len = len;
if ( 1 != EVP_DecryptFinal_ex( ctx, plaintext + len, &len))
        handleErrors( __LINE__);
// Zeile vorher fliegt er mit wrong final block length raus 
        plaintext_len += len;
In plaintext steht Müll.

Als key habe ich den base64-String aus dem public-key genommen
und das base64 decodiert. Im Programmbeispiel aus 
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
haben die da einfach einen willkürlichen String genommen.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Noch eine Frage: Immerhin kommt er durch 2 der 3 Funktionen
lebendig und ohne Fehlermeldungen durch. Kann ich davon ausgehen,
daß iv und Chiffrat stimmen ?

von Sheeva P. (sheevaplug)


Bewertung
3 lesenswert
nicht lesenswert
Joachim D. schrieb:
> PHP 5.5 ist kundenseitig. Denen ist das egal.

"Sehr geehrte Damen und Herren,

im Rahmen meiner Bedenkenhinweis- und Sorgfaltspflichten muß ich Sie 
leider nachdrücklich darauf hinweisen, daß die von Ihnen verwendete 
Software PHP in der Version 5.5 bereits seit geraumer Zeit veraltet ist 
und vom Hersteller nicht mehr mit Sicherheitsupdates versorgt wird. Eine 
solche veraltete Software im freien Internet einzusetzen, stellt ein 
hohes Sicherheitsrisiko für Sie, Ihre Kunden, und andere Internetnutzer 
dar.

Daraus ergeben sich erhebliche Haftungsrisiken sowohl für Sie, als auch 
für mich als Ihrem Dienstleister. Zu meinem tiefsten Bedauern muß ich 
Ihnen leider mitteilen, daß ich diese Risiken nicht tragen kann.

Hinzu kommt, daß einige der von Ihnen gewünschten Funktionen nicht mit 
dieser veralteten Software realisieren lassen.

Deswegen empfehle ich Ihnen dringend, auf eine aktuelle und unterstützte 
Version der Software zu wechseln. Ansonsten sehe ich mich leider 
gezwungen, von Ihrem Auftrag zurückzutreten, um unkalkulierbare Risiken 
für mich und meine Geschäftstätigkeit zu vermeiden.

Mit freundlichen Grüßen,
XY"

von Joachim D. (Firma: JDCC) (scheppertreiber)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal den Quellcode und das Laufzeotprotokoll angehängt.

Irgendwie kommt mir der public key merkwürdig vor, sollte der
nicht 26 Bit (64 Gebisse) und nicht 294 Byte haben ?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Hi Nop,
>
> ich bin Opfer, nicht Täter.

Dann ergreife die Flucht.

Denn in 3 weiteren Jahren wird aus irgendeinem anderen Grund (zum 
Beispiel weil es endlich gekracht hat) der nächste kommen und sich den 
Flickenteppich und das ganze Elend genau anschauen und dann taucht Dein 
Name in einer Reihe mit den anderen Namen auf die an der Entstehung und 
an der Aufrechterhaltung dieses Pfusch damals aktiv mitgewirkt haben.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Diese Firma mit dem Wirtschaftsinformatiker (FH) hat unserem
> Kunden eingeredet, man müsse bei einer https-Verbindung ein
> eingegebenes Passwort nochmal berschlüsseln damit's sicher
> wird.

Das ist einerseits nicht ganz falsch, andererseits aber auch nicht ganz 
richtig. Richtig ist: wenn man das Paßwort auf dem Server speichert -- 
was zur Überprüfung der Login-Credentials natürlich notwendig ist --, 
dann muß dies verschlüsselt geschehen. Ansonsten bekommt ein Angreifer, 
der in den Server, die Datenbank oä eindringen kann, das 
Klartextpaßwort.

Das Mittel der Wahl ist in solchen Fällen, das Paßwort nicht im 
Klartext, sondern als kryptografischen Hash zu speichern. Dieser wird 
aus dem Paßwort mit einer Einweg-Funktion (früher gerne MD5, heute 
lieber SHA) erzeugt und läßt keine Rückschlüsse auf das Paßwort zu. Zur 
Überprüfung des Paßwortes wird aus dem vom Nutzer eingegebenen Paßwort 
mit derselben Funktion wieder ein kryptografischer Hash erzeugt und mit 
dem gespeicherten verglichen. Stimmen beide Hashes überein, so war das 
eingegebene Paßwort korrekt.

Symmetrische oder asymmetrische Verschlüsselungsverfahren sind hier 
jedoch deplatziert, es kommt auf eine sichere Hashfunktion an. Zudem 
kann die Sicherheit des Hashes noch durch ein sogenanntes Salt erhöht 
werden, um bestimmte Angriffsarten wie zB solche mit vorberechneten 
Rainbow Tables zu erschweren, siehe dazu auch [1] und dort verlinkte. 
Zusätzlich kann auch noch ein sogenanntes Pepper genutzt werden, siehe 
dazu auch den Artikel.

Übrigens: um Updates der verwendeten Hashfunktion zu ermöglichen, wird 
sie heutzutage meistens zusammen mit dem kryptografischen Hash abgelegt, 
so daß aus dem Paßwort "hallo" mit dem Salt "123" und der Hashfunktion 
SHA256 als Speicherwert so etwas wie "sha256:123:12f...eec" ergibt.

> Die gleiche Firma besteht auf ihrem Uralt-PHP 5.5.

Das ist grob fahrlässig. Mindestens.

[1] https://de.wikipedia.org/wiki/Salt_(Kryptologie)

von Marten Morten (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> ich bin Opfer, nicht Täter.

Nein, du willst die Kohle, also bist du Mittäter.

> Diese Firma mit dem Wirtschaftsinformatiker (FH)

Ja, ja, wir haben schon verstanden, aber seine Kohle willst du doch.

Joachim D. schrieb:
> Es dekodiert mir jetzt da etwas (leider Unsinn).
...
> Als key habe ich den base64-String aus dem public-key genommen
> und das base64 decodiert.

Du hast es immer noch nicht verstanden? AES ist symmetrisch. Es gibt nur 
einen Schlüssel, keine Trennung in öffentlichen und privaten Schlüssel.

> Im Programmbeispiel aus
> https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
> haben die da einfach einen willkürlichen String genommen.

Nein, sie haben den GLEICHEN Key für Ver- und Entschlüsselung genommen, 
weil AES symmetrisch ist.

Joachim D. schrieb:
> Irgendwie kommt mir der public key merkwürdig vor, sollte der
> nicht 26 Bit (64 Gebisse) und nicht 294 Byte haben ?

Nochmal: S-Y-M-M-E-T-R-I-S-C-H.


 symmetrisches Verschlüsselungsverfahren,

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde der Firma beim Abschied noch ans Herz legen doch vielleicht in 
Betracht zu ziehen die Serverinfrastruktur von einer Firma zu mieten 
oder betreuen zu lassen die die sowas hauptberuflich dauerhaft warten 
und pflegen kann anstatt zu versuchen das heimwerkermäßig ohne eigene 
Fachkräfte selber zu machen (und dabei wie üblich kläglich zu 
scheitern).

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Es macht (im Moment) keinen Sinn gegen diese Firma zu
schießen. Mir war schon klar daß das ziemlich unausgegoren
bis fahrlässig ist.

Ich bin halt kein Kryptograph, für mich ist OpenSSL momentan
noch ein ziemliches und unüberschautes Monster.

Frage: der key hat bei AES256 64 Byte ?

von Heiko L. (zer0)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Es macht (im Moment) keinen Sinn gegen diese Firma zu
> schießen. Mir war schon klar daß das ziemlich unausgegoren
> bis fahrlässig ist.
>
> Ich bin halt kein Kryptograph, für mich ist OpenSSL momentan
> noch ein ziemliches und unüberschautes Monster.
>
> Frage: der key hat bei AES256 64 Byte ?

https://de.wikipedia.org/wiki/Advanced_Encryption_Standard

Und spenden nicht vergessen!

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Habe ich vorhin gelesen ;)

Ist halt ein recht komplexes Thema. Es würde mir ja schon
weiterhelfen wenn ich die Funktionsparameter verifizieren
könnte. So stochere ich nur im Nebel ;(

von FS (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Nachdem was ich so lese, scheinst du kein Sicherheitsexperte zu sein. 
Darum meine Empfehlung: Sobald irgendetwas mit Verschlüsselung ins Spiel 
kommt sollte man dies von jemandem planen und implementieren lassen, der 
sich damit auskennt und Erfahrung damit hat, ansonsten handelt man sich 
sehr leicht die ein odere andere Sicherheitslücke ein, oft nur weil man 
als Laie eine Kleinigkeit übersehen hat.

Ein System sicher zu machen bedeutet mehr als nur eine Bibliothek 
irgendwo einzubinden und dann irgendwie zum Laufen zu bringen. Man 
sollte schon ein schlüssiges Konzept und verstanden haben, was man da 
tut und wie die einzelnen Komponenten funktionieren.

Das Buch "Cryptography Engineering" ist in dem Zusammenhang sehr 
lesenswert, Verfasser u.a. Bruce Schneier.

Sieht man ja u.a. bei den vermeintlichen "Experten" bei Nissan, was 
ansonsten dabei rauskommt: Da wird mal eben die in jeder 
Windschutzscheibe lesbare VIN (die letzten fünf oder sechs Stellen sind 
eine fortlaufende Nummer) als API-Schlüssel für die Fahrzeugsteuerung 
per App verwendet und ein vermeintlicher Fix nach einem freundlichen 
Hinweis durch einen Sicherheitsexperten 1:1 von StackOverflow nicht etwa 
nur kopiert, sondern offensichtlich abgetippt (aufgefallen aufgrund von 
Schreibfehlern).

Das Einzige, was man zugute halten kann ist die Tatsächen, offenbar 
nicht blind auf SSL/TLS zu vertrauen. Würde ich auch nicht. Nur sollte 
das zweite Sicherheitsnetz dann auch halten.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
FS schrieb:
> Nachdem was ich so lese, scheinst du kein Sicherheitsexperte zu sein.

Asudrücklich: Ich bin es nicht.

Das Konzept an sich ist trotzdem Käse, er will es, er bekommt es.
Ich sehe keinen Sinn darin, innerhalb einer https-Verbindung noch
einmal zu verschlüsseln.

von vn nn (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> FS schrieb:
>> Nachdem was ich so lese, scheinst du kein Sicherheitsexperte zu sein.
>
> Asudrücklich: Ich bin es nicht.
>
> Das Konzept an sich ist trotzdem Käse, er will es, er bekommt es.

Und du hast gar keine Gewissensbisse, für sowas Geld zu nehmen?

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Nein. Warum auch ?

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Ich sehe keinen Sinn darin, innerhalb einer https-Verbindung noch
> einmal zu verschlüsseln.

Sehr gut... wenn das TLS sauber konfiguriert ist.

Mir ist auch rein technisch schleierhaft, wie das funktionieren soll.

Denken wir uns einen Anwendungsfall... Der Anwender ruft die Seite auf 
und möchte sich dort authentifizieren. Er gibt einen Benutzernamen und 
ein Paßwort ein, und übermittelt diese an die Seite.

Schon hier wird die Sache problematisch. Tatsächlich müßten die 
Credentials clientseitig noch einmal verschlüsselt werden, nach Deinen 
Aussagen wohl per AES. Das Dumme ist: AES ist eine symmetrische 
Verschlüsselung, die also auf einem gemeinsamen Schlüssel basiert, die 
sie sowohl zur Ver- als auch zur Entschlüsselung zwingend kennen muß.

Wie soll das gehen? Okay, der Benutzer gibt seine Credentials nicht per 
HTTP Base Auth oder HTTP Digest auth ein, sondern in ein HTML-Formular. 
Beim Klick auf "Login" muß also ein Skript die ins Formular eingegebenen 
Credentials auslesen, sie mit einem (dem Skript bekannten) AES-Schlüssel 
verschlüsseln und an den Server senden, der sie mit dem gemeinsamen 
Secret (Schlüssel) entschlüsselt und gegen die Benutzerdatenbank prüft. 
Das kann man machen, aber es erhöht die Sicherheit kein bisschen. 
Natürlich kann man das mit obfuskiertem Code, aber... nein.

Ich ganz persönlich glaube immer noch, daß Dein Problem daran liegt, daß 
Du die Unterschiede zwischen einem kryptografischen Hash, einer 
symmetrischen und einer asymmetrischen Verschlüsselung nicht verstanden 
hast.

Leider bist Du auf meine Beiträge nicht eingegangen, obwohl ich Dir 
gerne helfen würde. Zudem hast Du auch andere Beiträge ignoriert, die 
Dir die Unterschiede zwischen symmetrischer und asymmetrischer 
Verschlüsselung nahebringen wollten. Daher bleibt mir nur, Dir viel 
Glück zu wünschen.

von René H. (mumpel)


Bewertung
-1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> dann müßte ich mir PHP auf
> meinen Webserver legen.

Schau Dir mal XAMPP an. https://www.apachefriends.org/de/index.html

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert

von René H. (mumpel)


Bewertung
0 lesenswert
nicht lesenswert
Weshalb?

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Weshalb?

Weil es hier um Deployment geht, nicht um Implementierung. Simple.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Hi Sheeva,

ich habe das nicht ignoriert. Der Unterschied ist mir klar - ich
hatte das Thema doch leicht unterschätzt und mich im Web eingelesen.

HTTP Base Auth (https://de.wikipedia.org/wiki/HTTP-Authentifizierung)
ist halt relativ schmucklos ;) Das werden die auch nicht wollen.

Vom Ablauf her loggen sich die User auf dem Kunden-Host ein und
diese Benutzerdaten werden an unseren Server weitergeleitet, der
das noch mal gegenprüft. Aktuelle Benutzerlisten kommen nacht per
ftp vom Kunden und werden automatisch verarbeitet.

Es geht nur um die Übertragung der Kenndaten des bereits eingeloggten
Users an unseren Server (per https). Das "sichert" er mit AES256
irgendwie ab. Deshalb würde HTTP Base Auth da vermutlich auch
nicht einzusatzen, der User ist ja bereits authentifziert.

Ich kann das gesamte Konzept beim Kunden nicht umwerfen, es geht
mir im Moment nur darum dieses $//%§/-Gebilde zu entschlüsseln.

Daß man da eigentlich viel tiefer bohren müßte ist klar (PHP5.5,
Know-How in Kryptographie etcpp).

Grüße Joe.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Vom Ablauf her loggen sich die User auf dem Kunden-Host ein und
> diese Benutzerdaten werden an unseren Server weitergeleitet, der
> das noch mal gegenprüft. Aktuelle Benutzerlisten kommen nacht per
> ftp vom Kunden und werden automatisch verarbeitet.

Äh, das heißt, der User wird zweimal authentifiziert und autorisiert? 
Darf ich fragen, warum? Reichte es nicht aus, wenn der Kundenhost den 
Benutzer authentifiziert und den Benutzernamen für die Autorisierung auf 
dem von Dir betriebenen Host übergibt?

> Es geht nur um die Übertragung der Kenndaten des bereits eingeloggten
> Users an unseren Server (per https). Das "sichert" er mit AES256
> irgendwie ab. Deshalb würde HTTP Base Auth da vermutlich auch
> nicht einzusatzen, der User ist ja bereits authentifziert.

Klar.

> Ich kann das gesamte Konzept beim Kunden nicht umwerfen, es geht
> mir im Moment nur darum dieses $//%§/-Gebilde zu entschlüsseln.

Das müßte aber auch OpenSSL in einer Uralt-Version hinbekommen, AES ist 
ja jetzt wirklich nicht sooo neu ;-)

In der allergrößten Not kannst Du auch einen Subprozeß mit
openssl aes-256-cbc -d -in - -pass pass:<passwort> -out -

starten, bei dem Stdin und Stdout Pipes zum Elternprozeß sind, und auf 
die stdin-Pipe dann Deinen verschlüsselten String schreiben und über die 
stdout-Pipe den entschlüsselten String lesen. Das ist aus vielen Gründen 
nicht schön, schon gar nicht auf einem Multiusersystem; besser wäre es 
wohl, mit "-pass file:<datei>" das Paßwort über eine (vor dem Zugriff 
anderer User geschützten) Datei zu übergeben.

Ich gebe allerdings zu bedenken, daß Dein Server ebenfalls nur einen 
kryptografischen Hash des Paßwortes benötigt und auch vom Kundenhost nur 
ein ebensolcher übergeben werden muß. Dann könnt Ihr Euch den ganzen 
Unfug mit der AES-Verschlüsselung innerhalb einer verschlüsselten 
Connection auch gleich sparen.

Darüber hinaus... wenn Dein Server das Klartext-Paßwort kennt und die 
Userdaten per FTP übertragen werden, dann geschieht diese Übertragung 
gänzlich unverschlüsselt, und wenn jemand die Kommunikation zwischen dem 
Kundenhost und Deinem Server abhören kann -- wogegen der Herr Winf ja 
wohl seine spezielle "Sicherheitsmaßnahme" eingebaut hat -- kommt er auf 
diesem Wege an das Paßwort, ohne die Verschlüsselung von HTTPS zu 
knacken. Besser wäre es, das verschlüsselt über SCP, SFTP oder FTPS zu 
synchronisieren... oder Deinem Server verschlüsselten Zugriff auf die 
Benutzerdatenbank des Kunden zu geben, idealerweise readonly.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
'Winf' ist ein schöner Ausdruck, den merke ich mir ;)

Klar gibt das da noch weitere Leichen im Keller. Soweit ich weiß
werden die Daten nachts per ftps: übertragen, das paßt schon.

Im Moment speichere ich die Paßwörter noch im Klartext, bei anderen
verwende ich MD5 (ich brauche die Paßwörter ja nicht, es reicht
ja zu wissen das es stimmt). Besser wäre, die auch noch zu
verschlüsseln. Da muß ich noch die Laufzeiten testen.

Der Winf besteht darauf, das nochmal zu verschlüsseln und
glaubt einfach nicht, daß https das auch schon macht und das die
Sicherheit nicht erhöht.

Na gut, bekommt er das halt.

Im Moment wurde er erstmal gebeten, zu dokumentieren wie er die
Verschlüsselung eigentlich macht. Die 7 Schlüssel die ich bis jetzt
bekommen habe passen alle nicht ;(

Ich denke, dem Winf sollte mal klar gemacht werden wo die
Sicherheitsprobleme liegen. Zumindest zum größten Teil vor seinem
Monitor (ca. 30 cm).

Grüße Joe

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> 'Winf' ist ein schöner Ausdruck, den merke ich mir ;)

;-)

> Klar gibt das da noch weitere Leichen im Keller. Soweit ich weiß
> werden die Daten nachts per ftps: übertragen, das paßt schon.

Okay, dann ist ja alles gut... ;-)

> Im Moment speichere ich die Paßwörter noch im Klartext, bei anderen
> verwende ich MD5 (ich brauche die Paßwörter ja nicht, es reicht
> ja zu wissen das es stimmt). Besser wäre, die auch noch zu
> verschlüsseln. Da muß ich noch die Laufzeiten testen.

Wenn sie per MD5 (oder besser: SHA) gehasht sind, ist das im Endeffekt 
wie eine Verschlüsselung -- nur daß man den Hash halt nicht mehr 
entschlüsseln kann. Muß man ja auch nicht, solange man die Hashes 
vergleichen kann, und genau dasselbe gilt auch für die Übertragung per 
FTPS bzw HTTPS.

> Der Winf besteht darauf, das nochmal zu verschlüsseln und
> glaubt einfach nicht, daß https das auch schon macht und das die
> Sicherheit nicht erhöht.

Klarer Fall von "Schuß nicht gehört", sorry...

> Im Moment wurde er erstmal gebeten, zu dokumentieren wie er die
> Verschlüsselung eigentlich macht. Die 7 Schlüssel die ich bis jetzt
> bekommen habe passen alle nicht ;(

LOL

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Und genau diesem Szenario stehe ich als Nicht-Kryptograph gegenüber.

PHP decodiert es, wenn ich mir aus dem Quellcode die entsprechenden
Funktionen rausziehe und verwende, funktioniert es nicht. Das war
mit RC4. Auf den Tip, RC4 wäre nun wirklich nicht mehr das Gelbe
vom Ei hat er dann etwas mit AES-256 zusammengebrockelt. Das will
aber nicht.

Mal schauen was der Winf noch so rüberschickt ;)

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Auf den Tip, RC4 wäre nun wirklich nicht mehr das Gelbe
> vom Ei hat er dann etwas mit AES-256 zusammengebrockelt.

Warum hast Du ihn zu AES gedrängt und Dein Leben schwerer gemacht? Da 
Verschlüsselung an der Stelle ja eh vollkommen nutzlos ist hättest Du 
auch Rot13 vorschlagen können!

--

Sag ihm er soll Dir einfach einen Hash schicken denn Du sagst ja Du 
brauchst das Passwort eigentlich gar nicht, wozu also umständlich etwas 
verschlüsselt senden was am Ende gar nicht gebraucht wird?

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Warum hast Du ihn zu AES gedrängt und Dein Leben schwerer gemacht? Da
> Verschlüsselung an der Stelle ja eh vollkommen nutzlos ist hättest Du
> auch Rot13 vorschlagen können!

Ist wurscht, das klappt ja auch nicht.

Ich hätte ihm leicht verstimmte Buschtrommeln vorschlagen
sollen. Wenn er das a auf 476 Hz nimmt bekommt das auch
keiner mit ;)

Es war nicht meine Idee.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Es war nicht meine Idee.

Ja, das hattest Du schon eingangs erwähnt, aber Bernds eigentlicher 
Punkt ist natürlich trotzdem unumstößlich richtig: es ist gar nicht 
nötig, dort Paßworte im Klartext zu übertragen.

Tatsächlich birgt die Übertragung der Klartext-Paßworte sogar drei 
weitere große Sicherheitsrisiken, nämlich a) deren Speicherung auf dem 
Kundenhost, b) die Speicherung auf Deinem Host, sowie c), die 
Übertragung.

Zu a): Wenn ein Angreifer in den Host Deines Kunden eindringen und dort 
die gespeicherten Klartext-Paßworte auslesen kann, dann kommt er in den 
Besitzs der Klartext-Paßworte.

Zu b): Dasselbe gilt, wenn ein Angreifer in Deinen Host eindringen kann 
und dort die Klartext-Paßworte auslesen kann.

Zu c): Wenn der Angreifer sich als Man-in-the-Middle etablieren und die 
Hosts in ein Downgrade der Verschlüsselung zu einem unsicheren 
Algorithmus zwingen, oder anderweitig die Kommunikation belauschen kann, 
gelangt er auf diesem Weg ebenfalls in den Besitz der Klartext-Paßworte.

Vor diesem Hintergrund erscheint es mir als umso bessere Idee, die best 
practices der IT-Sicherheit anzuwenden, und schon auf dem Ursprungshost 
des Kunden lediglich kryptografische gesalzene und womöglich auch 
gepfefferte Hashes der Paßworte zu sichern, und ebendiese dann auch auf 
Deinen Host zu übertragen. Egal, wo unser Angreifer dann eindringen 
kann, ob in den Host des Kunden, in Deinen Host, oder in die 
Kommunikation: auch im schlimmsten Fall kommt er maximal an die 
kryprografischen Hashes der Paßworte, niemals aber an die 
Klartext-Paßworte. Damit entfällt auch die ohnehin fragwürdige 
Notwendigkeit einer weiteren Verschlüsselung der Kommunikationsinhalte.

Trotzdem haben der Winf und Du einen weiteren Vorteil, nämlich daß Ihr 
die Applikationen auf Kunden- und die auf Deiner Seite für diese 
Möglichkeiten umbauen müßt und daher einen Auftrag daraus generieren 
könnt -- vielleicht hat der Winf es ja gerade nötig, wer weiß... ;-) 
Nichtsdestotrotz wäre das ein wesentlicher Zugewinn an Sicherheit und 
obendrein der den Empfehlungen des Bundesamtes für Sicherheit in der 
Informationstechnik (BSI) folgende aktuelle Stand der Technik, so daß im 
Schadensfall auch niemand für deren Mißachtung haftbar gemacht wird oder 
sich zumindest schämen müßte... ;-)

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Sheeva,

das ist alles richtig.

Streng genommen brauche ich in diesem Fall das Paßwort überhaupt nicht,
es reicht ja die Information "user ist autentifiziert". Er hat sich
ja schon im Kundensystem eingeloggt. Das würde das Problem atomisieren.
Ich denke mal drüber nach.

Die Punkte b) und c) wären damit erledigt.

Auf a) habe ich schlicht keinen Einfluß.
Ich kann es anregen ... ;)

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe das gerade mal in der Firma besprochen.

Der Kunde stellt sein System um und macht künftig nur noch
direkte Belegabrufe über SOAP. Ein explizites Login ist dann
nicht mehr notwendig.

Künftig = sie wissen noch nicht wie, kein Knowhow im Haus,
der BER wird vorher fertig ;)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Streng genommen brauche ich in diesem Fall das Paßwort überhaupt nicht,
> es reicht ja die Information "user ist autentifiziert". Er hat sich
> ja schon im Kundensystem eingeloggt. Das würde das Problem atomisieren.
> Ich denke mal drüber nach.

Du kannst das verschlüsselte Passwort schon jetzt wie einen Hash 
benutzen, tu einfach auf Deiner Seite so als wäre es ein Hash und 
versuch erst gar nicht es zu entschlüsseln da es ja eh gar keine 
Notwendikeit gibt an den Klartext ranzukommen.

: Bearbeitet durch User
von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Leider doch. Anhand des Benutzernamens setze ich die Zugriffsrechte.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Leider doch. Anhand des Benutzernamens setze ich die Zugriffsrechte.

Deswegen habe ich schon oben einen expliziten Unterschied zwischen der 
Authentifizierung (auch: Authentisierung) und der Autorisierung gemacht.

Die Authentifizierung stellt sicher, daß der Benutzer derjenige ist, als 
welcher er sich ausgibt. Dabei werden die Login-Credentials (meistens 
Benutzername und Paßwort) überprüft, und dazu braucht der Authenticator 
-- also die Maschine bzw. Software, die diese Prüfung vornimmt -- 
natürlich einen Zugriff auf das Paßwort oder, wie oben bereits 
beschrieben, einen kryptografischen Hash davon.

Bei der Autorisierung geht dann darum, die Zugriffsrechte (Privilegien) 
zu prüfen, die der Benutzer auf die Assets (Geräte, Software, Dateien) 
dieses Systems hat. Dabei wird beim Zugriff auf ein Asset nur noch die 
Frage beantwortet: ist der Benutzer bereits authentifiziert, und darf er 
auf das angeforderte Asset zugreifen. Da die Login-Credentials hier 
üblicherweise nicht mehr zusätzlich überprüft, werden, braucht der 
Autorisator keinen Zugriff auf das Paßwort; stattdessen muß er nur 
wissen, welche Rechte die jeweiligen Benutzer haben.

Im Fall von HTTP(S) läuft das Zusammenspiel der Autentifizierung und der 
Autorisierung meistens wie folgt: zunächst loggt sich der Benutzer mit 
seinem Benutzernamen und seinem Paßwort ein, dafür setzt der Server ein 
Cookie mit einer Session-ID (Autentifizierung). Bei Zugriffen auf die 
Assets (URLs) des Servers erkennt derselbe sich über die Session-ID den 
authentifizierten Benutzer und prüft gegen seine Rechte-Datenbank, ob 
der Benutzer auf dieses Asset (den URL) zugreifen darf.

Lange Rede, kurzer Sinn: wenn die Authentifizierung bereits auf dem Host 
Deines Kunden stattfindet und auf Deinem Host nurmehr eine 
Autorisierung, dann brauchst Du das Paßwort gar nicht, sondern nur die 
Liste der Rechte Deiner Benutzer. Dann muß das Paßwort aber auch mehr 
übertragen oder gar verschlüsselt werden, und Ihr könnt Euch den ganzen 
Quatsch sparen. ;-)

von Joachim D. (Firma: JDCC) (scheppertreiber)


Bewertung
0 lesenswert
nicht lesenswert
Völlig korrekt. Das ist auch meine Idee. Salopp gesagt, kann
keiner hacken was ich nicht habe und nicht übertragen wird.
Die Verantwortung liegt dann alleine beim Kunden.

Die Autorisierung mache ich ohne Cookie. Ich lege Datum/Zeit
und die Benutzerkenndaten in der Website und auf dem Server
ab und vergleiche das dann. Paßt das nicht zusammen -> exit.

Ich muß an den ganzen Kram nochmal ran ;)

Grüße Joe und vielen Dank für deine Anregungen !

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.