Existiert diese IBAN wirklich, und gehört sie zu diesem Kontoinhaber?

Wir stellen einen Mechanismus für die Beantwortung dieser Frage bereit.

Damit können Sie:

• Mit einem besseren Gefühl eine Lastschrift oder Überweisung initiieren.
• Ihren Kunden auf dieselbe Weise mehr Sicherheit geben.
• Wenn Sie eine lange Liste mit IBANs und deren Kontoinhabern haben: diese Liste monetarisieren bzw. Geld sparen, indem Sie durch die Bereitstellung von Hashes - nicht notwendigerweise der IBANs selbst - das Guthaben auf Ihrem IBAN-BIC.com-Benutzerkonto erhöhen.

Das stellt gegenüber der Standardsituation einen erheblichen Fortschritt dar. Ohne diesen Mechanismus gibt es bei einer SEPA-Überweisung (oder analog bei einer Lastschrift) folgende drei mögliche Szenarien:

• Sie überweisen Geld an eine real existierende IBAN, die dem Kontoinhaber gehört, dem Sie tatsächlich Geld schicken wollen: Wunderbar. Nach ein bis zwei Tagen können Sie mit Erleichterung feststellen, dass alles funktioniert hat.
• Sie überweisen Geld an eine IBAN, die nicht wirklich existiert, obwohl sie alle möglichen Tests besteht (Prüfsumme, Existenz der enthaltenen Bankleitzahl usw.): das Geld kommt zurück, eventuell geschmälert um eine Gebühr. Das ist nicht besonders schön, aber auch keine Katastrophe.
• Sie überweisen Geld an eine real existierende IBAN, die aber dummerweise nicht demjenigen gehört, dem Sie Geld schicken wollen. Das Geld kommt nicht automatisch zurück, und Sie sind auf die Nettigkeit dessen angewiesen, den Sie unverhofft bereichert haben.

Unser Mechanismus eliminiert die unerfreulichen Szenarien 2 und 3 für diejenigen Konten, für die wir einen Hash in unserer Datenbank haben.

Informationen über die Existenz von IBANs teilen, ohne die IBANs zu verraten

Unser Webservice erlaubt es, andere Benutzer wissen zu lassen, ob eine gegebene IBAN zu einem gegebenen Kontoinhaber gehört, ohne dass die IBANs selbst in unserer Datenbank gespeichert (oder uns auch nur mitgeteilt) werden. Was auf den ersten Blick vielleicht kaum möglich klingt, wird durch kryptographische Hashfunktionen möglich gemacht. Wir speichern keine IBANs und auch keine Namen von Kontoinhabern, sondern nur Hashes von IBANs, die mit von den Namen der Kontoinhaber abgeleiteten Daten gesalzen werden. Anhand dieser Hashes können wir Fragen beantworten wie "gehört IBAN X zu Kontoinhaber Y", ohne X oder Y zu kennen oder berechnen zu können.

Auf diese Weise können unsere Benutzer (für die IBANs, für die wir Hashes haben) herausfinden, dass eine bestimmte IBAN wirklich zu einem bestimmten Kontoinhaber gehört. Diese Information wird zusammen mit den anderen Rückgabewerten der Funktion validate_iban geliefert.

Ihr IBAN-BIC-Benutzerkonto durch das Hochladen von Hashes aufladen

Sie können auf zwei Arten Ihren Kontostand erhöhen, indem Sie mit uns die Information teilen, dass eine IBAN zu einem bestimmten Kontoinhaber gehört. Unabhängig davon, welchen dieser beiden Wege Sie wählen, speichern wir nur gesalzene Hashes (wobei das Salz im allgemeinen für jede IBAN anders ist); wir speichern keine IBANs oder Kontoinhaber-Namen dauerhaft.

Sie werden für das Bereitstellen von Hashes bzw. IBAN/Kontoinhaber-Kombinationen belohnt:

• Sie erhalten 10 Punkte auf Ihrem Benutzerkonto (die Sie später für IBAN-Validierungen oder andere SOAP-Transaktionen einsetzen können), wenn Sie uns die Information bereitstellen, dass eine bestimmte IBAN zu einem bestimmten Kontoinhaber gehört und diese Information für uns neu ist.
• Wir wehren uns gegen Benutzer, die bedeutungslose Hashes hochladen, die nichts mit irgendeiner IBAN zu tun haben, nur um ihr Konto aufzuladen: wenn wir das bemerken, werden alle jemals für Hashes/IBANs gutgeschriebene Punkte vom Guthaben abgezogen und das Benutzerkonto suspendiert.

Die einfachste Art, auf diese Art Punkte zu verdienen, ist die Verwendung der Funktion submit_iban, die eine IBAN und den dazugehörigen Kontoinhaber als Parameter erwartet. Diese Funktion erledigt das Berechnen des Salzes und das Hashen und speichert schließlich die Hashes. Der Nachteil dieser einfach zu benutzenden Funktion ist, dass Sie darauf vertrauen müssen, dass wir wirklich weder IBANs noch Kontoinhaber dauerhaft speichern. Neben der Einfachheit hat diese Funktion auch den Vorteil, dass Sie kein Risiko haben, jemals die oben beschriebenen Minuspunkte für falsche Hashes zu kassieren, weil wir das Hashen so selbst erledigen.

Die folgende zweite Methode ist sicherer, weil Sie zu keinem Zeitpunkt IBANs übermitteln, aber weniger komfortabel: Zuerst die Funktion get_salts aufrufen, die aus dem Namen des Kontoinhabers einen oder mehrere Salz-Werte generiert. Dann der Reihe nach jeden der erhaltenen Salz-Werte an die IBAN anhängen (immer nur einen auf einmal) und aus IBAN und Salz einen SHA-256-Hash berechnen, und schließlich mit der Funktion submit_hashes alle diese Hashes in unsere Datenbank eintragen.

Warum ist das sicher?

Es ist wichtig, sicherzustellen, dass selbst wenn ein Hacker unsere Datenbank mit der darin enthaltenen Liste von Hashes erbeutet, weder IBANs noch Namen von Kontoinhabern aus der Datenbank rekonstruiert werden können.

Das ist tatsächlich der Fall, aus folgenden Gründen:

• Wir verlassen uns auf etablierte kryptographische Methoden, statt zu versuchen, selbst das Rad neu zu erfinden: SHA-2 ist wohlbekannt und bildet die Basis für weitverbreitete Sicherheitsanwendungen und -protokolle wie z. B. TLS und SSL, PGP, SSH, S/MIME und IPsec.
• Wir verwenden im allgemeinen unterschiedliche Salz-Werte für unterschiedliche IBANs. (Die Salze sind von den Kontoinhaber-Namen abgeleitet, die im allgemeinen für verschiedene IBANs verschieden sind). Wenn (beinahe) jeder Hash mit einem anderen Salz erzeugt wurde, wird ein Brute-Force-Angriff auf die IBANs (d.h., alle möglichen Werte einer IBAN hashen und nachschauen, ob der resultierende Hash in der Liste steht) unpraktikabel.
• Nur die IBAN-Hashes werden dauerhaft gespeichert, jedoch nicht die Salze, die aus den Namen der Kontoinhaber abgeleitet sind. Neben den IBANs können also auch die Namen der Kontoinhaber nicht aus dem Datenbankinhalt abgeleitet werden.