Angriffe mit dem richtigen Verfahren abwehren

Kryptoverfahren: Welche sollte man verwenden bzw. meiden?
Keine Kommentare

Die Auswahl an Kryptoverfahren ist, sofern man sich auf bekannte Algorithmen beschränkt, recht übersichtlich. Einige dieser Algorithmen sollte man allerdings mittlerweile nicht mehr verwenden, da sie inzwischen gebrochen wurden. Und dann gibt es da noch einige weitere Punkte zu beachten …

Aber fangen wir mit der Frage nach den aktuell als sicher geltenden Verfahren an. Vereinfacht könnte man sagen, dass alles, was nicht gebrochen wurde, sicher ist. Aber das wäre etwas zu einfach, denn auch wenn eine Schlüssellänge für ein Verfahren aktuell noch nicht gebrochen werden kann, könnte der Abstand zu einer bereits gebrochenen Schlüssellänge so gering sein, dass in absehbarer Zeit mit einem erfolgreichen Angriff zu rechnen ist.

Nehmen wir als Beispiel RSA . Dessen Sicherheit hängt davon ab, dass es nicht effektiv möglich ist, Zahlen in ihre Primfaktoren zu zerlegen. Das ist sehr wahrscheinlich so, es gibt aber keinen mathematischen Beweis dafür. Vielleicht hat ja auch bloß noch niemand einen effektiven Algorithmus gefunden. Um 1997 galten 768 Bit lange RSA-Schlüssel als sicher. 2009 wurde die 768 Bit lange Zahl RSA-768 der RSA Factoring Challenge faktorisiert, hier und hier einzusehen. Damit sind seitdem 768 Bit lange Schlüssel nicht mehr sicher. Inzwischen sind durch die gesteigerte Rechenleistung die ebenfalls lange Zeit üblichen 1 024 Bit langen Schlüssel nicht mehr sicher. Man muss also immer langfristig denken: Wie lange soll eine jetzt verschlüsselte Datei sicher sein? Oder eine Signatur? Oder was auch immer. Verfahren und Parameter müssen so gewählt werden, dass die Sicherheit für den gesamten geplanten Zeitraum gegeben ist.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hält aktuell mindestens 2 000 Bit lange RSA-Schlüssel für sicher, aber nur bis Ende 2022. Danach sollen mindestens 3 000 Bit lange Schlüssel verwendet werden. Wenn Sie also heute einen Text mit einem 2 048 Bit langen Schlüssel verschlüsseln, was ja durchaus ein üblicher Wert ist, könnte der in fünf oder sechs Jahren möglicherweise entschlüsselt werden. Soll der Inhalt länger geheim bleiben, müssen Sie einen längeren Schlüssel verwenden.

Welche Verfahren und welche Schlüssellängen sind sicher?

Es gibt verschiedene Institutionen und Organisationen, die die ihrer Ansicht nach sicheren Verfahren und Schlüssellängen veröffentlichen. In Deutschland sind das BSI und die Bundesnetzagentur (vollständig: „Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen“) die offiziellen Ansprechpartner.

TR-02102 des BSI

Das BSI veröffentlicht in Teil 1 der technischen Richtlinie TR-02102 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ seine Bewertung der Sicherheit ausgewählter kryptografischer Verfahren. Es werden die empfohlenen Verfahren und Schlüssellängen aufgeführt und es wird auch auf mögliche Angriffe und Schwachpunkte hingewiesen.

Die Richtlinie soll einen längerfristigen Überblick über die Sicherheit der Verfahren geben und richtet sich in erster Linie an Entwickler, die die Einführung neuer kryptografischer Infrastrukturen planen. Das BSI erhebt aber keinen Anspruch auf Vollständigkeit, nicht aufgeführte Verfahren werden vom BSI nicht zwingend als unsicher beurteilt, sondern eben gar nicht – was sich noch als Problem erweisen wird, wie wir im Folgenden sehen werden.

Die laut BSI sicheren Verfahren und Schlüssellängen

