Ist das Verschleiern / Verschleiern von öffentlich zugänglichen Datenbank-IDs wirklich eine bewährte Methode?

Ich habe gehört, dass Leute hier und da im Internet Vorträge halten, dass es die beste Vorgehensweise ist, öffentlich zugängliche Datenbank-IDs in Webanwendungen zu verschleiern. Ich nehme an, sie meinen hauptsächlich Formulare und URLs, aber ich habe nie mehr als einen Schluck zu diesem Thema gelesen.

EDIT : Natürlich, jetzt, wo ich das frage, finde ich einige Ressourcen zu diesem Thema:

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

Diese Links haben einiges von meiner Neugier befriedigt, aber die SO-Posts haben nicht viele Stimmen und sind nicht unbedingt auf das Thema in diesem Kontext ausgerichtet, sodass ich nicht sicher bin, was ich davon halten soll, und einige behaupten, dass die dritte Link ist Schwindel. Ich werde den Rest meiner Post intakt lassen:

Ich verstehe die Unterschiede zwischen Unbekanntheit und Sicherheit sowie wie die beiden zusammenarbeiten können, aber ich kann mir nicht vorstellen, warum dies notwendig wäre.

Gibt es eine Wahrheit, ist es nur Paranoia oder ist es einfach nur völlig falsch?

Ich kann mir Möglichkeiten vorstellen, dies zu tun, aber es fügt dem Anwendungscode natürlich eine Menge Komplexität hinzu. Unter welchen Umständen wäre dies sinnvoll? Wenn dies ist etwas , das Menschen oft tun, wie es in der Regel zum Einsatz? Hashing der Identifikatoren? Etwas anderes? Es scheint eine Menge Arbeit für nicht viel zusätzliche Sicherheit zu sein. Ich bin nicht auf der Suche nach echten Lösungen, ich möchte nur eine Vorstellung davon bekommen, wie / warum die Menschen dies in der realen Welt tun würden.

Gilt dies wirklich als "Best Practice" oder handelt es sich lediglich um eine Mikrooptimierung von geringem Wert?

ANMERKUNG : Ich denke, einige Leute haben möglicherweise die falsche Idee: Ich schlage nicht vor, dass schwer zu erratende IDs der einzige Sicherheitsmechanismus sind, offensichtlich gibt es die üblichen Zugriffskontrollen. Nehmen wir an, dass diese vorhanden sind und dass die bloße Kenntnis der ID oder der Hash-ID eines Datensatzes nicht ausreicht, um Zugriff zu gewähren.

Ich glaube nicht , es so wichtig ist, aber es gibt einige Szenarien , wenn es könnte auf andere Entscheidungen je Rolle , die Sie machen.

Wenn Sie beispielsweise eine Bestell-ID offenlegen, die nacheinander generiert wird, und Sie einen Social-Engineering-Angriff mit jemandem hatten, der den Kundensupport anrief und sagte: "Hey, ich habe gerade 2000 US-Dollar für einen neuen Computer ausgegeben, und Sie haben mir die Bestellung eines anderen Mannes geschickt ein $ 15 Kabel, jetzt bin ich aus $ 2000 "Sie könnten eine Menge Zeit damit verbringen, das Problem zu überprüfen, bevor Sie entweder annehmen, dass es falsch ist oder Sie dem Fälscher einen neuen Computer schicken.

Es gibt ähnliche, weniger raffinierte, aber peinliche Variationen des Themas. Wenn ein Bösewicht eine Bestell-ID inkrementiert, einen Link per E-Mail an eine Quittung sendet und keine zusätzlichen Überprüfungen vorgenommen werden, um zu überprüfen, ob die Person, die auf den Link geklickt hat, berechtigt ist, die Bestell-ID anzuzeigen, werden plötzlich unwissentlich private Kundendaten angezeigt an die falsche Person.

In solchen Fällen wird die Belichtung leicht gemindert, wenn die Zahlen nicht sequenziell sind, da das Erraten mit geringerer Wahrscheinlichkeit zu interessanten Ergebnissen führt. Auf der anderen Seite benötigen Sie jetzt eine bequeme Möglichkeit, eine Bestell-ID in Kunden-Support-Interaktionen zu referenzieren, die nicht zu langen Hin- und Her-Gesprächen mit telefonbasierten Kundeninteraktionen führt, während Ihr Mitarbeiter versucht, zwischen B, PD und zu unterscheiden T in Bestellnummer BPT2015D.

Ich würde sagen, es ist schwierig, diese Verschleierung als "Best Practice" zu bezeichnen, aber in bestimmten Szenarien kann es die Leichtigkeit verringern, eine weitere Schwachstelle in Ihrem Validierungs- oder Autorisierungscode auszunutzen. Auf der anderen Seite spielt es keine Rolle, ob jemand weiß, dass Sie den Blog-Beitrag Nr. 1 oder Nr. 2559 geschrieben haben. Wenn die ID selbst mit zusätzlichen Kenntnissen keine wertvollen Informationen enthält, hat das Argument, dass die Verschleierung eine bewährte Methode ist, weniger Gewicht.

Es gibt ein zweites mögliches Argument: Ihre Datenbankkennung könnte Sie zu einer bestimmten Datenbankimplementierung (oder -instanz) verleiten, und wenn Ihr Unternehmen aufgekauft wird oder einen Konkurrenten aufnimmt und Sie nun zwei Altsysteme oder den CEO zusammenführen müssen Sie gehen mit dem Repräsentanten von DynoCoreBase aus und entscheiden, dass Sie jetzt alle Ihre Daten auf DynoCoreBase Version 13h verschieben und alle Primärschlüssel als Guids verwenden möchten. Außerdem müssen Sie eine Art Zuordnungsebene erstellen, um alte IDs in neue zu übersetzen IDs, damit alte URLs nicht kaputt gehen. Ob diese Szenarien für Sie jedoch von Bedeutung sind, hängt wesentlich mehr von der Art Ihres Unternehmens (und der Kundenbeteiligung an diesen IDs) ab als von allgemeinen Best Practices.

Das ist meine Einstellung dazu:

Während "Sicherheit durch Unbekanntheit" offensichtlich nicht ausreicht, kann Unbekanntheit die Sicherheit unterstützen, wenn auch nur ein wenig. Sie müssen sich entscheiden, ob dieses kleine Stück Pseudosicherheit den zusätzlichen Aufwand wert ist, der erforderlich ist, um so etwas in Ihrer Anwendung bereitzustellen.

Es gibt einen anderen Grund außerhalb der Sicherheit, den ich mir vorstellen kann, dies umzusetzen:

Privatsphäre

Angenommen, wir haben es mit Benutzer-IDs in der URL zu tun. Wenn Joes Benutzer-ID 100und Bobs Benutzer-ID gleich sind 101, ist es wahrscheinlich offensichtlich, dass Joes Konto zuerst erstellt wurde. Während dies in den meisten Anwendungen möglicherweise keine Rolle spielt, kann es für einige von Bedeutung sein. Dies ist ein Beispiel für Privatsphäre, die ausschließlich durch Unklarheiten gekennzeichnet ist. Wenn Sie also nicht über ein ausgeklügeltes System zur Verschleierung der Benutzer-IDs verfügen, ist es möglicherweise einfach, herauszufinden, ob der Benutzer mit der ID 3Js9kW3hTs7sa120über ein längeres Konto als der Benutzer mit der ID verfügt Q8Hs73kks0hEg.

Aus dem Link, auf den ich verwiesen habe:

Der erste ist, dass Sie anhand der URL für ein Objekt die URLs für Objekte ermitteln können, die um dieses Objekt erstellt wurden. Dies legt die Anzahl der Objekte in der Datenbank zu möglichen Konkurrenten oder anderen Personen , die Sie vielleicht wollen diese Informationen nicht mit (wie bekanntlich gezeigt , von den Alliierten deutsche Panzerproduktionsniveaus zu raten , indem man den Seriennummern suchen.)

Durch die Verwendung einer Auto-Inkrement-ID wird die Anzahl der Objekte in der Datenbank öffentlich verfügbar gemacht und es kann angezeigt werden, welche zuerst erstellt wurden und welche neuer sind. Diese Informationen können die Tatsache verraten, dass ein Unternehmen neu ist oder sogar nicht gut läuft. Zum Beispiel: Nehmen wir an, Sie bestellen ein Buch und Ihre Bestellnummer lautet 1. Es könnte offensichtlich sein, dass Ihre Bestellung die erste im System war, was beunruhigend sein kann. Angenommen, Sie gehen zurück und bestellen einen anderen und Ihre Bestellnummer lautet 9. Dies verrät die Information, dass im Zeitraum zwischen Ihren beiden Bestellungen nur 7 Bestellungen getätigt wurden. Dies kann für Wettbewerber wertvolle Informationen sein. In diesem Fall ist die numerische Auto-Inkrement-ID wahrscheinlich besser verschleiert.

Das Wort "Obscure" ist hier wahrscheinlich leicht irreführend und kann dazu führen, dass die Leute denken, "obfuscate" oder "partial hide".

Es wird empfohlen, niemals intern generierte Datenbankschlüssel als Teil einer öffentlichen URL einzuschließen, wenn diese Datenbankeinträge vertrauliche Daten enthalten.

Es ist einfach zu einfach, mit den Nummern in der URL zu spielen und auf andere Datensätze zuzugreifen.

Ich werde gegen den Mainstream gehen und Ihnen sagen, dass die Verwendung eines zufälligen, langen Bezeichners meiner Meinung nach eine ziemlich anständige Form der Sicherheit ist.

Es muss jedem, der Zugriff auf diese Daten hat, klar gemacht werden, dass diese genauso sensibel sind wie ein Passwort. Und natürlich hat es den Nachteil, dass es schwieriger sein kann, sich zu ändern, wenn es in die Wildnis geht.

Es hat jedoch einige Vorteile gegenüber den üblichen Paaren aus Benutzername und Passwort. Erstens hat der Benutzer keine Wahl, so dass Sie sicher sein können, dass es im Wesentlichen unmöglich ist, zu erraten. Es macht keinen Sinn, eine absolut sichere Site zu entwerfen, wenn der Administrator seinen Vornamen als Kennwort wählt. Zweitens hat jeder Gegenstand eine andere Kennung. Wenn also einer Zugang zu einem Gegenstand hat, hilft dies dem anderen nicht.

Je mehr Sicherheitsstufen vorhanden sind, desto besser. Diese Methode allein kann jedoch sicherer sein als ein paar Anmeldeinformationen.

Dies hat zwei Aspekte: Benutzerfreundlichkeit und Sicherheit.

Aus Sicherheitsgründen ist das Verdecken von IDs ziemlich sinnlos. Wichtig ist, dass die ID niemals der einzige Schlüssel zu einer nicht öffentlichen Ressource sein darf. Dies bedeutet, dass Sie, wenn Sie ausgewählten Benutzern Zugriff auf eine bestimmte Seite gewähren möchten, nicht nur die ID der Seite in der URL benötigen, sondern auch einen tatsächlichen Sicherheitsmechanismus implementieren müssen, z. B. eine Anmeldung mit Benutzername / Passwort oder eine Authentifizierung mit öffentlichem / privatem Schlüssel. sowie eine ordnungsgemäße Autorisierung (das heißt, das System muss in der Lage sein, auf Einzelfallbasis zu beurteilen, ob Benutzer X auf Ressource Y zugreifen darf, und entsprechend zu handeln).

In Bezug auf die Benutzerfreundlichkeit lautet der allgemeine Ratschlag, künstliche Schlüssel verborgen zu halten: Sie haben für den Benutzer keine Bedeutung. Wenn Sie sie auf offensichtliche Weise offenlegen, führen Sie eine zusätzliche Abhängigkeit ein, die besonders schwierig zu handhaben ist, da sie im Freien lebt das Reich der Software - die Leute werden diese IDs aufschreiben, per E-Mail, Fax, Druck, Lesezeichen usw., und wenn Sie sie jemals ändern, werden Sie nervige Support-Tickets erhalten.

Nein , Sie absolut positiv wollen keinen Zugriff auf beliebige Ressourcen zu ermöglichen , nur durch ihre interne ID kennen. Dies ist das Internet, unabhängig davon, welche böswillige, kriminelle oder kindliche Präsenz Sie sich vorstellen, tatsächlich vorhanden ist , und sie werden früher oder später auf Ihre Website gelangen. Es sei denn, alles, was Sie jemals bedienen könnten, ist für alle völlig öffentlich (und wenn Sie auch nur einen Kunden haben, ist dies garantiert nicht der Fall), müssen Sie den Zugriff auf diejenigen beschränken, die tatsächlich dazu berechtigt sind.

Die übliche Lösung besteht darin, Autorisierungstoken zu verwenden, die in einer verschlüsselten Sitzung gespeichert sind, und zu überprüfen, ob etwas für den authentifizierten Benutzer sichtbar sein soll, bevor es tatsächlich gesendet wird. Hierbei kann es sich um einen tatsächlichen Sicherheitsmanager handeln, der zum Beispiel im Lieferumfang des JDK enthalten ist, oder um eine beliebige andere Komponente, die dieselbe Rolle erfüllt, sofern dies konsistent geschieht. (Es ist auch eine interessante Frage mit verschiedenen Vor- und Nachteilen, ob interne IDs an jemanden weitergegeben werden, der bereits authentifiziert ist oder nicht. Dies ist jedoch weniger sicherheitsrelevant.)

Der Wert dieses Vorgangs ist schwer zu berechnen, bis Sie tatsächlich von jemandem angegriffen werden, der es ernst meint. Dann ist es in der Regel der Unterschied, ob man sein Geschäft aufgibt oder einfach nur ein weiteres, vereiteltes Drehbuch-Kind abschüttelt.

Natürlich hängt es davon ab, wie vertraulich die Daten sind, aber aus Sicherheitsgründen würde ich mindestens die ID und einen Prüfsummenwert angeben.

Generieren Sie die Prüfsumme, indem Sie Salt (dh eine festgelegte Sammlung von Zufallszeichen) vor und nach der ID hinzufügen und eine MD5 für den Wert ausführen.

Verweigern Sie auf jeder Seite, die den ID-Wert liest, den Prüfsummenwert und vergleichen Sie ihn mit dem übergebenen Wert. Verweigern Sie die Anforderung, wenn er nicht übereinstimmt.

Wenn ein potenzieller Hacker in der Lage ist, genügend gültige Kombinationen zu erhalten, kann er möglicherweise den Salt-Wert mit brachialer Gewalt ermitteln. Wenn Sie also eine weitere Sicherheitsstufe hinzufügen, z. B. die Überprüfung der Benutzer-ID, kann dies ebenfalls hilfreich sein.