Unique ID nochmal Unique machen

[beta20]

Hallo zusammen,

ich habe eine eindeutige ID, die sich folgendermaßen zusammensetzt
(Als Ziffern können A-Z und a-z und 0-9 vorkommen):
Ziffer 1-2: ID eines Gerätes (also 62^2 Kombinationen)
Ziffer 3-5: ID eines Event (also 62^3 Kombinationen)
Ziffer 6-8: Zufällige ID, die pro Event eindeutig ist ((also 62^3 Kombinationen)

Also wäre beispielsweise:
AA 001 002
Folgendes Problem / Unschönheit habe ich nun:
AA 001 (dieser ersten 5 Ziffern) sind dann immer gleich pro Event. Nur der hintere Teil unterscheidet sich. Da diese ID als Passwort dient, kann jemand eine gewisse Logik des Passworts entdecken und probiert einfach verschiedene Kombinationen der letzten 3 Ziffern durch.

Meine Fragen:
- Stimmt die Berechnung der Kombination überhaupt?
- Kann ich diese ID nochmal umwandeln, sodass die Logik nicht erkennbar ist, aber die ID immer noch eindeutig ist? Wenn ja wie?

Danke für jede Hilfe.

 

[InfectedBytes]

Deine Berechnung sollte stimmen.
Du könntest deine ID verschlüsseln.

Ansonsten ist die Frage ob dein Ansatz überhaupt der richtige ist. Wenn du mehr zu deinem Projekt sagst, kann man mal überlegen ob es nicht bessere Möglichkeiten gibt.
Falls das ganze z.B. übers Netzwerk gehen soll, könntest du den ganzen Kommunikationskanal sichern z.b. via SSL

 

[beta20]

Wie genau willst Du die ID verschlüsseln?
SHA512 etc. klar wäre möglich, aber das Passwort soll immer noch NUR 8 Zeichen sein.
Das ist gerade mein Problem. Ich brauche also irgendeine Verschlüsselung, der mit den achtstelligen Code nochmal umwandelt in einen achtstelligen Code.
Eine Idee?

Kurz zum Projekt:
1) Es wird ein Passwort generiert, damit ein User mit diesem Passwort in einem WLAN (kein Internet verfügbar) etwas abrufen kann.

2) Sobald der User zu Hause ist, hat er natürlich das WLAN nicht mehr zur Verfügung, möchte aber mit dem gleichen Code dies ebenfalls abrufen. (In der Zwischenzeit wurden die Informationen ebenfalls in das Internet geladen)

Ein anderer Ansatz fällt mir nicht ein.

 

[InfectedBytes]

also erstmal SHA512 ist kein Verschlüsselungsalgorithmus, sondern ein hashing algorithmus!
Wenn du das einfach nur vor einem simplen User schützen möchtest, dann reicht eine simple Verschlüsselung, also z.B. einzelne bits permutieren, wobei du in deinem Fall aufpassen musst, dass das Ergebnis weiterhin nur lesbare Zeichen besitzt.

Falls du jedoch eher einen "echten" Schutz willst, würde ich den Ansatz lieber ganz überdenken.
Erstmal sind 8 Zeichen unglaublich wenig, da solltest du schon mehr nutzen.

Beispielsweise könntest du Serverseitig ein zufälliges Passwort erzeugen und in einer DB einfach eintragen was dieses Passwort kann. Also z.b.:
Passwort=54sd86g45dfv87gd5y => Gerät=xy Event=12345 etc.
Der Benutzer gibt nun einfach sein generiertes Passwort ein und der Server übersetzt für sich allein in die Zieldarstellung und verarbeitet dies.
Dadurch weiß der Nutzer nichtmals das es Geräte/Events/etc. gibt und zudem ist das Mapping von Passwort auf Gerät/... nur dem Server bekannt.

 

[beta20]

Danke für die Antwort.

"zufälliges Passwort" ->
heißt, dass das Passwort u.U. nochmals vorkommen kann, also dann nicht mehr eindeutig ist.

Ok vllt werde ich nochmal etwas konkreter:
Die ersten 5 Nummern sind gleich (1-2: ID des Gerät und 3-5: ID des Event)
6-8: generiertes Passwort für ein File.

