Thunderbird, wie viele andere e-Mail Clients meint direkt, dass diese Nachricht ein Betrugsversuch (Phishing) sein könnte. Huch, will amiando mir da böses?

Natürlich nicht. Aber das wird einige Kunden beunruhigen. Und diese Meldung ist leicht vermeidbar.

Thunderbird meint eine Nachricht könnte Phishing sein, wenn man einen Link einbaut, der aber woanders hinzeigt. Sprich der Kunde denkt er landet bei seiner Bank, ist aber auf dem Weg zu einem Freehost irgendwo anders.

Ein Beispiel für böses Phishing-HTML

Gäben Sie hier Poypal-Zugangsdaten ein:
<a href="http://russiafreehost.com">http://www.paypal.de</a>


Ein Beispiel für legitimes HTML, was missverstanden wird

Bei Fragen rund um amiando besuchen Sie uns bitte im Internet unter
<a href="http://news.amiando.com/HS?a=ABCDEF123456">http://www.amiando.de</a>

Kleiner Tipp vom Onkel Jan: man sollte Tracking Code nicht mit URLs kombinieren. Entweder sollte man die URLs durch Namen o.ä. ersetzen, sprich den Satz ändern und auf “Hitmeister” und nicht auf “http://www.hitmeister.de” verlinken. Oder bei diesen Links auf Tracking Codes verzichten. Denn als Phisher beschimpft zu werden ist nicht so doll. Und neue Mail-Templates immer in verschiedenen Clients testen…

Schritt 1: Self-Assessment Questionnaire

In einem ersten Schritt muss man ein sogenanntes Self-Assessment Questionnaire (SAQ) ausfüllen, in dem man die eigene Sicherheit in der IT bewertet. Dieses SAQ kann man als Word-Dokument herunterladen, normalerweise hat der Acquirer aber auch ein Online-Interface dafür.

Die Punkte, die man in diesem SAQ abnicken muss, sind in der Art:

• Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.
• Is the PAN masked when displayed? The first six and last four digits are the maximum number of digits to be displayed.)

Wer eine Datenschutzrichtlinie und einen aktiven Datenschutzbeauftragten hat, und sich etwas Mühe mit seinem System gegeben hat, sollte da keine großen Probleme haben. Dieses SAQ muss man unterschreiben, es wird aber nicht geprüft.

Je nachdem, was für ein Merchant man ist, gibt es auch unterschiedliche Levels an Kriterien.

Schritt 2: PCI Security Scan

In einem zweiten Schritt muss ein Approved Scanning Vendor (ASV) die eigenen Systeme mit einem automatischen Test auf Schwachstellen und Löcher überprüfen. Wir haben das mit der Firma usd.de AG gemacht (von Wirecard empfohlen) aber der Scan ist standardisiert. Man kann also einen günstigen Anbieter suchen, wenn man das nicht als Anlass nehmen möchte ein komplettes Audit mit einem guten Dienstleister zu machen.

Dem ASV übergibt man eine Liste mit allen IP-Adressen, die man verwendet, um seinen Dienst zur Verfügung zu stellen. Also WWW, FTP, Mail usw. Man sollte zudem einen Termin für den Scan vereinbaren und mit dem eigenen ISP absprechen, damit keine Intrusion-Detection-Systeme während dem Scan Amok laufen.

Während dem Scan prüft der ASV die Systeme. Der Scan dauert etwa eine Stunde. Mein Tipp ist, das ist ein etwas umgebautes Nessus. Aber an die Regeln kommt man aber nicht ran. Der Scan teilt sicht in fünf Bereiche auf:

• Information gathering (hier werden keine Lücken gefunden, sondern nur die Systeme analysiert)
• Web server
• TCP/IP
• General remote services
• Firewall

Die Vulnerabilities werden aufgeteilt in Confirmed, Potential und Information Gathered zusammen mit einer Severity (1-5). Dabei wird noch mal unterschieden, ob eine gefundene Vulnerability auch die PCI Zertifizierung verhindert, oder nur aufgezeigt wird.

