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
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.
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.
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
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.
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
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.
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.
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()
Weiß ich nicht. Komplett sind es 85 Btye, der Teil vor dem ':' sind 16 Byte, der danach 60.
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.
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
Es dekodiert mir jetzt da etwas (leider Unsinn). Vermutlich stimmt der key zum Entschlüsseln nicht.
1 | if ( 1 != EVP_DecryptInit_ex( ctx, EVP_aes_256_cbc(), NULL, key, iv)) |
2 | handleErrors( __LINE__); |
3 | |
4 | if ( 1 != EVP_DecryptUpdate( ctx, plaintext, &len, ciphertext, ciphertext_len)) |
5 | handleErrors( __LINE__); |
6 | plaintext_len = len; |
7 | if ( 1 != EVP_DecryptFinal_ex( ctx, plaintext + len, &len)) |
8 | handleErrors( __LINE__); |
9 | // Zeile vorher fliegt er mit wrong final block length raus
|
10 | 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.
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 ?
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"
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 ?
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.
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)
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,
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).
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 ?
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!
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 ;(
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.
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.
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?
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.
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
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.
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
1 | 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.
'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
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
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 ;)
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?
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.
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... ;-)
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 ... ;)
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 ;)
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
Leider doch. Anhand des Benutzernamens setze ich die Zugriffsrechte.
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. ;-)
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 !
Kleiner Nachschlag: Es funktioniert jetzt endlich. Ursache: Der Herr Wirtschafstingenieur hatte per php_openssl_encrypt() verschlüsselt und das dann nochmal base64 codiert. Der String aus php_openssl_encrypt() ist aber schon base64 (schlecht dokumentiert). Einfacher Fehler aber man sucht sich einen Wolf ;(
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.