Der User selbst erstellt KEIN Passwort. Das Passwort wird vom Programm generiert, welches wie gesagt eindeutig sein soll.
Das generierte Passwort selbst wird natürlich in der Datenbank gespeichert, womit dann auch ermittelt wird.
Heißt also ich habe in meiner Datenbank in der Tabelle "File":
ID Name Passwort
1 Test abc

Somit habe ich dann:
AA 001 abc

Damit der User das File abrufen kann, muss er derzeit diesen Code angeben: AA001abc
Dieser Code will ich nun nochmal umwandeln (aber muss 8-stellig bleiben), sodass AA001 ebenfalls umgewandelt wird. Der Code selbst muss dann immer noch eindeutig sein.

 

[InfectedBytes]

Wenn du den Code lang genug machst, sind Kollision praktisch ausgeschlossen. Bei einer 128 Bit GUID (typischerweise 32 lesbare Zeichen), beträgt die Wahrscheinlichkeit 1 / 2^128, also etwa 2,9387e-39. Selbst wenn du Milliarden GUIDs pro Sekunde erzeugen würdest, würdest du in zig Jahren nur eine Handvoll von Kollisionen haben.
Außerdem kann dieser Code weiterhin eindeutig sein, indem du einfach z.B. inkrementelle Werte nutzt (z.b. Pseudozufall mit spezifischen seed)

In dem was ich eben schrieb hat der Benutzer auch kein Passwort erstellt, sondern der Server.
Hier nochmal der Ablauf von dem was ich eben schrieb:
Programm (idealerweise der Server und nicht das Benutzerprogramm) erzeugt einen (peusdo)zufälligen Schlüssel und speichert diesen in einer DB (wenn es unbedingt sein muss, kann dieser Key auch nur 8 Zeichen lang sein)
Key Device Event PW
1234abcd AA 001 002

Der Benutzer bekommt nun aber nur den Key 1234abcd gesagt.
Wenn er dann auf dein File zugreifen will, gibt er diesen Key an, der Server schaut dann in seiner Liste nach weiß nun, dass der User AA001002 verwenden will.

Da der Key (pseudo)zufällig generiert wurde, bringt stumpfes ausprobieren rein gar nichts.


Das Problem ist halt in jedem Fall, dass 8 Zeichen viel zu wenig sind um auch nur annähernd sicher zu sein

 

[beta20]

Verstehe ich leider nicht so ganz.
Klar, kann der Schlüssel zum einzelnen File auch 32 Stellen haben.
Aber zu einem Passwort soll genau ein File gehören.

Ja, so soll es auch sein:
User gibt das Passwort ein und bekommt das File mit diesem Passwort.
Das sind dann 62^8 Kombinationen bzw. Files´s für eine einzige Firma sollte das ausreichend sein.

Der Benutzer bekommt nun aber nur den Key 1234abcd gesagt.
Wenn er dann auf dein File zugreifen will, gibt er diesen Key an, der Server schaut dann in seiner Liste nach weiß nun, dass der User AA001002 verwenden will.

Woher weiß dann das Programm, dass er AA001002 verwenden will?
Woher weißt du, dass 1234abcd eindeutig ist?

 

[InfectedBytes]

Woher weiß dann das Programm, dass er AA001002 verwenden will?

Das Programm guckt in der Tabelle nach! Bei der Erzeugung von 1234abcd wurde ja in die Tabelle geschrieben das dieser Wert zu AA001002 gehört:

Programm (idealerweise der Server und nicht das Benutzerprogramm) erzeugt einen (peusdo)zufälligen Schlüssel und speichert diesen in einer DB (wenn es unbedingt sein muss, kann dieser Key auch nur 8 Zeichen lang sein)
Key Device Event PW
1234abcd AA 001 002

Woher weißt du, dass 1234abcd eindeutig ist?

Indem ich es Eindeutig erzeuge. Ganz stupide (und unsicher) wäre z.b. indem das Programm einfach hochzählt. Also die erste Anfrage bekommt einfach 00000001, die zweite Anfrage 00000002, usw.
Besser wäre es z.b. einen Pseudo Zufallszahlen generator zu nutzen, dessen Periodenlänge 62^8 ist.
Dieser würde nämlich erst eine doppelten Wert erzeugen, wenn alle 62^8 Möglichkeiten durch sind.

 

[InfectedBytes]