Die aktuelle Version 2017-01 vom 8. Februar 2017 der TR-02102-1 führt u. a. folgende Verfahren und Schlüssellängen als sicher auf:

  • Symmetrische Verschlüsselung
    • Als Blockchiffre wird AES mit 128, 192 oder 256 Bit langen Schlüsseln empfohlen, als Betriebsarten der Galois/Counter Mode (GCM), das Cipher Block Chaining (CBC) und der Counter Mode (CTR), für die es jeweils noch empfohlene Betriebsbedingungen gibt.
    • Für symmetrische Stromchiffren gibt es zurzeit keine Empfehlung, AES im Counter Mode kann jedoch als Stromchiffre aufgefasst werden.
  • Asymmetrische Verschlüsselung
    Empfohlen werden das auf dem Diffie-Hellman-Problem auf elliptischen Kurven basierende Elliptic Curve Integrated Encryption Scheme (ECIES) mit 250 Bit langen Schlüsseln, das auf dem normalen DH-Problem basierende Discrete Logarithm Integrated Encryption Scheme (DLIES) und RSA mit 2 000 Bit langen Schlüsseln bzw. beim Einsatz über das Jahr 2022 hinaus 3 000 Bit langen Schlüsseln. Dabei wird davon ausgegangen, dass es für die Gültigkeitsdauer der Werte weder einen Durchbruch bei der Entwicklung effektiver Algorithmen zur Lösung der zugrunde liegenden Probleme gibt noch es zum Einsatz von Quantencomputern für Angriffe kommt (dazu im Folgenden noch mehr).
  • Hashfunktionen
    • Das BSI empfiehlt die Hashfunktionen SHA-256, SHA-512/256, SHA-384 und SHA-512 der SHA-2-Familie sowie SHA3-256, SHA3-384, SHA3-512 der SHA-3-Familie .
    • Vom Einsatz von SHA-1-Funktionen wird explizit abgeraten, da „die Erzeugung von Kollisionen gegen SHA-1 heute prinzipiell praktisch möglich“ erscheint ([4], S. 41). „In Anwendungen, die eine kollisionsresistente Hashfunktion benötigen, sollte daher SHA-1 definitiv nicht mehr eingesetzt werden.“ (ebd.)
  • Message Authentication  
    Für die Bildung von MACs empfiehlt das BSI die Verfahren CMAC und GMAC mit einer der aufgeführten Blockchiffren und HMAC mit einer aufgeführten Hashfunktion, immer mit einer Schlüssellänge von mindestens 128 Bit. Die Taglänge sollte mindestens 96 Bit betragen, minimal zulässig (aber nicht empfohlen) sind 64 Bit.
  • Signaturverfahren
    Als Signaturverfahren werden vom BSI die Verfahren RSA, der Digital Signature Algorithm DSA und Merkle-Signaturen sowie die DSA-Varianten auf elliptischen Kurven ECDSA und ECKDSA bzw. ECGDSA empfohlen.

Des Weiteren gibt es Vorgaben für die Authentisierung, den Schlüsselaustausch (Diffie-Hellman sowohl normal als auch über elliptische Kurven), Schlüsselaushandlung und -übertragung, Key-Updates, Secret Sharing und Zufallszahlengeneratoren.

Weitere Protokolle

Für einige Protokolle gibt es separate Teile der technischen Richtlinie TR-02102 als eigenständige Dokumente. TR-02102-2 enthält Empfehlungen für den Einsatz von TLS. In TR-02102-3 gibt es Empfehlungen zum Einsatz von IPsec und IKEv2 (IKEv1 sollte nicht mehr verwendet werden, da IKEv2 Vorteile gegenüber v1 besitzt). Und in TR-02102-4 werden Empfehlungen fürden Einsatz von SSH (sowohl zur zu verwendenden Version als auch zu den zu verwendenden kryptografischen Algorithmen) gemacht.

Sonderfall Signaturen

In Deutschland werden an eine qualifizierte elektronische Signatur nach dem Signaturgesetz (SigG) und der Signaturverordnung (SigV, beide inzwischen vom Vertrauensdienstegesetz (VDG) abgelöst) besondere Anforderungen gestellt. Dem zufolge ist die Bundesnetzagentur für den Aufbau und die Überwachung einer sicheren und zuverlässigen Infrastruktur für qualifizierte elektronische Signaturen zuständig. Sie veröffentlicht jährlich eine Übersicht über die Algorithmen und ihre zugehörigen Parameter, die zur Erzeugung von Signaturschlüsseln, zum Hashen zu signierender Daten und zur Erzeugung und Prüfung qualifizierter elektronischer Signaturen geeignet sind. Ebenso bestimmt sie den Zeitpunkt, bis zu dem diese jeweils gültig sind.