Wir hatten im Scan vier Vulnerabilities:

• Unsere PHP Version war dem ASV zu alt.
• Unser SSL hat auch Schlüssel unter 128 bit akzeptiert.
• Man hat an dem Server erkennen können, dass wir PHP nutzen (gut, das steht auch in den URLs, aber egal).
• Unser Apache hatte eine XSS-Exploit Möglichkeit auf unserer HTTP 413-Fehlerseite (Mehr Infos zu diesem Exploit)

Nachdem wir die obengenannten Vulnerabilities behoben haben wurde der Scan neu angestoßen und unsere Website abgesegnet. In Kombination mit dem SAQ reicht ein erfolgreicher Scan für die Zertifizierung. Der Scan muss aber vierteljährlich wiederholt werden.

Fazit

Insgesamt ist so eine PCI Zertifizierung eine ganz lustige Möglichkeit mal zu gucken, wie sicher ein Außenstehender die eigene Website findet. Man muss das ganze aber etwas relativieren.

• Der SAQ zeigt ganz gute Stellen auf, wo in der Organisation Probleme lauern könnten. Teilweise sind die Fragen aber ziemlich “Enterprise”-ig.
• Der Scan ist ganz lustig. Man bekommt Feedback zu den genutzten Systemen und eventuell wird die eine oder andere Sicherheitslücke aufgezeigt. Das ganze ersetzt aber auf keinen Fall ein richtiges Security-Audit von Profis.

Zusätzlich ist die ganze Geschichte ist ganz schön teuer, wird einem aber von den credit card processors aufgedrückt.

Hier ein Vergleich der Apple-Gebühren pro Land, inklusive Mittelwert:

In den USA zahlt man 29,29% Gebühren, in der EU 39,24%. Einen gewissen Aufschlag für die Wechelskursumrechnung usw. würde ich ja verstehen (auf dem Niveau US vs. JP). Aber der Sprung von 29,29% zu 39,24% ist schon knackig. Mich würde mal interessieren, woher dieser Sprung kommt. Oder ist es einfach “weil wir es können” ?

Für unsere Abrechnung sind In App Purchases leider deutlich zu teuer. Ich würde es sehr cool finden, wenn man direkt vom iPhone aus die Hitmeister Produkte bestellen könnte, mit Abrechnung über das iPhone. Aber bei 12,5% Provisionen bei uns vs. 39,24% die wir an Apple abdrücken müssten, wäre das ein ziemliches Verlustgeschäft. Bei unseren anderen Zahlungsmethoden (Lastschrift, Kreditkarte usw.) zahlen wir deutlich weniger. Schade! Ich denke Apple bräuchte alternatives Gebührenmodeel für physische Güter.

Wer HTML-Code für e-Mails schreiben muss wird in eine ganz eigene, schreckliche Welt versetzt. CSS? Naja so halb. DIVs? Lieber nicht. Man fährt mit ganz ganz old-school HTML am besten.

Alle HTML Templates müssen in einer Reihe von Systemen getestet. Entweder mühsam per Hand, oder mit Tools wie Litmus. Und dann geht es wieder los, das Template sieht in Hotmail gut aus, in Outlook geht so, in Gmail aber mies, dann ändern wir was und es ist jetzt umgekehrt.

Das bittere: die Zukunft wird nicht besser. Microsoft hat bis Outlook 2003 den Internet Explorer fürs HTML verwendet. Ab Outlook 2007 wird es die Word-HTML-Engine. E-Mail Designs werden mindestens fünf Jahre zurück geworfen.

Ein kleiner Vergleich zwischen Outlook 2000 und 2010 vom email standards project

Bei uns intern waren wir etwas ratlos, welche e-Mail Anwendungen unsere Kunden denn tatsächlich nutzen. Bewegen wir uns in der schönen, heilen Thunderbird Welt, oder müssen wir Notes, Outlook 2007 und Konsorten mit unterstützen? Die Antwort: ja, wir bewegen uns in der schrecklichen Welt. Und wir müssen fieses, kompatibles, “kleinster-gemeinsamer-Nenner” HTML schreiben für Outlook.