Ansonsten kannst du auch bei deinem Ansatz bleiben und einfach deine ID AA001002 verschlüsseln. Ist zwar nicht besonders sicher, aber vielleicht reicht es dir ja.
Ganz simpel (und unsicher ) wäre z.b. sowas:
letzte Ziffer sagt an um wieviel die erste Ziffer verschoben wird und umgekehrt
vorletzte Ziffer sagt an um wieviel die zweite Ziffer verschoben wird und umgekehrt
...
Wenn also vorne A und hinten 2 steht würde, so wird der Wert von A um zwei erhöht werden (A wird zu C)
etc.
Ist immernoch sehr unsicher, aber besser als das ganze im Klartext dem Nutzer zu geben.

 

[beta20]

Verstehe ich leider immer noch nicht. Was ist der Sinn nochmal eine zweite eindeutige ID zu erzeugen, sofern diese die gleiche Anzahl an Zeichen hat? Das Passwort selbst ist ja schon eindeutig

Nach meinem Verständnis benötige ich einen JAVA-Code, der mir aus den Infos (GeräteID, EventID, FileID) ein eindeutiges Passwort erzeugt, jedoch mit einer neuen Kombination. Dieser neue erzeugte Code geht dann an den User mit dem er das File später auch abrufen kann.

Ich hole nochmals etwas aus - ich habe folgende Szenario in einem Unternehmen:
Ich habe ein Unternehmen, das z.B. 100 Geräte hat.
Jedes dieser Geräte nutzt meine Software.
Vor jeder Installation: Wird eine eindeutige ID des Gerätes festgelegt
(Zeichen 1-2)

Jedes Gerät kann n Events haben
(Zeichen 3-5) -> also maximal um die 200.000 Events.
Heißt also: Selbst wenn jeden Tag eine Veranstaltung gemacht wird, wären das ca. 560 Veranstaltungen.
OK: wenn ich darüber nach denke sollte man das Passwort auf 10 Stellen erweitern (ob 8 oder 10 macht dann auch nicht mehr viel aus)

File
- Bei jedem Event werden x Files (Bilder) erstellt. Jedes File wiederum ist eindeutig
(Zeichen: 6-8)

Zusammen ergibt das eine eindeutige ID (Geräte ID Event ID, File ID) bzw. das Passwort das der User bekommt.
Das Passwort wird dann ausgedruckt und erhält der User.

Mit dem Passwort hat der User dann die Möglichkeit:
a) Das File herunterzuladen in dem internen Netz (Abruf via WLAN9
b) Nach der Veranstaltungen werden die Files nochmals auf einen anderen Server hochgeladen (inkl. Infos zu dem Passwort etc.), womit der User dann ebenfalls die Möglichkeit hat das File später auch im Internet abzurufen (= gleiches Passwort wird verwendet)

Heißt für mich: Ich benötige etwas ähnliches wie der MD5 Hash, wobei es nur 8 bzw. 10 Zeichen hat.
Gibt es so etwas denn?

Später kann man den Schritt vllt. noch gehen, dass die Files nur in einer bestimmten Zeit abrufbar sind.
Also sprich selbst wenn das Passwort gültig ist, dass dann ein Fehler kommt, dass das File nicht abrufbar ist.

 

[InfectedBytes]

Verstehe ich leider immer noch nicht. Was ist der Sinn nochmal eine zweite eindeutige ID zu erzeugen, sofern diese die gleiche Anzahl an Zeichen hat? Das Passwort selbst ist ja schon eindeutig

Eben aus Sicherheitsgründen.

Ein Hash wird dir nicht viel helfen, da es eine Einwegfunktion ist

 

[Thallius]

Also,

anscheinend hat der User direkten Zugriff auf die Datei auf dem Server und bekommt sie dann via direktem Download. Ist das so richtig?

Wenn ja, dann vergiss den Mist. Das macht man nicht. Erstelle einen Webservice der das File an den Client schickt.

Der User ruft dann eine php seite auf zum Beispiel: getfile.php?fileId=DeineIDkombiniertmitdemHash

Nun kannst du einfach einen beliebigen Hash mit beliebigem Salt über deine ID laufen lassen und hängst diesen an deine ID dran. Dieses ID+Hash gibst du dann als fileId dem User. Der ruft die PHP Seite in seinem Browser auf und die php seite erzeugt aus dem ID Teil der mitgegebenen ID den hash und vergleicht ihn mit dem Hash-Teil. Nur wenn dieser Stimmt gibts auch die Datei.