Derzeit aktuell ist der am 7. Dezember 2016 veröffentlichte Algorithmenkatalog 2017 . Dieser weicht zum Teil von den allgemeinen Empfehlungen des BSI ab. So empfehlen beide für Signaturen RSA, DSA und DSAVarianten auf Basis elliptischer Kurven. Doch während das BSI zusätzlich Merkle-Signaturen empfiehlt, erlaubt die Bundesnetzagentur für die Erstellung einer qualifizierten elektronischen Signatur bis zum Jahr 2020 auch Nyberg-Rueppel-Signaturen, aber generell keine Merkle- Signaturen.

Laut Algorithmenkatalog nicht mehr zulässige Algorithmen

Im Gegensatz zur technischen Richtlinie des BSI enthält der Algorithmenkatalog auch eine Aufführung der früher einmal zulässigen, inzwischen aber unsicheren und daher für die Erzeugung einer qualifizierten elektronischen Signatur nicht mehr geeigneten kryptografischen Algorithmen. So ist z. B. der Einsatz von SHA-1, RIPEMD-160 und SHA-224 nicht mehr zulässig, und auch RSA-Schlüssel bis zu einer Länge von 1 728 Bit dürfen nicht mehr verwendet werden.

Abgesehen von Sicherheitsgründen, werden Algorithmen auch aus dem Katalog gestrichen, wenn sie wenig genutzt werden. Im aktuellen Katalog hat die zeitliche Beschränkung der Nyberg-Rueppel-Signaturen bis zum Jahr 2020 keinen Sicherheitsgrund, sondern ihre Nutzung soll lediglich auslaufen.

Unsere Algorithmen

Die im Algorithmenkatalog der Bundesnetzagentur verbotenen Algorithmen sollten auch für die Berechnung normaler Signaturen nicht mehr verwendet werden. Aber wie sieht es mit anderen Verfahren aus? Was ist z. B. mit der symmetrischen RC4-Verschlüsselung? Die Bundesnetzagentur ist nur für Signaturen zuständig, sie kümmert sich nicht um Verschlüsselung, also auch nicht um RC4. Und das BSI? RC4 kommt in TR-02102-1 nicht vor. Da das BSI, wie schon erwähnt, keinen Anspruch auf Vollständigkeit erhebt, hat das aber keine negativen Auswirkungen – das BSI hat sich RC4 ja vielleicht nur nicht angesehen. Also könnte man es ruhig verwenden, immerhin steht das R im Namen ja für Ronald Rivest, einem der RSA-Entwickler. Und RC4 ist schließlich ein altbekanntes Verfahren.

International PHP Conference 2018

Getting Started with PHPUnit

by Sebastian Bergmann (thePHP.cc)

Squash bugs with static analysis

by Dave Liddament (Lamp Bristol)

API Summit 2018

From Bad to Good – OpenID Connect/OAuth

mit Daniel Wagner (VERBUND) und Anton Kalcik (business.software.engineering)

RC4 ist tot

Es ist aber auch ein inzwischen unsicheres Verfahren und sollte deshalb nicht mehr verwendet werden. Im Februar 2015 hat die IETF die Verwendung von RC4 im Rahmen von TLS verboten (RFC 7465 ). Die Browserhersteller haben die Unterstützung von RC4 inzwischen eingestellt – und das aus gutem Grund. Im März 2013 wurde von Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering und Jacob Schuldt gezeigt, dass sich Teile des RC4-Schlüsseltexts sowohl einer TLS-Verbindung als auch einer WPA-Verbindung entschlüsseln lassen. Schon zuvor waren Schwachstellen in der RC4-Verschlüsselung bekannt geworden, aber mit diesem Angriff wurde die Sache gefährlich.

