Hi, ist folgendes mathematisch möglich/lässt es sich auf ein bekanntes Problem reduzieren?: Ein Accountsystem, bei dem sich nur feststellen lässt, ob jemand, der sich einloggt/authentifiziert sich zuvor registriert hat, aber nicht zuordnen lässt, wer es ist? Würde zB bedeuten, dass man natürlich keine Accounts sperren kann, sobald sie einmal erstellt worden sind. Wäre auch ok, wenn man wesentlich leichter (Wahrscheinlichkeit, Rechenaufwand, ..) feststellen kann, ob jemand einen Account hat als sicher einzelne Authentifizierungen zuordnen zu können. Zum Beispiel würde es reichen, wenn der Rechenaufwand zum feststellen der Zuordnungen exponentiell mit der Menge der Accounts steigen würde, die Wahrscheinlichkeit für eine einzelne Authentifizierung fehlzuschlagen, obwohl man einen Account hat, jedoch nur logarithmisch. (paar Loginversuche, bevor man reinkommt sind also ok) Es muss in jedem Fall nahezu unmöglich sein, dass jemand ohne Account sich fälschlicherweise authentifizieren kann - also ähnlich schwer wie Authentifizierungen zu Accounts zuordnen zu können. Natürlich darf man davon ausgehen, dass die Teilnehmer ihre Accounts auch geheim halten wollen. Geht mir nur um die Mathematik, nicht, ob das praktisch sinnvoll wäre. Bin gespannt auf eure Antworten
bolton more schrieb: > Ein Accountsystem, bei dem sich nur feststellen lässt, ob jemand, der > sich einloggt/authentifiziert sich zuvor registriert hat, aber nicht > zuordnen lässt, wer es ist? Ich vermute, Dein Problem ist falsch formuliert. Ansonsten: Ja, das geht (sogar trivial). Gib allen registrierten Benutzern das gleiche Passwort, egal auf welcher mathematischen Grundlage das berechnet wurde. Grüße Andreas
Andreas H. schrieb: > Ich vermute, Dein Problem ist falsch formuliert. > Gib allen registrierten Benutzern das gleiche Passwort :D stimmt natürlich. Habe vergessen, dass jeder Benutzer jederzeit in der Lage sein soll, zu Beweisen, dass eine einzelne Authentifikation zu seinem Account gehört, ohne dazu seine Accountdaten preisgeben zu müssen, dass er also für beliebige Authentifizierungen seine Anonymität aufgeben kann, ohne, dass das weitere Auswirkungen hat. Ist das beim Online Ticket gegeben? Der Herausgeber kann doch bei der Ticketkontrolle rausfinden, wo ich das Ticket herhabe, oder?
bolton more schrieb: > Habe vergessen, dass jeder Benutzer jederzeit in der Lage sein soll, zu > Beweisen, dass eine einzelne Authentifikation zu seinem Account gehört, > ohne dazu seine Accountdaten preisgeben zu müssen, dass er also für > beliebige Authentifizierungen seine Anonymität aufgeben kann, ohne, dass > das weitere Auswirkungen hat. Bahnhof. Versuchs mal gaaanz langsam und deutlich für klein Fritzchen.
niemand schrieb: > Sieh dir mal an, wie Zertifikate gemacht sind. niemand schrieb: > oder das hier: > http://de.wikipedia.org/wiki/Online-Ticket beide Vorschläge passen aber leider nicht zu: bolton more schrieb: > jemand, der > sich einloggt/authentifiziert sich zuvor registriert hat, aber nicht > zuordnen lässt, wer es ist? Denn hier wäre das Cert. immer bei der Registrierung erstellt, dem Registrierenden also eindeutig zuordenbar. Wenn die Certs auch noch einmalig wären (one-time-pad mäßig), dann wäre diese Zuordnung sogar bijektiv, also könnte der Herausgeber anhand des Certs den Benutzer immer eindeutig identifizieren, oder ? Also doch alle das gleiche Passwort, bzw. ein hinreichend grosser PW-Pool, aus dem dann zufällig eins ausgewählt wird. Ist die Anzahl im Pool groß genug, geht die Wahrscheinlichkeit, dass es gerade Benutzer X ist, irgendwann gegen 0. Grüße Andreas
bolton more schrieb: > Habe vergessen, dass jeder Benutzer jederzeit in der Lage sein soll, zu > Beweisen, dass eine einzelne Authentifikation zu seinem Account gehört, > ohne dazu seine Accountdaten preisgeben zu müssen, dass er also für > beliebige Authentifizierungen seine Anonymität aufgeben kann, ohne, dass > das weitere Auswirkungen hat. Ehm, versteh mich nicht falsch aber von Kryptographie hast Du entweder keine Ahnung oder Du kannst (zumindest mir) Dein Problem nicht verständlich machen. Wenn Du Dich irgendwo einloggst wird eigentlich NIE das Passwort selbst übertragen, sondern nur irgendwelche Hashes. Das Passwort bleibt also immer nur beim Sender.Selbst der Empfänger hat typischerweise nur einen Hash des Passworts gespeichert und verifiziert dagegen. Google mal nach Challenge-Response Algorithus. Das ist ein Verfahren, wo das Ganze auch zweiseitig gemacht werden kann, sich also der Sender und der Empfänger gegenseitig identifizieren. Vielleicht ist es ja das was Du suchst... Grüße Andreas
Andreas H. schrieb: > Wenn Du Dich irgendwo einloggst wird eigentlich NIE das Passwort selbst > übertragen, sondern nur irgendwelche Hashes. Auch in simplen passiven Webformularen, in Plaintext Browser-Authentifizierung?? Oder FTP? Oder ... Richtig ist, dass saubere Verfahren nur den Hash in der Benutzer-DB speichern. Ob aber seitens des Clients oder des Servers gehasht wird ist sehr verschieden.
bolton more schrieb: > Habe vergessen, dass jeder Benutzer jederzeit in der Lage sein soll, zu > Beweisen, dass eine einzelne Authentifikation zu seinem Account gehört, bolton more schrieb: > Ein Accountsystem, bei dem sich nur feststellen lässt, ob jemand, der > sich einloggt/authentifiziert sich zuvor registriert hat, aber nicht > zuordnen lässt, wer es ist? Das wiederspricht sich. Entweder hat er einen Account der ihm zugeordnet ist, dann ist er aber identifizierbar (wenn er der einzige Zugriffsberechtigte ist) oder er hat keine exclusiven Rechte, die ihn von Anderen unterscheidbar machen würden. Klassischer Fall einer Äquivalenzrelation^^ Grüße Andreas
A. K. schrieb: > Auch in simplen passiven Webformularen, in Plaintext > Browser-Authentifizierung?? Oder FTP? Oder ... Da hast Du recht. Aber das sind (in meinen Augen) auch nur Relikte aus den Zeiten, wo IT-Security noch ein akademisches Steckenpferd von Promotionsstudenten war. > Richtig ist, dass saubere Verfahren nur den Hash in der Benutzer-DB > speichern. Ob aber seitens des Clients oder des Servers gehasht wird ist > sehr verschieden. Eigentlich nicht. Es wird immer auf der Senderseite gehashed. Denn wenn der legendäre Oscar per Mitm-Attack das Klartext PW hat, macht das Hashen beim Empfänger ja auch keinen Sinn mehr. Einzige mir bekannte Ausnahme sind die On-time-PW Generatoren (z.B. von Cisco) wo man gefahrlos auch den Key im Klartest schicken kann weil er danach sowieso ungültig ist (bei TANs ist die Situation an dieser Stelle fast ähnlich. Da fehlt halt die InTime Fähigkeit) Kennst Du andere Verfahren gier Grüße Andreas
bolton more schrieb: > Habe vergessen, dass jeder Benutzer jederzeit in der Lage sein soll, zu > Beweisen, dass eine einzelne Authentifikation zu seinem Account gehört, > ohne dazu seine Accountdaten preisgeben zu müssen, dass er also für > beliebige Authentifizierungen seine Anonymität aufgeben kann, ohne, dass > das weitere Auswirkungen hat. Vorschlag (aus der hohlen Hand, ohne Gewähr...): * Jeder Benutzer der sich anmeldet, bekommt einen Schlüssel vom Server, mit dem er eigene Daten signieren kann. Jeder der diesen Schlüssel kennt wird sich einloggen können, d.h. der Server-Betreiber muss seinen Benutzern vertrauen, dass die den nicht weitergeben. * Weiterhin generiert er sich selber ein Schlüsselpaar, ggf. sogar für jeden Anmeldevorgang ein neues. Dies behält er für sich selbst. * Der Server generiert eine Zufallszahl, übermittelt die an den Benutzer. Dieser macht zwei Signaturen: Einmal mit dem Schlüssel vom Server, einmal mit seinem privaten Schlüssel. * Das Datenpaket wird an den Server übermittelt, der seine Signatur überprüft und im Erfolgsfall Zugang gewährt. * Der Server kennt den Schlüssel des Benutzers nicht, kann also die zweite Signatur nicht überprüfen und keinem Benutzer zuordnen. * Der Benutzer kann aber später beweisen, dass er den Schlüssel hat, der die zweite Signatur erzeugt hat. Gut? Grüße, Simon
Andreas H. schrieb: > Hashen beim Empfänger ja auch keinen Sinn mehr. Der Sinn dieser Methode liegt darin, dass eine Offenlegung der Auth-DB wenig(er) Schaden anrichtet. Diese Problematik ist auch heute noch relevant. 10000 Passwörter live mitlesen dauert viel länger und ist weit riskanter als mal eben ein File mit 10000 Klartext-Passwörtern abzugreifen und sofort wieder zu verschwinden.
Andreas H. schrieb: > den Zeiten, wo IT-Security noch ein akademisches Steckenpferd von > Promotionsstudenten war. Was meinst du wieviele Webpräsenzen auch heute noch frisch fabriziert werden, mit Sicherheitsverfahren die nicht besser sind als vor 20 Jahren. Wichtig ist das Design, manchmal noch die Funktion, und natürlich die Entwicklungszeit. Und der Seitenblastler darf auch nicht zu teuer sein. Diejenigen, die über die Kriterien der Präsenz entscheiden, und die Termine prügeln, haben Security kaum auf dem Radar, ausser vielleicht bei bekannt sicherheitskritischen Präsenzen wie Banken.
Man speichert bei der Registrierung einen Hash(Passwort und UserID). Bei der Authentifizierung wird clientseitig einen Hash von den der UserID und dem Passwort generiert, zusammen mit dem Unix-Timestamp in Plain und einmal zusammen mit dem Passwort gehashed zum Server geschickt. Dort wird der Hash(UserId und Passwd) kontrolliert und danach ein neuer Hash aus den Hashes (UserId + Passwd) und (Timestamp+Passwd) generiert. Dieser Hash[Hash(UserID+Passwd)+Hash(Timestamp+Passwd)] wird zusammen mit dem Plain Unix-Timestamp in einer DB speichern. Nun könnte man eine bestimmte Authentifizierung ohne Zutun des User (um den Hash vom Timestamp und dem Passwort zubekommen) nicht mehr nachvollzogen werden.
Simon Budig schrieb: > * Der Benutzer kann aber später beweisen, dass er den Schlüssel hat, der > die zweite Signatur erzeugt hat. Und wie überprüft der Server die Gültigkeit ? Wenn er das anhand der zweiten Signatur macht, ist das Verfahren ja nicht mehr annonym, denn die zweite Sig wurde ja zusammen mit der, durch die Serversignatur geprüfte Übertragung, transferiert, ist also zuordenbar. Genau das sollte aber nicht sein :-) Grüße Andreas
Andreas H. schrieb: > Simon Budig schrieb: >> * Der Benutzer kann aber später beweisen, dass er den Schlüssel hat, der >> die zweite Signatur erzeugt hat. > > Und wie überprüft der Server die Gültigkeit ? Die erste Signatur beweist doch, dass der Benutzer den (zwischen allen Benutzern geteilten) Schlüssel erhalten hat. Grüße, Simon
A. K. schrieb: > Der Sinn dieser Methode liegt darin, dass eine Offenlegung der Auth-DB > wenig(er) Schaden anrichtet. Diese Problematik ist auch heute noch > relevant. 10000 Passwörter live mitlesen dauert viel länger und ist weit > riskanter als mal eben ein File mit 10000 Klartext-Passwörtern > abzugreifen und sofort wieder zu verschwinden. Was irgendwann mal zur Shadow-Passworddatei unter Unix führte. Das ist bekannt, ändert aber nichts daran, das Oscar Deinen Key hätte, wenn er nicht vorher schon gehashed worden wäre. Ich hatte nur den Transfer gemeint, nicht das Storage auf dem Server. Da beissen Dich natürlich noch ganz andere Hunde ;-) Grüße Andreas
A. K. schrieb: > Was meinst du wieviele Webpräsenzen auch heute noch frisch fabriziert > werden, mit Sicherheitsverfahren die nicht besser sind als vor 20 > Jahren. Wichtig ist das Design, manchmal noch die Funktion, und > natürlich die Entwicklungszeit. Und der Seitenblastler darf auch nicht > zu teuer sein. > > Diejenigen, die über die Kriterien der Präsenz entscheiden, und die > Termine prügeln, haben Security kaum auf dem Radar, ausser vielleicht > bei bekannt sicherheitskritischen Präsenzen wie Banken. Das beweisen ja auch die diversen erfolgreichen Hacks irgendwelcher Seiten. Aber viel schlimmer finde ich die diversen "Normalanwendungen", die meinen, sich einen Extraport spendieren zu müssen um dann "nach Hause telefonieren" zu müssen. Damit kann man dann die Firmensicherheit auch sehr schnell gegen die Wand fahren. Und solche Lücken werden dann anscheinend auch nur im Rahmen von normalen Produktupdates geschlossen, wenn überhaupt^^ Grüße Andreas
Simon Budig schrieb: > Die erste Signatur beweist doch, dass der Benutzer den (zwischen allen > Benutzern geteilten) Schlüssel erhalten hat. Von "(zwischen allen Benutzern geteilten)" war bisher nicht die Rede. Ok, dann musst Du nur sicherstellen, das zwischen der Challenge und der Response eine große Anzahl anderer "Anmeldungen" passiert sind, damit Deine Antwort nicht mehr per TimeSlot zugeordnet werden kann. Sehr wacklig, oder ? Grüße andreas
Andreas H. schrieb: > A. K. schrieb: >> Auch in simplen passiven Webformularen, in Plaintext >> Browser-Authentifizierung?? Oder FTP? Oder ... > Da hast Du recht. Aber das sind (in meinen Augen) auch nur Relikte aus > den Zeiten, wo IT-Security noch ein akademisches Steckenpferd von > Promotionsstudenten war. Mehr war damals auch nicht notwendig, weil es zum Ehrencodex gehörte, dass man auf einem der wenigen Computer, die damals online erreichbar waren, nichts anstellt. Und für Bankgeschäfte ging man auf die Bank und füllte einen Erlagschein aus.
Andreas H. schrieb: > Simon Budig schrieb: >> Die erste Signatur beweist doch, dass der Benutzer den (zwischen allen >> Benutzern geteilten) Schlüssel erhalten hat. > > Von "(zwischen allen Benutzern geteilten)" war bisher nicht die Rede. > > Ok, dann musst Du nur sicherstellen, das zwischen der Challenge und der > Response eine große Anzahl anderer "Anmeldungen" passiert sind, damit > Deine Antwort nicht mehr per TimeSlot zugeordnet werden kann. > > Sehr wacklig, oder ? So wie ich Simons Vorschlag verstehe, ist das im Grunde auch nur ein "1 Password für alle" Verfahren. Der wensentliche Unterschied: nach der Anmeldung mit dem bekannten Password schickt der Client dem Server eine Zusatz-Information, mit der der Server im Prinzip nichts anfangen kann, die er sich aber trotzdem speichert. Im Falle des Falles kann dann später der Client sagen: Hier das war ich. Bei dieser und jener Operation müsstest du diese Zusatz-Information gespeichert haben. Wenn dem so ist, dann beweist das, dass ich zumindest diese Zusatz-Information kenne. Und da ausser mir keiner diese Info kennt, beweist das, dass ich das war. Um sicherzustellen, dass letzters (ausser mir kennt die keiner) gewährleistet ist, schickt der Server etwas, was der Client mit seinem geheimen Password verschlüsseln muss. D.h. wenn es darum geht, zu beweisen dass er das war, kann man ja von ihm verlangen, dass er darlegt wie er zu dieser am Server überall mitprotokollierten Zusatz-Information gekommen ist.
Andreas H. schrieb: > Von "(zwischen allen Benutzern geteilten)" war bisher nicht die Rede. Ah pardon, das hätte ich expliziter hinschreiben können. > Ok, dann musst Du nur sicherstellen, das zwischen der Challenge und der > Response eine große Anzahl anderer "Anmeldungen" passiert sind, damit > Deine Antwort nicht mehr per TimeSlot zugeordnet werden kann. Nunja, wenn man zum Anfordern der Challnge den Benutzernamen nicht abfragt, dann wäre das auch egal, oder? > Sehr wacklig, oder ? Bestimmt, ich bin kein Krypto-Experte. Und ich verstehe auch nicht, weshalb der TE diese Anforderungen hat :-) Viele Grüße, Simon
Christian Rademaker schrieb: > Man speichert bei der Registrierung einen Hash(Passwort und UserID). > > Bei der Authentifizierung wird clientseitig einen Hash von den der > UserID und dem Passwort generiert, zusammen mit dem Unix-Timestamp in > Plain und einmal zusammen mit dem Passwort gehashed zum Server > geschickt. Dort wird der Hash(UserId und Passwd) kontrolliert und danach > ein neuer Hash aus den Hashes (UserId + Passwd) und (Timestamp+Passwd) > generiert. Dieser Hash[Hash(UserID+Passwd)+Hash(Timestamp+Passwd)] wird > zusammen mit dem Plain Unix-Timestamp in einer DB speichern. > > Nun könnte man eine bestimmte Authentifizierung ohne Zutun des User (um > den Hash vom Timestamp und dem Passwort zubekommen) nicht mehr > nachvollzogen werden. ??? Ich kann Dir nicht folgen. Grüße Andreas
Karl Heinz Buchegger schrieb: > Im Falle des Falles kann dann später der Client sagen: Hier das war ich. > Bei dieser und jener Operation müsstest du diese Zusatz-Information > gespeichert haben. Wenn dem so ist, dann beweist das, dass ich zumindest > diese Zusatz-Information kenne. Und da ausser mir keiner diese Info > kennt, beweist das, dass ich das war. Dann muss der Server aber eben wieder diese Sicherheitsinformation mit dem Benutzer in Verbindung bringen können. Aber genau das sollte ja ausgeschlossen sein. Es geht mMn eben nicht, so wie der TE das gernew hätte :/ Grüße Andreas
Andreas H. schrieb: > Dann muss der Server aber eben wieder diese Sicherheitsinformation mit > dem Benutzer in Verbindung bringen können. Aber genau das sollte ja > ausgeschlossen sein. Es geht aber nur mit Zutun (und Zustimmung) des entsprechenden Benutzers. Und das ist doch der Punkt, oder? Grüße, Simon
Simon Budig schrieb: > Nunja, wenn man zum Anfordern der Challnge den Benutzernamen nicht > abfragt, dann wäre das auch egal, oder? > Ja, dann kannst Du Dir auch gleich die ganze Registrierung sparen und mein oben vorgeschlagenes Global-PW auf die WEB Site schreiben. Erheblich weniger Aufwand bei kaum verringerten Risk :-D >> Sehr wacklig, oder ? > > Bestimmt, ich bin kein Krypto-Experte. Und ich verstehe auch nicht, > weshalb der TE diese Anforderungen hat :-) Ich auch nicht. Und ich halte die Forderungen auch nicht für zusammen erfüllbar (s. mein Post viel weiter oben). Aber man lernt ja nie aus :-D Grüße Andreas
Simon Budig schrieb: > Es geht aber nur mit Zutun (und Zustimmung) des entsprechenden > Benutzers. Und das ist doch der Punkt, oder? Nein. Es geht um Authentifizierung so, dass der Server weiss, dass Du "rein darfst" aber nicht wer Du bist", erschwert durch die Forderung, dass Du auch Rechte auf bestimmte Sachen geltend machen kannst. Meiner Meinung nach ein nicht lösbares Problem. Grüße Andreas
Andreas H. schrieb: > Nein. Es geht um Authentifizierung so, dass der Server weiss, dass Du > "rein darfst" aber nicht wer Du bist", erschwert durch die Forderung, > dass Du auch Rechte auf bestimmte Sachen geltend machen kannst. Hmm, vermutlich reden wir aneinander vorbei. Das "darf rein" ist geklärt dadurch, dass der Benutzer irgendwann den zwischen allen Benutzern geteilten Schlüssel erhalten hat. Damit ist eine Sperrung von Accounts (wie schon vom TE erkannt) unmöglich, im Prinzip kann aber auch ein Benutzer weiteren Benutzern den Zugang ermöglichen - was bisher noch nicht KO-Kriterium war. Dann fordert der TE, dass "jeder Benutzer jederzeit in der Lage sein soll, zu Beweisen, dass eine einzelne Authentifikation zu seinem Account gehört, ohne dazu seine Accountdaten preisgeben zu müssen, dass er also für beliebige Authentifizierungen seine Anonymität aufgeben kann, ohne, dass das weitere Auswirkungen hat.". Ok, mein Verfahren deckt das wohl noch nicht 100%ig ab, mit einer leichten Modifikation gehts aber: Der Benutzer könnte aber für jeden Anmeldevorgang einen neuen Schlüssel generieren, und dann mit diesem Schlüssel die Zufallszahl signieren. Wenn er dann später beweisen will, dass die vom Server mit einer gegebenen Zufallszahl verknüpften Aktionen von ihm stammen, dann legt er den bei sich gespeicherten privaten Schlüssel dem Serverbetreiber vor. Damit kann der dann überprüfen, dass die damals gespeicherte Signatur wirklich mit diesem Schlüssel aus dem Besitz von einem konkreten Benutzer stammt. (Nachtrag: Sinn des jedesmal neu generierten Schlüssel ist ein Schutz vor Offenlegung seiner anderen Aktionen) > Meiner Meinung nach ein nicht lösbares Problem. Och, sehe ich erstmal nicht. Grüße, Simon
Andreas H. schrieb: > Simon Budig schrieb: >> Es geht aber nur mit Zutun (und Zustimmung) des entsprechenden >> Benutzers. Und das ist doch der Punkt, oder? > > Nein. Es geht um Authentifizierung so, dass der Server weiss, dass Du > "rein darfst" aber nicht wer Du bist", erschwert durch die Forderung, > dass Du auch Rechte auf bestimmte Sachen geltend machen kannst. Hmm. Das hab ich dann vom TO anders verstanden. Das geht dann meiner Meinung nach nur noch, indem sich der anonyme Benutzer, obowhl er bereits anonym angemeldet ist, ein weiteres mal anmeldet, wobei er dann seine Identität preisgeben muss. Will er das nicht mehr, kann er sich wieder ausloggen. Ist natürlich problematisch, denn durch eine Analyse der Verbindungsdaten kann man im Nachhinein mit einer gewissen Wahrscheinlichkeit rekonsttuieren, wer es wohl gewesen sein wird.
Simon Budig schrieb: > Wenn er dann später beweisen will, dass die vom Server mit einer > gegebenen Zufallszahl verknüpften Aktionen von ihm stammen, Lies noch mal nach, was der TO von sich gegeben hat. Ich denke Andreas hat recht: Darum geht es nicht. Ein Benutzer will sich anonym einloggen um sich Daten zu saugen. Aber er will auch auf dem Server etwas ausdrucken, wofür er sich beim Server identifizieren muss, denn drucken darf nicht jeder.
Also es gibt solche Verfahren, man verwendet die beispielsweise für anonymes Geld. Du brauchst ein Kryptoverfahren mit dem ein Datenpaket verschlüsselt werden kann, dann von jemand anderen signiert, und wieder entschlüsselt werden kann. Solche Verfahren gibt es. (frag mich nicht wie das im Detail geht) Damit geht es sogar direkt. Es gibt aber auch noch die Luxusversion bei der Du in die Kennung was rein schreiben kann. Jetzt erstellst Du 1000 Datenpakete, welche Du später als "Kennung" für den Zugriff verwenden würdest, da kann zum Beispiel drin stehen wie viel Du machen darfst. Du verschlüsselst alle 1000 mit zufälligen Schlüsseln und schickst sie an den Server. Der Server wählt nun 999 zufällig davon aus, und fragt Dich nach den Schlüsseln für die. Er überprüft alle 999 auf Korrektheit und signiert die einzig noch verschlüsselte Kennung. Du nimmt die Kennung, entschlüsselst die und kannst Dich damit einloggen.
So, vor der nächsten Laborrunde (ja, arbeiten muss man ja auch noch ;-) mal ein kurzes Beispiel wo man so etwas brauchen könnte. Etwas konstruiert, sorry. Aufgabe: "Meckerbox" in einer Firma Jeder Mitarbeiter kann hier wie z.B. in unserem Forum posten. Insbesondere will die GL, dass die MA auch mal Luft ablassen können, für Sachen die sie nerven und auch mal über ihre Vorgesetzen herziehen. Zweck ist es, die Mitarbeiterzufriedenheit und damit die Produktqualität zu erhöhen, weil die GL natürlich mitliest und hofft so neue Erkenntnisse, sozusagen Teeküchengerüchte, zu gewinnen. Dieses Mitlesen wird den MAs auch vorher mitgeteilt. Der GL ist klar, dass die Meckerbox von den MA nur dann angenommen wird, wenn sichergestellt werden kann, dass es absolut anonym ist. Nicht-MAs soll kein Zugang gewährt werden, man will sich ja nicht öffentlich bloss stellen oder Headhuntern schon mal die unzufriedenen MAs frei Haus liefern. Dazu wird ein Board gebaut, das vom INet zugänglich (SSL only) ist, damit die MAs es ausserhalb der Firma benutzen können um MA-Identifizierung über IP checks zu verhindern. Registrieren können sich die MA nur über das Firmenintranet. Dazu wird zur Identifizierung das normale Intranet-ID/PW Pärchen benutzt. Der registrierte Benutzer erhält dann seinen "Boxpass" , mit dem er das Meckerboard benutzen kann. Das Board ist inhaltlich ähnlich wie das Mikrocontroller.net Forum aufgebaut. Man kann aber eben nur lesen/schreiben, wenn man sich mit seinem "Boxpass" eingeloggt hat. Einen Benutzernamen kann man sich dann beliebig geben und auch nachträglich ändern. Natürlich soll ein MA seine Beiträge auch nachträglich editieren und löschen können OHNE einen Admin zu brauchen, der dann ja Kenntniss des MA erlangen würde. Beachte: Der MA darf nur SEINE Beiträge ändern/löschen können. Die Beiträge anderer MAs sind natürlich nur lesbar. So, nun haut rein :-) Grüße Andreas P.S: Willkürliche MA Anzahl 15000 MA (um hier mal eine "große" Zahl vorzugeben)
Christian Berger schrieb: > Jetzt erstellst Du 1000 Datenpakete, welche Du später als "Kennung" für > den Zugriff verwenden würdest, da kann zum Beispiel drin stehen wie viel > Du machen darfst. > Du verschlüsselst alle 1000 mit zufälligen Schlüsseln und schickst sie > an den Server. > Der Server wählt nun 999 zufällig davon aus, und fragt Dich nach den > Schlüsseln für die. > Er überprüft alle 999 auf Korrektheit und signiert die einzig noch > verschlüsselte Kennung. > Du nimmt die Kennung, entschlüsselst die und kannst Dich damit > einloggen. Super, das mach ich auch. Genau wie Du es beschreibst. Identifizieren musste ich mich ja nie. Ach ja, Registrieren auch nicht. Da war doch was ... Und mit Registrierung ? Der Server legt ordentlich alle 1000 Pakete unter menem Account ab, denn die muss er mir ja zurückschicken. Nur mir !!! Und dann wie gehabt. Obwohl, dann kann der Server ja doch den User zu den Packeten zuordnen^^ Grüße Andreas
Ok, nehmen wir die Meckerbox. :)
(Ich zwischendurch an ein System gedacht, in dem man z.B. anonym Prior
Art hinterlegen kann und später sagen kann "Hier, das war wirklich meine
Idee").
Vorweg - wir müssen erstmal davon ausgehen, dass der Netzwerkverkehr
nicht getrackt wird. Welche Pakete wann wie laufen ist so oder so ein
Leak, das ist aber nicht per se ein kryptographisches Problem.
Bei der Meckerbox sehe hier bisher kein Rechte-Management außer dem
Zugriff auf den Server selber. Das ist in der Tat haarig, weil nach
"meinem" Schema die Mitarbeiter ihre im Firmennetz verteilten
Credentials duplizieren könnten, so dass externe ebenfalls Zugriff auf
den Server bekommen könnten. Das sehe ich als Schwachpunkt bzw. habe da
keine Idee dafür.
Aber der Rest müsste doch funktionieren. Der Meckerer meldet sich mit
den für-alle-gleichen Credentials beim Server an (ob nun als Signatur
bei einer Transaktion oder einmal für die ganze Session ist quasi egal)
und ist nun "anonymous" auf dem Server.
Er legt ein neues Meckerticket an. Der Server liefert dazu eine
Zufallszahl, die der Meckerer mit einem frisch erzeugten Schlüssel
signiert. Den Schlüssel behält er für sich. Der Server speichert das
Ticket, Zufallszahl zu diesem Ticket und die Signatur.
Nun will der Meckerer in einer weiteren Session das Ticket ändern. Er
hat sich wieder als "anonymous" beim Server authentifiziert (s.o). Er
ändert den Text und übermittelt nun dem Server seinen vorher erzeugten
privaten Schlüssel (der natürlich keine Namen etc. enthält).
Der Server hat nun den privaten Schlüssel, der in der Session davor
verwendet wurde um die Signatur zu erzeugen. Er kann die Zufallszahl nun
selber signieren und so also die Signatur verifizieren. Er weiß nun,
dass der Autor derselbe ist, und ändert den Text des Tickets. Damit ist
der Schlüssel natürlich verbrannt, und damit man in Zukunft das Ticket
erneut ändern kann, wird die neue Version nach dem gleichen Schema mit
einer neuen Zufallszahl versehen, die mit einem vom Nutzer neu erzeugten
Schlüssel signiert wird.
Wo ist denn mein Denkfehler? Ok, das mit dem Weitergeben der
Server-Zugangsdaten das sehe ich. Aber sonst?
Nur wenn es tatsächlich um ein System gehen sollte, bei dem
unterschiedliche (anonyme) Nutzer verschiedene Privilegien ("Zugriff auf
Drucker") haben sollen, dann sehe ich da auch ein Problem. Es sei denn
man verteilt für jede ressource einen eigenen
"anonymous-drucker"-Zugang.
Grüße,
Simon
Simon Budig schrieb: > Wo ist denn mein Denkfehler? Das es nicht zur Spec passt. Um auf die Meckerbox zu kommen, müssen sich die MAs aus dem INTRANET mit ihrem normalen MA-UID/PW anmelden. Daraufhin erhalten sie den "Boxpass" mit dem sie dann in die Box einloggen können. Dieser Boxpass ist aber nicht für alle gleich, sondern individuell für jeden MA. Vorstellbar wäre jetzt (oder eben auch nicht), dass der MA mit der passenden Menge Magie diesen Boxpass so modifiziert, dass der Server nachher eben nur feststellen kann, das es ein gültiger Boxpass ist, aber nicht welchem MA der dazugehörige Original-Boxpass ausgestellt wurde. Mit dem modifizierten Boxpass kann sich der MA dann immer wieder anonym anmelden und dann auchseine Beiträge bearbeiten. Ticketsystem hatte ich nicht spezifiziert :p Aber es kriegt langsam formen. Vielleicht geht das ja doch^^ So, Feierabend. Bis morgen o/^ Grüße Andreas
Andreas H. schrieb: > Simon Budig schrieb: >> Wo ist denn mein Denkfehler? > > Das es nicht zur Spec passt. > > Um auf die Meckerbox zu kommen, müssen sich die MAs aus dem INTRANET mit > ihrem normalen MA-UID/PW anmelden. Daraufhin erhalten sie den "Boxpass" > mit dem sie dann in die Box einloggen können. Dieser Boxpass ist aber > nicht für alle gleich, sondern individuell für jeden MA. Warum? Warum kann der nicht für alle gleich sein? "Hier ist der Meckerzugang. Wenn Du uns nicht vertraust, bist Du eingeladen, die Zugangsdaten mit anderen Mitarbeitern abzugleichen." Grüße, Simon
Simon Budig schrieb: > Andreas H. schrieb: >> Simon Budig schrieb: >>> Wo ist denn mein Denkfehler? >> >> Das es nicht zur Spec passt. >> >> Um auf die Meckerbox zu kommen, müssen sich die MAs aus dem INTRANET mit >> ihrem normalen MA-UID/PW anmelden. Daraufhin erhalten sie den "Boxpass" >> mit dem sie dann in die Box einloggen können. Dieser Boxpass ist aber >> nicht für alle gleich, sondern individuell für jeden MA. > > Warum? Warum kann der nicht für alle gleich sein? Wegen dem hier > Einen Benutzernamen kann man sich dann beliebig geben > und auch nachträglich ändern. > > Natürlich soll ein MA seine Beiträge auch nachträglich editieren > und löschen können OHNE einen Admin zu brauchen, der dann ja > Kenntniss des MA erlangen würde. und natürlich soll das von jedem beliebigen PC im Intrenet gehen und nicht nur auf dem PC auf dem ich mich zuletzt eingeloggt habe. D.h. irgendeine Kennung, die der Client beim Login präsentieren muss und die er sich aus der letzten Verbindung gemerkt hat, ist nicht. Was ist, wenn mein PC neu aufgesetzt werden muss? Wo kriege ich dann diese sessionübergreifende Kennung her? gleichzeitig anonym und doch nicht anonym ist für mich ein Widerspruch in sich selbst.
Ok, ich will meinen Ansatz nicht mit Gewalt verteidigen, aber... :) Karl Heinz Buchegger schrieb: >> Einen Benutzernamen kann man sich dann beliebig geben >> und auch nachträglich ändern. (Das lässt sich sicherlich auch noch organisieren :) >> Natürlich soll ein MA seine Beiträge auch nachträglich editieren >> und löschen können OHNE einen Admin zu brauchen, der dann ja >> Kenntniss des MA erlangen würde. Ok, das habe ich ja oben ausgeführt. > und natürlich soll das von jedem beliebigen PC im Intrenet gehen und > nicht nur auf dem PC auf dem ich mich zuletzt eingeloggt habe. D.h. > irgendeine Kennung, die der Client beim Login präsentieren muss und die > er sich aus der letzten Verbindung gemerkt hat, ist nicht. Was ist, wenn > mein PC neu aufgesetzt werden muss? Wo kriege ich dann diese > sessionübergreifende Kennung her? Das sind aber Forderungen die Du jetzt neu stellst. Intranet geht ja so oder so nicht, weil da ja die Aktivitäten auf dem Server zeitlich mit dem Netzwerkverkehr zur Workstation des Mitarbeiters korrelliert werden könnten. Ansonsten musst Du die Schlüsseldaten halt irgendwie auf einem USB-Stick mitschleppen. Sicher, das ist unbequem, aber Kryptographie ist nie einfach und bequem... > gleichzeitig anonym und doch nicht anonym ist für mich ein Widerspruch > in sich selbst. Naja, Du scheinst sehr davon auszugehen, dass man für Aktivitäten auf dem Server immer einen klassischen Account mit Loginnamen und Passwort braucht. Wenn man das eher in der Richtung betrachtet, dass jeder mit dem one-for-all-Passwort auf dem Server Ressourcen anlegen kann, die jeweils an ein Geheimnis gekoppelt sind welches man kennen muss um sie ändern zu können, dann scheint mir das zumindest für das Meckerbox-Beispiel lösbar zu sein. Ob das dem TE hilft ist natürlich eine andere Frage. Das müsste aber er beantworten :) Viele Grüße, Simon
Das Meckerboxmodell gefällt mir sehr gut, ich denke, es vereinfacht und konkretisiert das Problem. Sagen wir mal, man will die Box gegen Spam oder Beleidigungen schützen, da die Geschäftsleitung die Box sonst abschaffen würde, daher ist es im Interesse der Mehrheit der Mitarbeiter, das zu verhindern. Deshalb a) dürfen nur Mitarbeiter Zugriff haben Simon Budig schrieb: > Bei der Meckerbox sehe hier bisher kein Rechte-Management außer dem > Zugriff auf den Server selber. Das ist in der Tat haarig, weil nach > "meinem" Schema die Mitarbeiter ihre im Firmennetz verteilten > Credentials duplizieren könnten, so dass externe ebenfalls Zugriff auf > den Server bekommen könnten. Das sehe ich als Schwachpunkt bzw. habe da > keine Idee dafür. b) darf kein Mitarbeiter die Möglichkeit haben, externen Leuten Zugriff zu verschaffen, ohne seine persönlichen Accountdaten/Schlüssel weiterzugeben Die Mitarbeiter wollen nun die Möglichkeit haben, im Falle einer Beleidigung kollektiv herausfinden zu können, wer die Beleidigung eingeworfen hat. Dazu muss jeder Mitarbeiter glaubhaft versichern können, dass er die Beleidigung selber nicht geschrieben hat, wobei er natürlich in Kauf nehmen muss, seine Anonymität fallen zu lassen. Wenn das nun jeder bis auf den Schuldigen macht, kann dieser identifiziert und entlassen werden. Mitarbeiter, die sich weigern, können ebenfalls entlassen werden. Prinzipbedingt kann mathematisch natürlich von niemandem die Anonymität aufgehoben werden, außer, er macht das freiwillig/wird zur Herausgabe gezwungen. Damit das funktioniert, muss b) erfüllt sein, sodass jeder Einwurf einem Account per Ausschlussverfahren zugeordnet werden kann, also kein externer ohne Mitarbeiteraccount die Beleidigung einwerfen kann. Beiträge editieren/hinzufügen ist nicht notwendig bzw lässt sich immer einfach emulieren, indem jeder Mitarbeiter, der etwas schreiben möchte, in die Box einen öffentlichen Schlüssel wirft, über den jeder die Signatur aller weiteren Beiträge, die dann zB auf ein Flipchart nebendran geschrieben werden können, überprüfen kann. Geheim muss der Inhalt der Box nicht sein, das würde auch nicht gehen, denn jeder Mitarbeiter kann ja prinzipiell immer unbemerkt veröffentlichen, was er lesen kann. Das Problem ist erstmal unabhängig vom Netzwerk (bzgl Verfolgbarkeit anhand Adressen oder Zeiten, das kann das Netzwerk ja garantieren, dafür gibt es ja genügend existierende Methoden) Christian Berger schrieb: > Du brauchst ein Kryptoverfahren mit dem ein Datenpaket verschlüsselt > werden kann, dann von jemand anderen signiert, und wieder entschlüsselt > werden kann. Solche Verfahren gibt es. (frag mich nicht wie das im > Detail geht) Das hört sich verdammt gut an, verstehe ich das richtig, der signierende kann nicht feststellen, was er da signiert hat und die Signatur überlebt die Entschlüsselung? Wenn ich jemandem jetzt anonym Rechte vergeben möchte, könnte ich das über die 1000 Pakete machen, um sicherzugehen, dass der Nutzer sehr wahrscheinlich nicht bescheißen will, da ich ihm ja quasi einen Blankoscheck ausstelle. Ich verschaffe mir also Gewissheit, dass der Scheck, den ich letztendlich unterschreibe, genauso mit Rechten beschriftet ist wie die 999 anderen. Clever :) Auf die Meckerbox angewendet bräuchte man noch nichtmal verschiedene Rechte, ein einmal Ticket würde erstmal ausreichen. Jeder Mitarbeiter bekommt eins (die Mitarbeiter schreiben sich auf ein Blatt Papier den Hash eines zufällig gewählten Codes konkateniert mit ihrem Namen und lassen diesen unterschreiben, wobei während der Unterschrift die Geschäftsleitung diesen nicht zu Gesicht bekommt. Jeder MA kann nun später was in die Box einwerfen, authentifiziert sich mit dem unterschriebenen Hash und kann auch jederzeit nachweisen, was er eingeworfen hat und was nicht, in dem er den zufällig gewählten Code veröffentlicht. Jeder kann nun den Namen + Code hashen und der MA kann mittels des unterschriebenen Hashes beweisen, was er geschrieben hat und was nicht. Das wäre genau die Magie, die notwendig ist, also: wie kann man was verschlüsseltes signieren, sodass die Signatur beim entschlüsseln erhalten bleibt? Du schriebst, du wüsstest nicht im Detail, wie das ginge, kannst du vielleicht ein Stichwort oÄ nennen? PS: wie gesagt, weder bin ich eine Geschäftsleitung, noch will ich jemanden feuern, der anonym bleiben möchte, es geht mir nur um die Magie der Mathematik :) Hatte das aber in der Tat mal, eine elektronische Meckerbox in der Firma, wobei man sich aber anmelden musste und darauf vertrauen musste, dass es so implementiert ist, dass es niemand so leicht zurückverfolgen kann. Vielen Dank an alle, die sich so aktiv beteiligen und auch danke für die Hinweise, die mir geholfen haben, genauer zu beschreiben, was ich eigentlich genau möchte.
Nachtrag: was sich also an meinen ursprünglichen Spezifikationen von ganz oben ändern muss: Statt beweisen muss man abstreiten können, etwas geschrieben zu haben. zB in dem man jedem erlaubt, nachzuvollziehen, was man insgesamt geschrieben hat. Ich denke, der schwierigere Part ist Anonymität von Tickets für einmal Nachricht in Box einwerfen. Abstreitbarkeit ergibt sich dann automatisch, in dem jeder seine Tickets vorlegt.
Ich wuerd einen Server bei jemandem unabhaengigen, dem alle Vertrauen aufstellen. Vielleicht gibt's ja so jemanden. Also jemanden ohne Ehrgeiz auf den Chefposten. Oder ein externes mailaccount, worauf die Mitarbeiter posten koennen, von zuhause aus natuerlich.
Um sich vor Verkehrsanalyse zu schützen gibt es Tor oder Mix-Kaskaden. Um sicherzustellen, dass man aus einer bestimmten Gruppe kommt, gibt es anonyme Berechtigungsnachweise oder Ringsignaturen. > Ringsignaturen bieten besondere Möglichkeiten bei der Si- > gnatur von Nachrichten. Mit einer Ringsignatur existieren > mehrere mögliche Unterzeichner, von denen mindestens ei- > ner die Unterschrift erzeugt hat. Es ist nicht möglich, un- > ter den Unterzeichnern denjenigen zu nden, der die Un- > terschrift tatsächlich erzeugt hat. Die Menge der möglichen > Erzeuger der Unterschrift ist Bestandteil der Signatur und > es ist gewährleistet, dass der tatsächliche Unterzeichner sich > darin befindet. http://jorsoft.de/uni/ringsignatures.pdf Ob Ringsignaturen auch mit 15000 MA funktionieren weiß ich nicht (Performanz!)
Ok, mit der Anforderung dass bewiesen werden soll, dass etwas nicht
von einem kommt ist mein System dann endgültig überfordert :)
Mir fallen dafür so Konzepte wie das "ewige Logfile" ein, im Prinzip
eine Liste von Hashes, die jeweils einen neuen Hashwert aus dem alten
Hashwert plus den neuen Daten berechnen.
Bis man das aber auf diese Anforderungen zurechtmassiert hat muss man
ein bischen Hirnschmalz investieren...
Und es hilft natürlich nicht gegen multiple Persönlichkeiten.
Viele Grüße,
Simon
Karl Heinz Buchegger schrieb: > gleichzeitig anonym und doch nicht anonym ist für mich ein Widerspruch > in sich selbst. Lies den Thread :-) Genau um DIESES Problem gehts doch. Die Meckerbox ist nur eine Beispielanwendung, damit man sich die Anforderungen besser vorstellen kann. Grüße Andreas
Christian Rademaker schrieb: > Man speichert bei der Registrierung einen Hash(Passwort und UserID). > > Bei der Authentifizierung wird clientseitig einen Hash von den der > UserID und dem Passwort generiert, zusammen mit dem Unix-Timestamp in > Plain und einmal zusammen mit dem Passwort gehashed zum Server > geschickt. Dort wird der Hash(UserId und Passwd) kontrolliert und danach > ein neuer Hash aus den Hashes (UserId + Passwd) und (Timestamp+Passwd) > generiert. Dieser Hash[Hash(UserID+Passwd)+Hash(Timestamp+Passwd)] wird > zusammen mit dem Plain Unix-Timestamp in einer DB speichern. > > Nun könnte man eine bestimmte Authentifizierung ohne Zutun des User (um > den Hash vom Timestamp und dem Passwort zubekommen) nicht mehr > nachvollzogen werden. Ich glaube ich habs noch nicht ganz durchblickt oder es fehlt irgendwas an der Erklärung. Es ist doch wumpe ob ich über einen unverschlüsselten Kanal das Klartextpasswort sende oder den Hash?
Was mir spontan einfiele ist, ein personalisierter Login, auf den Folgend dann ein 2 h gültiges Cookie (ohne Vermerk, von wem das ist) gesetzt wird. Edit: Problem dabei ist natürlich, dass der Benutzer dem Server vertrauen muss und das soll, wenn ich das richtig verstanden habe, nicht notwendig sein ...
Andreas H. schrieb: > Eigentlich nicht. Es wird immer auf der Senderseite gehashed. Nun wirklich nicht. Simples Gegenbeispiel: 99%+ aller Webseiten. Andreas H. schrieb: > Denn wenn > der legendäre Oscar per Mitm-Attack das Klartext PW hat, macht das > Hashen beim Empfänger ja auch keinen Sinn mehr. Toll, wenn er den Hash kennt, kann er eben diesen übermitteln, das Problem bleibt. Dafür wurden sichere Verbindungen erfunden. Andreas H. schrieb: > Das ist > bekannt, ändert aber nichts daran, das Oscar Deinen Key hätte, wenn er > nicht vorher schon gehashed worden wäre. Toll, so hat er den Hash, den er einfach an den Server übermittelt. Durch das clientseitige hashen hast du noch dazu das gleiche Problem, wie wenn du die Passwörter plain in der DB stehen hast: Jemand, der es schafft, die DB auszulesen, weis genau, was er übermitteln muss, um angenommen zu werden. Nein, das Bilden des Hashes macht nur auf dem Server Sinn.
vn nn schrieb: > Toll, so hat er den Hash, den er einfach an den Server übermittelt. > Durch das clientseitige hashen hast du noch dazu das gleiche Problem, > wie wenn du die Passwörter plain in der DB stehen hast: Jemand, der es > schafft, die DB auszulesen, weis genau, was er übermitteln muss, um > angenommen zu werden. Made my day. Du machst hoffentlich KEINE Sicherheitssoftware, oder ? Natürlich macht das Übertragen von gehashten Keys nur dann Sinn, wenn gechallenged wurde. Und dann wird ja nicht mehr der Hash des Keys, sondern der Hash (Challenge-token, hash-key) gesendet. Diesen Hash kann Oscar aber nach dem originalen Transfer nicht mehr gebrauchen, weil das Challenge-token jedes mal neu erzeugt wird. Aber DU wirst jetzt sicher argumentieren, dass Oscar ja das Challenge-Token auch gesehen hat, also aus dem Hash ja theoretisch den gehashten Key zurückrechnen kann und dann jede neue Challenge korrekt beantworten kann... ... Also vorausgesetzt er hätte einen Quantencomputer^^ Lies Dir bitte mal durch, wie aktuelle Authentifizierungsverfahren funktionieren, danke :-) Grüße Andreas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.