Die Antwort in lang (Datenbasis ca. 30k Empfänger):

• Outlook: 45% (davon 36% Outlook 2000-2003 und 8% Outlook 2007). Das schreckliche daran: irgendwann haben die meisten Outlook 2000-2003 Kunden vermutlich auch Outlook 2007. Es geht bergab.
• Thunderbird: 7% (davon 4% Thunderbird 2, 2% Thunderbird 3). Was ich hier interessant finde: Thunderbird schiebt nicht so aggressiv die Updates raus wie Firefox. Oder die Leuten mögen die nicht. Keine Ahnung.
• Windows Live Hotmail: 6% (zu gleichen Teilen IE und FF)
• GMX: 6% (mehr FF als IE)
• Yahoo! Mail: 4%
• Apple Mail: 3%
• Windows Live Mail: 3%
• Apple iPhone: 2%
• Gmail: < 1%
• Freenet, AOL, Opera, Lotus Notes, Entourage, Excite, Swisscom, Mail.com, Orange: auch alle jeweils unter 1%
• Sonstige: 17%

Wir haben - basierend auf den Ergebnissen - jetzt PCs mit den verschiedenen Outlook-Versionen ausgestattet. An sich nutzt die ganze Firma Thunderbird, aber das ändert sich jetzt teilweise.

Mich überrascht zudem, wie schwach Gmail abgeschnitten hat. Hätte ich nicht gedacht.

Mir ist gerade ein strittiger Punkt in einem SLA untergekommen, den ich in Zukunft bei der Vertragsgestaltung berücksichtigen werde: wer misst eigentlich die Einhaltung des Service Levels?

In einem SLA von uns steht klar definiert, dass ein Dienstleister eine Verfügbarkeit der Dienste (definiert als Antwort innerhalb von 500 ms) im Monatsdurchschnitt von 99,5% zu garantieren hat. Wenn nicht, wird eine (Geld-)Strafe fällig. Soweit gut und bekannt.

Leider ist nicht klar definiert, wer genau diese Verfügbarkeit misst. Wir messen selbst (nagios) und mit ServerGuard24. Der Dienstleister misst (soweit ich weiss) selber.

Nun liegen die Zahlen der drei Messpunkte leicht auseinander. Diese Abweichung könnte aber zu einer recht empfindlichen Strafe führen. Und es geht um die Frage: wessen Messung gilt?

Zusammenfassend habe ich heute gelernt: lieber € 10 im Monat in einen unabhängigen Dienstleister investieren, der die SLA misst. Und diesen Dienstleister dann im SLA verankern. Spart Diskussionen.

P.S. Eigentlich sind Service Levels von 99,5% m.E. heutzutage bei kritischen Anwendungen nicht mehr zeitgemäß. Das sind mehr als drei Stunden Downtime pro Monat. Da muss ich mal nachbessern.

Die Ergebnisse der Aufrufe waren so beeindruckend (und erschreckend), dass Jupp direkt eine Woche Zeit bekommen hat, um unseren Code zu durchforsten. Das Ergebnis

• Die Execution Time wurde teilweise um bis zu 75% reduziert.
• Unser Code wirkt jetzt teilweise etwas komisch.

Normalerweise würde man ja sagen: wenn solche Ersparnisse drin sind, wurde vorher etwas falsch gemacht. Zumindest würde ich das immer behaupten. Unsere Ladezeiten waren aber immer ok (zwischen 600-800 ms) und deswegen war Performance lange keine Baustelle. Der Cache federt bei uns Unfug ab, und ordentliche Hardware macht den Rest.

Wo kam der Performance-Gewinn her? Zwei Stellen waren:

Magic Functions und Member Variablen. Wir machen ausgiebigen Gebrauch von magic functions. Vor allem, um partitionierte Daten nachzuladen. Oft ist es aber wesentlich günstiger mit den Daten, die man eh hat, die member Variablen zu füllen anstatt auf den __get() zu warten. Auch wenn __get() im Normalfall sehr billig ist (je nachdem, was man da alles reinsteckt).