Konkret können mit dem Angriff die ersten 256 Bytes des Klartextstreams ermittelt werden. Da die ersten 36 Bytes aus einem nicht vorhersagbaren Hashwert bestehen (damals meist vom Hashalgorithmus SHA-1, der inzwischen selbst als unsicher gilt ), können sie nicht ermittelt werden. Effektiv können also 220 Bytes eines verschlüsselten Texts entschlüsselt werden. Dafür werden ca. 230 Sessions benötigt, mit ca. 224 Sessions können bereits bestimmte Bytes zuverlässig entschlüsselt werden. Im November 2013 hat Microsoft daher empfohlen, möglichst bald auf den Einsatz von RC4 für SSL/TLS (und auch alle anderen Einsatzzwecke) zu verzichten. Parallel wurde im Rahmen der Snowden-Enthüllungen bekannt, dass die NSA SSL-/TLS-Verbindungen mit RC4 mit ziemlicher Sicherheit in Echtzeit entschlüsseln kann . Und was die NSA kann, können vermutlich auch andere Geheimdienste.

Im Juli 2015 wurde dann von Mathy Vanhoef und Frank Piessens ein praktischer Angriff auf RC4 in SSL/TLS und WPA-TKIP vorgestellt: RC4 NOMORE (Numerous Occurrence MOnitoring & Recovery Exploit ). Sie konnten den Cookie einer HTTPS-Verbindung eines realen Geräts in 52 Stunden ermitteln. Für den Angriff auf WPA-TKIP reicht sogar eine Stunde, danach kennt der Angreifer den MIC-Schlüssel und kann beliebige an den Client gesendete Pakete entschlüsseln und einschleusen.

Also: Finger weg von RC4, dessen Verschlüsselung ist nicht mehr sicher.

SHA1 ist auch tot

Kommen wir zu einem anderen, lange Zeit beliebten, inzwischen aber unsicheren Verfahren: der Hashfunktion SHA-1.

2005 wurde von Xiaoyun Wang, Andrew Yao und Frances Yao ein erster Angriff auf SHA-1 veröffentlicht, der den Rechenaufwand für die Berechnung einer Kollision von ursprünglich 280 für einen Brute-Force-Angriff auf 263 Berechnungen reduzierte. Im August 2006 wurde von Christophe De Cannière und Christian Rechberger ein Angriff veröffentlicht, bei dem ein Teil der gefälschten Nachricht frei gewählt werden kann [18].

Danach gab es noch einige weitere Verbesserungen, die sich zum Teil aber als Irrtum bzw. Fehlinterpretation herausstellten und zurückgezogen wurden.

2015: The SHAppening versetzt den Todesstoß

Im Oktober 2015 veröffentlichten Marc Stevens, Pierre Karpman und Thomas Peyrin eine Freestart-Kollision für die Kompressionsfunktion von SHA-1: The SHAppening. Sie kamen zu dem Schluss, dass es aufgrund der kontinuierlichen Erhöhung der Rechenleistung sehr viel früher als bisher geschätzt möglich sein wird, die zur Fälschung von TLS-Zertifikaten nötigen Chosen-Prefix-Kollisionen zu finden. SHA-1 sollte daher nicht mehr verwendet werden. Die Browserhersteller haben daraufhin angekündigt, die Unterstützung von SHA-1 für TLS ab Anfang 2016 einzuschränken und ab 2017 komplett einzustellen.

Googles Chrome warnt seit dem im Januar 2017 veröffentlichten Chrome 56 vor SHA-1-Zertifikaten , Firefox seit dem im Februar 2017 veröffentlichten Firefox 52 . Bei Microsoft ist seit Mai 2017 Schluss . Seitdem wird in Edge und Internet Explorer 11 bei Websites, die ein TSL-Zertifikat mit SHA-1 verwenden, das auf einem Root-Zertifikat in Microsofts Trusted Root Program basiert, eine Warnung vor einem ungültigen Zertifikat eingeblendet. Für Zertifikate von Unternehmens-CAs und selbstsignierte Zertifikate gibt es keine Warnung, aber auch diese sollten durch Zertifikate mit SHA-2 Hashes ersetzt werden.

Apple warnt seit den im April 2017 veröffentlichten macOS Sierra 10.12.4, iOS 10.3, tvOS 10.2 und watchOS 3.2 vor Websites mit SHA-1-Zertifikaten, die von einer CA aus dem Default Trust Store ausgestellt wurden. Und mit der Veröffentlichung von macOS High Sierra 10.13, iOS 11, tvOS 11 und watchOS 4 im September 2017 endete auch die Unterstützung von SHA-1 für alle weiteren TLS-Verbindungen wie z. B. Mail, VPN, Kalender etc. . Nicht betroffen sind mit SHA-1 signierte Root-Zertifikate von öffentlichen und unternehmensinternen CAs sowie selbst signierte Zertifikate.