Gruß

Claus

 

[beta20]

Also,

anscheinend hat der User direkten Zugriff auf die Datei auf dem Server und bekommt sie dann via direktem Download. Ist das so richtig?
Claus

Nein, der User muss auf eine Seite: www.myapp.de/password
Dort gibt er das Passwort ein, dass er damals bekommen hat.

Heißt also:
-> Sobald ein neues File erzeugt wird, wird in der Datenbank ein Passwort generiert und das dem File zugeordnet. Der User bekommt dann dieses Passwort ausgedruckt.
Anschließend geht der User auf die Seite www.myapp.de/password und gibt das Passwort, das er erhalten hat, in dem Formular dort rein.
Anschließend wird in der Datenbank nach diesem Passwort gesucht und der User wird auf eine neue Seite mit dem Bild / File geleitet. Dort kann er dann dies ausdrucken, downloaden etc.

Frage ist eben, wie ich das Passwort erzeuge, sodass kein Muster erkannt werden kann.

 

[Thallius]

Habe ich doch geschrieben...

 

[beta20]

ok und wie macht man das mit Hash und Salt. Habe leider keine Erfahrung damit

 

[Thallius]

Da hilft lesen und lernen

http://code-bude.net/2015/03/30/grundlagen-sicheres-passwort-hashing-mit-salts/

 

[beta20]

Würde das auch gehen:
Meine ID ist ja (aus den GeräteID, Event ID, CodeId) ist ja eindeutig.
Nun erzeuge ich mit MD5 den Hash und schneide den nach 8 oder 10 Stellen ab.
Dieser 8 oder 10 stellige Code gebe ich dann dem User zurück als sein Code um die Datei abzurufen.

Problem ist: MD5 hat nur Kleinbuchstaben. ich brauche aber
Groß und Kleinschreibung

Oder gibt es andere Algorithmen, die das können?

 

[Nuiton]

Lese doch mal den Artikel den @Thallius verlinkt hat. MD5 ist viel zu unsicher.

 

[beta20]

Danke - habe ich gemacht, verstehe aber nicht so ganz wie das ablaufen soll mit Salt.

Vielleicht habe ich es auch einfach nicht so ganz erklärt um es zu verstehen was ich brauche?

• Ich generiere ein 8-10 stelliges Passwort (GeräteID, Event ID, CodeId) - was durch die Kombination eindeutig sein sollte
• Diesen Code möchte ich so nicht an den User als Passwort (Code) herausgeben, da er sonst ein Muster erkennen kann (die ersten Ziffern sind immer gleich!)
  • Deshalb möchte ich dieses 8-10 stellige Passwort nochmal umwandeln in wieder ein 8-10 stelliges Passwort.
  • Dieses neu erzeugten Passwort bekommt dann der User ausgedruckt etc. und kann damit dann seine Datei abrufen

Hinter jedem Passwort steckt also direkt eine Datei.

Was die Unsicherheit angeht:
62^8 oder 62^10 Kombinationen sollten genügend sein, wenn man bedenkt hinter jedem Passwort steckt genau eine Datei.
Die Dateien werden auch nach einer gewissen Zeit gelöscht, sodass die Wahrscheinlich gering ist, dass wenn jemand einen ZufallsCode eingibt zu einer Datei gelangt, zu der er nicht kommen sollte.

Demnach wäre zum Beispiel meine Idee das erste Passwort (GeräteID, Event ID, CodeId) mit MD5 zu hashen und dann davon nur die 8-10 stellen zu nehmen, was dann der neue Code ist, welcher an den User gegeben wird...

 

[Nuiton]

Warum willst du das Rad neu erfinden? Du kannst BCrypt benutzen.
Von der Webseite:

String hashed = BCrypt.hashpw(password, BCrypt.gensalt());
if (BCrypt.checkpw(candidate, hashed))
    System.out.println("It matches");
else
    System.out.println("It does not match");

 

[beta20]

danke.
Und hier kann ich auch die Anzahl an Stellen einstellen?
Beispiel: 10 Stellen:

// gensalt's log_rounds parameter determines the complexity
// the work factor is 2**log_rounds, and the default is 10
String hashed = BCrypt.hashpw(password, BCrypt.gensalt(10));