Validate Methoden. Jeder Service in unserer Architektur validiert alle Parameter, mit denen er aufgerufen wird. So kommt kein Quatsch bis zur DB vor. Dabei gibt es einfache Validierungen (int, string) aber auch kompliziertere, bis hin zu DB-Lookups usw. Wir finden Sicherheit wichtig, und dazu gehören saubere Input-Daten. Diese validate-Funktionen werden hunderte Male pro Seite aufgerufen. Zum einen haben wir da die “Klassen-lastigkeit” reduziert. Wir haben Zend_Validate eingesetzt, da liegen zwischen dem Aufruf und dem Ergebnis verschiedene Klassen, diese implements dies, die andere macht die factory für das usw. Zusätzlich machen an so zentralen Stellen Code-Änderungen im PHP-Bereich Sinn. Normalerweise wird da ja viel kaputt optimiert, aber bei den zentralen Stellen bekommt man was raus. Ein unintuitives Lieblingsbeispiel von mir:

if (isset($aValues[$sNeedle]))
{
   return true;
}
elseif (in_array($sNeedle, $aValues))
{
   return true;
}
else
{
   return false;
}

Normalerweise könnte man sagen, das obere mit dem isset() kann man sich sparen. Richtig. Nur: isset ist viel schneller als in_array (Benachmarks, mehr). In diesem Fall hat der isset ca. 95% der Fälle erledigt, NULL kommt selten vor. Sprich der aufwendigere Code ist sogar schneller. Pro Ausführung spart man jetzt nicht wahnsinnig viel, aber in einer sehr zentral genutzten Funktion macht es schon einen Unterschied.

Ich kann XHProf wärmstens empfehlen. Man entdeckt tolle Sachen (wer zum Teufel hat die Regex da eingebaut?) und spart Ausführungszeit. Uns hat die Optimierung sicherlich ein Hardware-Upgrade eingespart.

Ein kleiner Hinweis noch: wenn man XHProf lokal auf dem Testsystem ausführen muss man unbedingt gucken, dass die Bedingungen, insbesondere was Caches angeht, den realen entsprechen. Sonst wird an der falschen Stelle optimiert. Passiert den besten Bloggern…

Vorgestern hat er ein kostenloses eBook veröffentlicht, zusammen mit einigen nahmhaften Co-Autoren (Gary Vaynerchuk, Guy Kawasaki, Tim O’Reilly, Tony Hsieh, Tom Peters usw.) . Das eigentlich simple Thema: Here’s what we’re working on and thinking about.

Ich würde jedem empfehlen, mal durch das eBook durchzuflippen. Mich haben einige Beiträge sowohl persönlich wie auch in beruflicher Hinsicht interessiert und berührt. Die große Schriftgröße und die dadurch bedingten kurzen Texte finde ich als Format super. Einmal kurz Inspiration am Abend.

Das eBook gibt es als kostenlosen Download, bei Scribd oder in seinem Blog.

Beim nächsten Mal geht es wieder weiter mit technischen Themen. Ich denke ich sollte mal etwas über Suche schreiben, da bekomme ich einige Anfragen zu und es ist ein Problem, was schwierig ist gut zu lösen. Wenn es andere Themen gibt, gerne melden! Entweder in den Kommentaren oder an jan@hitmeister.de

Bei Hitmeister organisieren wir im nächsten Jahr zwei Events: einmal den Internet Marketing Köln (IMK) und einmal den Hitmeister e-Commerce Day.