2017: SHAttered schließt den Sargdeckel

Forscher der Cryptology Group des Centrum Wiskunde& Informatica (CWI) in Amsterdam und der Google Security, Privacy & Abuse Research Group haben im Februar 2017 eine echte Kollision für SHA-1 berechnet. Elie Bursztein hat die Forschungsergebnisse und ihre Folgen auf der Black Hat USA 2017  und DEF CON 25 vorgestellt.

Die Forscher haben zwei PDF-Dateien mit nahezu identischen Inhalten, aber unterschiedlichen Hintergrundfarben (einmal blau, einmal rot) erzeugt, die den gleichen SHA-1-Wert ergeben. Was eigentlich nahezu unmöglich sein sollte, denn dafür müssten eigentlich 280 Berechnungen nötig sein. Und selbst die oben erwähnte Verbesserung auf 269 Berechnungen machte den Angriff lange Zeit noch nicht praktikabler. Die gestiegene Rechenleistung und weitere Verbesserungen am Angriff führten nun zum Durchbruch, auch wenn er immer noch extrem aufwendig ist. Der neue Angriff erforderte:

  • 9 223 372 036 854 775 808 SHA-1-Berechnungen
  • 6 500 Jahre CPU-Berechnungen für die erste Phase
  • 110 Jahre GPU-Berechnungen für die zweite Phase

Aber das ist immer noch 100 000 Mal schneller als ein Brute-Force-Angriff unter Ausnutzung des Geburtstagsparadoxons , der 12 000 000 GPU-Jahre benötigen würde.

Die praktische Auswirkung dieses Angriffs ist fatal: Es können Dateien mit unterschiedlichen Inhalten, aber identischen SHA-1 Hashes erzeugt werden. Wenn jemand die eine Datei signiert, ist diese Signatur auch für die andere Datei gültig. Das will man natürlich auf gar keinen Fall. Im Beispiel unterscheiden sich nur die Hintergrundfarben, aber genauso gut könnte auch z. B. in einem Kaufvertrag der Kaufpreis unterschiedlich sein, in einem Zertifikat der Inhaber usw. Und damit ist SHA-1 nun endgültig unsicher.

Passwortspeicherung: Normale Hashfunktionen sind ungeeignet

Ich habe schon im PHP Magazin 6.2013 erklärt, warum Sie Passwörter nicht als normale Hashwerte speichern, sondern speziell dafür entwickelte Passworthashfunktionen verwenden sollten [1]. Für PHP ist das mit PHP 5.5 eingeführte Passwort-Hashing-API die beste Lösung.

Aktuell gibt es mal wieder einen Grund, an diese speziellen Funktionen zu erinnern. Anfang August wurden auf der Website „Have I been pwned?“ die SHA-1-Hashwerte von mehr als 319 Millionen Passwörtern aus verschiedenen Datenlecks mit Klartextpasswörtern veröffentlicht. Mehrere Forscher um das Kollektiv CynoSure Prime haben alle Hashes bis auf 116 geknackt, was einer Erfolgsquote von ca. 99,9999 % ergibt. Eine normale Hashfunktion wie SHA-1 ist also absolut ungeeignet, um Passwörter zu schützen. Die speziellen Passworthashfunktionen wurden entwickelt, um solche Angriffe zu verhindern.

Ein Ausblick in die Zukunft: Quantencomputer und Kryptografie

Oben habe ich geschrieben, dass die Aussagen des BSI nur gelten, wenn keine Quantencomputer für den Angriff zum Einsatz kommen. Diese Einschränkung ist nötig, da sich mit Quantencomputern manche noch unberechenbaren Probleme lösen lassen. So gilt beispielsweise beim Einsatz von Quantencomputern die Faktorisierungsannahme nicht mehr. Der Shor-Algorithmus nutzt Mittel der Quanteninformatik und berechnet auf einem Quantencomputer einen nicht trivialen Teiler einer zusammengesetzten Zahl, und das mit polynomieller Laufzeit. Der Algorithmus wurde 1994 von Peter Shor veröffentlicht, hat eine Laufzeit von O(log(n)3) und würde z. B. Angriffe auf RSA möglich machen.

