Kryptografie: Anonyme Accounts möglich?

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

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

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

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