• Der IMK richtet sich an alle, die im Online-Marketing (samt der Unterdisziplinen) tätig sind und sich mit anderen austauschen möchten. Es gibt keine Vorträge, sondern Kölsch, Fingerfood und nette Gespräche. Früher war das mal der Online-Marketing Stammtisch, von einem Stammtisch kann man aber bei > 400 Teilnehmern nicht sprechen. Die Teilnahme ist kostenlos, Sponsoren bezahlen die Getränke. Der Termin steht jetzt fest: 17. Juni 2010 ab 19h im RheinEnergie Stadion. Wichtig: Ab dem 15.03.2010 kann man sich anmelden. Und da die Veranstaltung letztes mal innerhalb von 24 Stunden ausgebucht war, sollte man sich den 15.03.2010 im Kalendar notieren.
• Der Hitmeister e-Commerce Day richtet sich an Online-Händler, Shopbetreiber sowie e-Commerce Dienstleister. Es wird relevante Fachvorträge geben sowie einen Ausstellerbereich, mit Unternehmen und Dienstleistern der Branche. Sowohl das Vortragsprogramm wie auch die Liste der Aussteller wird fortlaufend ergänzt. Auch hier ist die Teilnahme kostenlos. Der Hitmeister e-Commerce Day findet am 13. März 2010 statt, eine kostenlose Anmeldung ist ab sofort möglich. Wir hoffen hier ein Forum für den Online-Handel schaffen zu können, wo die Branche zusammen kommt und über aktuelle Themen und Entwicklungen diskutiert.

Es würde mich freuen, Leser von meinem Blog auf den Veranstaltungen persönlich zu treffen!

Der Sprecher meinte auch, Quelle.de hätte in den ersten 10 Stunden der Rabattaktion 31.000 Bestellungen verarbeitet. Ich habe nochmal dazu im Vergleich die Amazon-Zahlen für den “Peak Order Day” 2008 rausgesucht:

Peak items ordered on a single day

2008: 6.3M
2007: 5.4M
2006: 4.0M
2005: 3.6M
2004: 3.6M
(Quelle: TechCrunch)

Quelle hat also bei 31.000 Bestellungen pro Tag ihren Peak Order Day, Amazon bei 6.3 Millionen. Leider gibt Amazon keine Zahlen für Deutschland raus. International ist bei Amazon laut dem Segmentbericht ca. 50% (=3,15 Mio. Order). Deutschland ist davon der stärkste Markt, also hat Amazon.de am besten Tag 2008 so grob 1-1,5 Mio. Bestellungen gemacht? Das zeigt sehr deutlich, wie weit Amazon Quelle voraus ist, beziehungsweise war.

So, und jetzt weiterarbeiten!

P.S. Dies soll keine Kritik an der Quelle-Technik sein! Ein System ist immer nur für eine erwartete Obergrenze ausgelegt, die war bei Quelle einfach niedriger angesetzt. Man kann ja nicht für den maximal denkbaren Traffic-Ansturm Kapazität bereithalten. Interessant ist die erwartete Last aber schon.

Update vom 03.11.2009:
Intershop führt die Ausfälle auf eine stellenweisen Überlastung der Netze nach Fürth zurück. Die eigene Software sei zu keiner Zeit an ihre Grenzen gestossen. Am zweiten Tag wurden wohl 86.000 Bestellungen abgewickelt. Laut einem Traceroute hostet www.quelle.de bei Lambdanet. Mich würde interessieren, was die dazu sagen.

Den Mauszeiger auf pointer zu setzen sollte selbstverständlich sein. Trotzdem ist es ein über Jahre am PC gelerntes Verhalten, dass Knöpfe leicht dunkler werden, wenn der Mauszeiger über ihnen “schwebt”. Und vom gelernten Verhalten der Nutzer abweichen ist generell nicht gut. Warum im Web abweichen?

Ich habe mal im Internet geguckt, wer hovers definiert hat (beim “in den Warenkorb” Knopf auf der Artikelseite):
Amazon: nein
Otto: nein
Neckermann: nein
Hitmeister: ab dem nächsten Update

Wir überholen bald alle! Ernsthaft, dieser Effekt kostet einen Designer vielleicht 20 Minuten und hilft dem Nutzer weiter. Zwar leicht und unterschwellig, aber der Gesamteindruck zählt. Also ab ans Photoshop!

Hier ist eine Anleitung, wie man hovers hübsch in CSS löst, ohne flackern. Und wenn man schon dabei ist: am besten in den Formularen nochmal kontrollieren, dass der Beschreibungstext der Checkboxen auch klickbar ist.