Ein parallel von Peter Shor veröffentlichter Algorithmus zur Berechnung des diskreten Logarithmus würde Angriffe auf Verfahren wie den Diffie-Hellman-Schlüsselaustausch ermöglichen, deren Sicherheit darauf beruht, dass es eben nicht möglich ist, diskrete Logarithmen effektiv zu berechnen. Insbesondere alle asymmetrischen Verfahren sind durch Quantencomputer gefährdet, da sie aus dem öffentlichen Schlüssel den privaten Schlüssel berechnen können. Sobald es praktisch einsetzbare Quantencomputer gibt, werden diese Verfahren schlagartig unsicher sein.

Deutlich besser sieht es in der Hinsicht für symmetrische Verfahren aus: Da deren einziger Schlüssel geheim gehalten werden muss, gibt es keinen Ansatzpunkt für die Quantencomputer. Der beste Ansatz für einen quantencomputerbasierten Angriff auf symmetrische Verfahren ist der 1996 von Lov K. Grover veröffentlichte Grover-Algorithmus, der eigentlich die Suche in Datenbanken beschleunigt. Er erlaubt aber auch verbesserte Brute-Force-Angriffe auf symmetrische Verschlüsselungen, wenn einige Klartext-Schlüsseltext- Paare vorliegen. Dem lässt sich aber durch längere Schlüssel entgegenwirken, zurzeit geht man von einer nötigen Verdoppelung der Schlüssellänge aus. Wenn entsprechend leistungsstarke Quantencomputer möglich erscheinen, sollte man also z. B. im Fall von AES von der minimalen Schlüssellänge von 128 Bit besser zu 256 Bit Schlüssellänge wechseln.

Für die asymmetrischen Verfahren werden aber andere Lösungen benötigt, die vor Angriffen mit Quantencomputern sicher sind. Der englische Begriff „Post-Quantum Cryptography“ für diese vor Angriffen mit Quantencomputern sicheren Verfahren wurde von Daniel J. Bernstein geprägt. Für die Post-Quanten-Kryptografie gibt es verschiedene Ansätze, und für alle gibt es auch bereits Algorithmen. Im Ernstfall muss man also diese nur an Stelle von z. B. RSA und DH-Schlüsselaustausch verwenden.

Auf der Black Hat Europe 2016 hat Jennifer Fernick das Softwareprojekt „Open Quantum Safe“ vorgestellt. Das umfasst zurzeit eine C Library mit quantencomputerresistenten Algorithmen (liboqs) und einen Fork von OpenSSL  mit quantencomputerresistenten Algorithmen und Cipher Suites, die auf liboqs basieren. Die Software läuft unter Windows, Mac OS X und Linux.

Fazit

Kryptoverfahren sind nicht für die Ewigkeit gemacht. Irgendwann findet immer jemand einen Weg, sie auszuhebeln. Oder die Rechenleistung aktueller Computer ist groß genug, um ursprünglich unberechenbar erscheinende Probleme doch zu lösen. Eine Verschlüsselung ist daher nur ein Zeitschloss, irgendwann kann sie gebrochen werden. Und das Gleiche gilt sinngemäß auch für alle anderen Anwendungen von Kryptografie, weshalb z. B. die Vorgaben der Bundesnetzagentur für die qualifizierte digitale Signatur jährlich an die aktuelle Entwicklung angepasst werden. Ehemals sichere Algorithmen und Schlüssellängen werden gestrichen, neue kommen dazu. Daher ist es wichtig, die von eigenen Projekten genutzten Kryptoverfahren und Parameter regelmäßig, z. B. jährlich, auf ihre Sicherheit zu prüfen und ggf. auch außerpanmäßig auf aktuelle Entwicklungen wie z. B. SHAttered zu reagieren. Wann haben Sie das letzte Mal die Sicherheit der von Ihnen verwendeten Kryptoverfahren und ihrer Parameter geprüft?

Literatur
[1] Eilers, Carsten: „Passwörter speichern, aber richtig!“; PHP Magazin 6.2013

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -