Sie brechen eines der Tabus hashCode () . Sie verwenden die Ausgabe als Schlüsselkennung. Das ist falsch.

Sie sehen, die Ausgabe von hashCode () (in der Standardimplementierung) ist eine 32-Bit-Ganzzahl ohne Vorzeichen, das sind ungefähr 4 Milliarden eindeutige Hashcodes. Klingt ziemlich viel? Nun, nicht so sehr. Das Anwenden des Geburtstagsproblems in diesem Fall zeigt, dass bei ungefähr 77000 Objekten eine Kollisionswahrscheinlichkeit von ungefähr 50% besteht. 50% ige Wahrscheinlichkeit, dass zwei Objekte denselben Hashcode haben.

Ein weiteres Problem besteht darin, dass sich die Implementierung von hashCode () von einer Java-Version zur anderen ändern kann. Es ist nicht als permanente Kennung eines Objekts gedacht, daher gibt es nichts, was es dazu zwingt, über Versionen hinweg konsistent zu sein.

Wenn Sie darauf bestehen, Hashes als Objektkennungen zu verwenden, ist es viel besser, stattdessen eine eigene Methode zu verwenden hashCode () zur Verwendung für Ihre Schlüsselkennungen (z. B. getMySpecialHashKey () . Sie können so etwas wie MessageDigest.getInstance ("SHA-256") , um das Objekt in einen schönen 256-Bit-Schlüssel zu verdauen.

Meine Empfehlung: Lassen Sie die ganze Idee des Hashing des Objekts hinter sich und generieren Sie stattdessen eine zufällige Kennung für Ihr Objekt, wenn Sie konstruieren es. Etwas in der Art von (in Java)

  SecureRandom secRand = new SecureRandom (); byte [] objIdBytes = neues Byte [16]; //128-bitsecRand.nextBytes ( objIdBytes); String objId = Base64.encodeBase64String (objIdBytes); // Hier ist Ihre ID  

Sie scheinen den Zugriff auf ein Objekt nur an die Kenntnis seines Schlüssels zu binden. Das ist auch falsch. Ein richtiger Ein berechtigungsbasiertes Modell mit ordnungsgemäßer Authentifizierung und Autorisierung ist erforderlich.

Java hashCode () sollte niemals so verwendet werden. Tu es niemals! Es ist sogar legal (obwohl nicht empfohlen), dass alle Instanzen einer Klasse denselben Hashcode zurückgeben. Der Vertrag in Java lautet "Zwei Objekte, die als gleich angesehen werden, müssen denselben Hashcode haben". Nicht mehr und nicht weniger. Es wäre beispielsweise gültig, Hashcode 1 für alle ungeraden Zahlen und 0 für gerade zurückzugeben.

Hashcode wird für eine schnellere Suche in Sammlungen wie HashMap verwendet Code> und Kollisionen werden erwartet.

Viele Klassen definieren ihre eigene Version von hashCode () , und wenn Sie den Code kennen, können Sie dies häufig problemlos tun Sagen oder erraten Sie den Hashcode.

Das ist also absolut unsicher.

Es ist nicht kryptografisch sicher, da dies nicht Teil seiner Anforderungen ist.

Die Implementierung des HashCodes ist ein Implementierungsdetail bis zur JVM und kann für verschiedene Objekttypen unterschiedlich sein (Objekte können die überschreiben hashCode-Methode und stellen eine eigene Implementierung bereit.

Der Zweck des Java-hashCode besteht darin, Objekte zu identifizieren, wenn sie in Hash-Tabellen platziert werden. Ihre Hauptanforderung ist die Leistung. Es hat auch eine Länge von nur 32 Bit, was zu kurz ist, um Kollisionen zu vermeiden. Für den beabsichtigten Zweck (Hash-Tabellen) sind zwei Objekte mit demselben Hash nur ein kleines Problem. Die Identifizierung von Objekten ohne Mehrdeutigkeitskollisionen ist jedoch ein großes Problem.

Sie sollten jedoch im Allgemeinen keinem Benutzer den Zugriff auf Objekte erlauben Objekt, nur weil sie den Hash-Code des Objekts kennen. Verwenden Sie ein ordnungsgemäßes Rechteverwaltungsschema. Verwenden Sie kennwortgeschützte Benutzerkonten, bei denen jeder Benutzer einen anderen Satz von Berechtigungsparametern hat. Wenn der Benutzer versucht, auf ein Objekt zuzugreifen, überprüfen Sie, ob seine Berechtigungen dies zulassen, und lehnen Sie die Anforderung ab, wenn dies nicht der Fall ist.

Es ist sicherlich nicht sicher genug für eine Situation, in der das Erraten von Werten Informationen enthüllen kann.

Zumindest einige der Überschreibungen sind nicht sicher genug, um angesichts von als Hash-Code verwendet zu werden Beliebige vom Benutzer ausgewählte Eingaben (mit Javas String.hashCode () überschreiben ist es wirklich einfach, einen Hash-DoS-Angriff gegen alles durchzuführen).

In Fällen, in denen Sie eine Kennung wünschen, Ich empfehle, einen einfachen Bezeichner (z. B. einen numerischen Schlüssel in einer Datenbank, eine atomar inkrementierte Ganzzahl, die ein Schlüssel für eine Hash-Tabelle ist usw.) zu verwenden und dann einen kryptografischen Hash davon und ein Salt anzuhängen.

Das heißt, Ihre öffentlich zugängliche ID hätte die Form (in sprachunabhängiger Form):

  Verketten (PrivateID, HexString (SHA256 (UTF8Bytes (Verketten (Salt, PrivateID))))  

(Sie können einen Teil des Hashs für eine kleinere ID entfernen, um die Zeit bis zur Brute-Force zu verkürzen.)

Dann erhalten Sie die private ID als eine Teilzeichenfolge, und die vollständige ID kann erneut überprüft werden. Das allgemeine Verfahren lässt sich auch leicht zwischen Sprachen portieren.

Die Handvoll CPU-Zyklen, die dies kosten wird, werden im Vergleich zum Rest des Systems keine großen Auswirkungen haben, es sei denn, Ihr System ist so trivial, dass Sie Es wird sowieso nicht viel CPU verbraucht. Wenn Sie dies also nicht auf einem Gerät mit sehr geringem Stromverbrauch ausführen (wie in, weitaus weniger leistungsstark als ein billiges Telefon), ist dies kein Problem.

In Fälle, in denen Sie tatsächlich einen Hash-Code als Hash-Code verwenden möchten und sich mit benutzerdefinierten Eingaben befassen müssen, verwenden Sie dann einen Startwert-Hash-Algorithmus (z. B. SpookyHash) und stützen Sie Ihren Startwert auf die Startzeit (oder noch besser auf die Startzeit). eine Mischung aus Startzeit und der Zeit, zu der Sie den Hash-Container erstellen). (Nichts mit kryptografischen Hashes zu tun, daher können sie viel schneller sein. Das einzige Sicherheitsrisiko, das dadurch vermieden wird, ist Hash-DoSing.)