software token

[cr]

Hallo zusammen,

da ih mich ab und zu von fremden rechnern in mein cms einloggen muss, würde ich da sehr gern noch als sicherheitskomponente ne art software token einführen...

gibts da ne möglichkeit sowas selbst zu programmieren oder habt ihr ne günstige gute software, die man in php nutzen kann?

danke für jeden tip!

cr

[Christoph Jeschke]

Guten Tag,

da ih mich ab und zu von fremden rechnern in mein cms einloggen muss, würde ich
da sehr gern noch als sicherheitskomponente ne art software token einführen...

Was genau soll dieses Softwaretoken denn genau können, bzw. welches Sicherheitsproblem soll die Einführung eines solchen Tokens lösen?

Gruß
Christoph Jeschke

[cr]

Guten Tag,

hallo

Was genau soll dieses Softwaretoken denn genau können, bzw. welches Sicherheitsproblem soll die Einführung eines solchen Tokens lösen?

er soll einfach neben benutzer und passwort eine variable sich ändernde 3. sicherheitskennung abfragen. da ich nicht weiß ob jemand mein pwd oder benutzername mitloggt, könnte ich dieses problem soo umgehen...

usb ist eine variante, jedoch benötige ich zwingend eine ungebundene variante, da ich nicht überall (z.b. im geschäft) usb sticks nutzen kann..

grüße

cr

[Alexander (HH)]

Moin Moin!

»» Was genau soll dieses Softwaretoken denn genau können, bzw. welches Sicherheitsproblem soll die Einführung eines solchen Tokens lösen?

er soll einfach neben benutzer und passwort eine variable sich ändernde 3. sicherheitskennung abfragen. da ich nicht weiß ob jemand mein pwd oder benutzername mitloggt, könnte ich dieses problem soo umgehen...

Nein, kannst Du nicht. Der fremde Rechner ist vollständig kompromittiert, ebenso alle Router, Proxys und Firewalls, die Dir von dort bis zu Deinem Server im Weg stehen. Keylogger gehört sowieso dazu, und Dein Software-Token-Programm wird natürlich in einen versteckten Bereich zur späteren Analyse kopiert. Der gesamte Netzwerk-Traffic wird aufgezeichnet.

usb ist eine variante, jedoch benötige ich zwingend eine ungebundene variante, da ich nicht überall (z.b. im geschäft) usb sticks nutzen kann..

Wie willst Du dann ein SW-Token implementieren, wenn Du keine SW ausführen kannst? Willst Du den Token-Generator aus dem WWW herunterladen? Wo der Angreifer die Software mal eben ganz entspannt am Proxy kopieren kann?

Das funktioniert so nicht.

Vertraue keinen fremden Rechnern, vertraue keinen fremden Netzen, und vor allem: Vertraue nicht in Deine Fähigkeiten, angriffssichere Software zu schreiben. Damit sind schon Leute gescheitert, die das jahrelang geübt haben (und natürlich Amateure).

Alexander

[cr]

Moin Moin!

moin moin,

ne da hast du mich falsch verstanden...ich meinte eher dass ich den software token bzw die software auf dem handy etc nutze...d.h. auf einem gerät welches ich ständig dabei habe, was aber nichts mit dem pc mit welchem ich auf den geschützten bereuch zugreife, auch nur einen milimeter verbunden ist.

auf diesem gerät soll eine rechnung durchgeführt werden, welche ich iwie (wie auch immer, danach suche ich ja gerade) auch auf dem server getätigt wird und dann durch meine eingabe verglichen wird.

jetzt verständlicher?

dgrüße

[Alexander (HH)]

Moin Moin!

[...] ich meinte eher dass ich den software token bzw die software auf dem handy etc nutze...d.h. auf einem gerät welches ich ständig dabei habe, was aber nichts mit dem pc [...] verbunden ist. [...] auf diesem gerät soll eine rechnung durchgeführt werden, welche ich iwie (wie auch immer, danach suche ich ja gerade) auch auf dem server getätigt wird und dann durch meine eingabe verglichen wird.

jetzt verständlicher?

Ja. Du beschreibst einen Hardware-Token.

Die Berechnungen sind alles andere als trivial, denn genau die schützt sich ja. Z.B. wäre MD5 über Datum und Uhrzeit reichlich dumm, denn dass kann man schon fast mit Bleistift und Papier knacken. Die Hardware-Tokens haben eine Seriennummer, eine eingebaute Uhr, und sehr, sehr wahrscheinlich auch noch einen Zufallsgenerator eingebaut. Daraus wird der angezeigte Schlüssel berechnet, bei den "großen" Modellen wird auch noch die eingegebene PIN mit "verwurstet", bevor ein Schlüssel ausgegeben wird.

Der dazu gehörende Server (ab hier kenne ich nur die RSA-Implementierung mit einfachem HW-Token) wird mit dem Token synchronisiert, dazu braucht man die Seriennummer und zwei aufeinander folgende Schlüsselwerte. Ab dann kann der Server allein aufgrund der verstrichenen Zeit für jeden weiteren Schlüssel sagen, ob der vom Token generiert wurde oder nicht. Das bedeutet nicht notwendigerweise, dass der Server die Schlüssel vorhersagen kann, aber er kann den Schlüssel mit der vergangenen Zeit und den bisherigen Schlüsseln zusammenrechnen und sagen, ob das Ergebnis paßt oder nicht. Gleichzeitig wird die Gangungenauigkeit der Token-Uhr berücksichtigt. Loggt man sich zu lange nicht ein, kann es passieren, dass Token-Uhr und Server-Uhr zu weit auseinander laufen und der Token vom Service-Techniker an der Hotline durch zwei aufeinander folgende Schlüsselwerte neu mit dem Server synchronisiert werden muß.

Das alles mathematisch so stabil zu bekommen, dass einerseits niemand (zu oft) unberechtigt ausgesperrt wird, andererseits aber auch mit an Sicherheit grenzender Wahrscheinlichkeit niemand unberechtigt herein gelassen wird, ist die große Kunst und das entscheidende Know-How von RSA und anderen.

Ohne exzellente Kenntnisse im Bereich Verschlüsselung stehen die Chancen sehr schlecht, ein sicher genug funktionierendes System selbst zu bauen.

Alexander

[Christoph Jeschke]

Guten Tag,

er soll einfach neben benutzer und passwort eine variable sich ändernde 3.
sicherheitskennung abfragen. da ich nicht weiß ob jemand mein pwd oder
benutzername mitloggt, könnte ich dieses problem soo umgehen...

Genügend Feedback, warum das keine so gute Idee ist, hast du nun ja bekommen. Ich sehe das im Übrigen genauso.

Da ich aber die Idee prinzipiell interessant finde, überlegte ich folgende Vorgehensweise:
1. Ich schreibe ein Skript, welches nach dessen Aufruf ein Einmalpasswort an mein Mobiltelefon schickt, egal ob per SMS, E-Mail oder E-Mail über SMS. Das Einmalpasswort sollte dabei recht stark sein, denn daran hängt in einer feindlichen Umgebung nun der eigentliche Schutz.
2. Das Skript schreibt das Passwort in eine Datei (oder Datenbank).
3. Beim Login in meine eigentliche Applikation muss nun nicht nur das Applikationspasswort, sondern auch das Einmalpasswort korrekt angegeben werden.
4. Das Einmalpasswort wird von dem System / aus der Datenbank entfernt.

Zusätzlich würde ich das Applikationspasswort noch in kurzen Abständen ändern. Außerdem sollte in einem bestimmten Zeitraum nur eine kleine Anzahl von Einmalpasswörtern generiert werden dürfen.

Eure/deine Meinung?

Gruß
Christoph Jeschke

[cr]

Guten Tag,

hallo

Genügend Feedback, warum das keine so gute Idee ist, hast du nun ja bekommen. Ich sehe das im Übrigen genauso.

Da ich aber die Idee prinzipiell interessant finde, überlegte ich folgende Vorgehensweise:

schön ;)

1. Ich schreibe ein Skript, welches nach dessen Aufruf ein Einmalpasswort an mein Mobiltelefon schickt, egal ob per SMS, E-Mail oder E-Mail über SMS. Das Einmalpasswort sollte dabei recht stark sein, denn daran hängt in einer feindlichen Umgebung nun der eigentliche Schutz.

ähm kurze zwischenfrage: wenn dieses script aber mit auf meinem webspace liebt kann das doch auch n hacker theoretisch hacken und dann hat er die funktionsweeise des scriptes...oder sehe ich da was falsch bzw meintest du das iwie anders?

2. Das Skript schreibt das Passwort in eine Datei (oder Datenbank).
3. Beim Login in meine eigentliche Applikation muss nun nicht nur das Applikationspasswort, sondern auch das Einmalpasswort korrekt angegeben werden.
4. Das Einmalpasswort wird von dem System / aus der Datenbank entfernt.

ähm kurze zwischenfrage

Zusätzlich würde ich das Applikationspasswort noch in kurzen Abständen ändern. Außerdem sollte in einem bestimmten Zeitraum nur eine kleine Anzahl von Einmalpasswörtern generiert werden dürfen.

Eure/deine Meinung?

toll!

also ich verstehe das so:

-> der rechner ist bei mir zu hause. auf diesem ist die seite mit den daten die ich benötige. auf meinem normalen webspace lass ich ein script laufen, welches bei aufruf (ggf mittels pwd gesichert) mit eine sms schickt. zusätzlich schreibt ddas script eine txt mit dem passwort in blowfish verschlüsselt und dazu einen timestamp von 60 sekunden z.b.
der homerechner geht nach eingabe der zugangsdaten auf den entfernten server (SSL) und liest die txt aus, vergleicht das pwd und prüft ob die zeit abgelaufen ist.

so würd ich das machen, meinung?

grüße

cr

[Christoph Jeschke]

Guten Tag,

ähm kurze zwischenfrage: wenn dieses script aber mit auf meinem webspace
liebt kann das doch auch n hacker theoretisch hacken und dann hat er die
funktionsweeise des scriptes...oder sehe ich da was falsch bzw meintest du
das iwie anders?

Wenn ein Einbrecher deinen Webspace kompromittieren kann, brauchst du auch kein Einmalpasswort mehr. Dann kann er vermutlich auch deine Hauptapplikation kompromittieren.

Sollte ein Angreifer dein Skript finden, kann er nichts anderes tun, als _dir_ neue Einmalpasswörter an dein Mobiltelefon schicken. Rufst du das Einmalpasswort-Skript aus einer feindlichen Umgebung heraus auf, ist es egal, ob du ein Passwort angibst, oder nicht. Denn wenn ein Keylogger installiert ist oder dein Netzwerktraffic mitgeschnitten wird, ist es danach eh bekannt.

Du könntest dein Einmalpasswort noch mit einem weiteren, nur dir bekanntem Passwort, prefixen. Dann kann jemand, der zwar dein Mobiltelefon hat, noch nichts mit den Einmalpasswörtern anfangen.

Um sich bei deiner Hauptapplikation anmelden zu können, benötigt man dann:
1. Username der Hauptapplikation
2. Passwort der Hauptapplikation
3. Einmalpasswort auf dem Mobiltelefon
4. Passwort-Prefix aus deinem Kopf

Problematisches wird es, wenn jemand Zugriff auf dein Mobiltelefon oder die übertragenen Daten hat und 1,2 und 4 kennt.

Gruß
Christoph Jeschke

[cr]

Guten Tag,

guten tag

Wenn ein Einbrecher deinen Webspace kompromittieren kann, brauchst du auch kein Einmalpasswort mehr. Dann kann er vermutlich auch deine Hauptapplikation kompromittieren.

stimmt

Du könntest dein Einmalpasswort noch mit einem weiteren, nur dir bekanntem Passwort, prefixen. Dann kann jemand, der zwar dein Mobiltelefon hat, noch nichts mit den Einmalpasswörtern anfangen.

ja klingt interessant...

Um sich bei deiner Hauptapplikation anmelden zu können, benötigt man dann:

1. Username der Hauptapplikation
2. Passwort der Hauptapplikation
3. Einmalpasswort auf dem Mobiltelefon
4. Passwort-Prefix aus deinem Kopf

ganz dumme frage:

um den ganzen spaß zu vereinfachen könnte ich doch auch einfach n "zettel" nehmen, darauf 10 TAN-Nummern schreiben, diese mit blowfish verschlüsselt online in der hauptapplikation sichern. Bei jedem Aufruf nutze ich Nutzername, Passwort und eine Nummer der Liste.

Zusätzlich kann man ja tricks beim eingeben nutzen, so dass jemand, der den Zettel findet, auch damit nichts anfangen kann. ?

Oder: (jetzt wirds langsam viel)

einfach ne vpn verbindung zum rechner aufbauen und darüber alles laufen lassen?

oh ich glaub da solltest du als profi mir nen sinnvollen tip zu den letzten 2 punkten geben

danke!

[Alexander (HH)]

Moin Moin!

ganz dumme frage:

um den ganzen spaß zu vereinfachen könnte ich doch auch einfach n "zettel" nehmen, darauf 10 TAN-Nummern schreiben, diese mit blowfish verschlüsselt online in der hauptapplikation sichern. Bei jedem Aufruf nutze ich Nutzername, Passwort und eine Nummer der Liste.

Und nach 10 Logins ist Schluß. Ein HW-Token liefert Dir jede Minute eine neue TAN.

Blowfish, ROT13 und *ALLE* anderen Verschlüsselungsalgorithmen nützen Dir gar nichts, wenn Du verschlüsselte Daten, Entschlüsselungsalgorithmus und Schlüssel direkt nebeneinander auf dem Server liegen hast.

Zusätzlich kann man ja tricks beim eingeben nutzen, so dass jemand, der den Zettel findet, auch damit nichts anfangen kann. ?

Doch. Was für Tricks willst Du benutzen? Blowfish-Dekodierung der Blowfish-verschlüsselten TANs auf Deinem Zettel im Kopf?

Oder: (jetzt wirds langsam viel)

einfach ne vpn verbindung zum rechner aufbauen und darüber alles laufen lassen?

Das würde Dein Problem im wesentlich darauf reduzieren, eine vernünftige VPN-Software zu finden und Deinen Laptop mit dem VPN-Client mit Dir herum zu schleppen. Alle Deine administrativen Programme auf Deinen Servern könntest Du so auf einen Schlag schützen, ohne eine einzige Zeile Code anfassen zu müssen.

Der einzige Haken an VPN-Software ist, dass Du einen mehr oder weniger ungehinderten Internet-Zugang brauchst. In größeren Firmennetzwerken ist oft absolut keine direkte Internet-Verbindung herzustellen, HTTP und HTTPS gehen über Proxies, Mail geht über eigene Server, der Rest ist schlicht gesperrt. Dann ist ein UMTS-Stick sehr hilfreich, notfalls auch ein Modem oder ein ISDN-Adapter.

FÜr den Zugang zum VPN kannst Du, je nach Software, z.B. Passworte, Zertifikate oder Token-Codes benutzen. Letzere sind bei ausreichender Paranoia natürlich zu empfehlen. Der Token ist dabei natürlich NIE in der Laptop-Tasche.

Alexander

[Alexander (HH)]

Moin Moin!

Um sich bei deiner Hauptapplikation anmelden zu können, benötigt man dann:

1. Username der Hauptapplikation
2. Passwort der Hauptapplikation
3. Einmalpasswort auf dem Mobiltelefon
4. Passwort-Prefix aus deinem Kopf

Problematisches wird es, wenn jemand Zugriff auf dein Mobiltelefon oder die übertragenen Daten hat und 1,2 und 4 kennt.

Insbesondere Nr. 4 ist kritisch, wie schon gesagt. Je nach Paranoia-Grad und Bedarf an Datenschutz sorgt man dafür, dass es mehrere Prefixe gibt, die z.B. von der Uhrzeit abhängen. Man könnte auch darüber nachdenken, diverse Prefixe als "Kill-Switches" einzubauen, die bei ansonsten korrekten Login-Daten das System abriegeln oder zerstören.

Alexander

[Alexander (HH)]

Moin Moin!

1. Ich schreibe ein Skript, welches nach dessen Aufruf ein Einmalpasswort an mein Mobiltelefon schickt, egal ob per SMS, E-Mail oder E-Mail über SMS. Das Einmalpasswort sollte dabei recht stark sein, denn daran hängt in einer feindlichen Umgebung nun der eigentliche Schutz.
2. Das Skript schreibt das Passwort in eine Datei (oder Datenbank).
3. Beim Login in meine eigentliche Applikation muss nun nicht nur das Applikationspasswort, sondern auch das Einmalpasswort korrekt angegeben werden.
4. Das Einmalpasswort wird von dem System / aus der Datenbank entfernt.

Guter Ansatz.

Das Einmal-Passwort ist reines Rauschen, hängt weder vom HTTP-Request noch von irgendwelchen anderen Daten (Datum, Uhrzeit, Prozess-ID, ...) auf dem Servern ab. Damit das Tippen nicht so schwierig wird, codiert man das Passwort als Base64 o.ä.

Haken: SMS und E-Mail haben keine garantieren Zustellzeiten. Ich habe bei beiden schon Zustellzeiten von über 8 Stunden beobachtet.

Zusätzlich würde ich das Applikationspasswort noch in kurzen Abständen ändern.

Generell eine gute Idee.

Außerdem sollte in einem bestimmten Zeitraum nur eine kleine Anzahl von Einmalpasswörtern generiert werden dürfen.

Damit öffnest Du DoS-Angriffen Tür und Tor. Was schadet es der DB, wenn ein paar 10.000 unnütze Einmal-Passworte in der DB liegen, die in ein paar Minuten ohnehin wieder gelöscht werden?

Alexander

[hotti]

hi,

da ih mich ab und zu von fremden rechnern in mein cms einloggen muss, würde ich da sehr gern noch als sicherheitskomponente ne art software token einführen...

Für sowas verwende ich einen eigenen UserAgent auf einem USB-Stick, womit auch das temporäre Zeugs wie Cookies, Passworte und so auf dem Stick haften bleiben, den ich dann ganz einfach und cool aus der Büchse rausziehe, wenn ich fertisch bin.

Hotte

[Alexander (HH)]

Moin Moin!

da ih mich ab und zu von fremden rechnern in mein cms einloggen muss, würde ich da sehr gern noch als sicherheitskomponente ne art software token einführen...

Wenn dich die Paranoia packt, nimm ein Hardware-Token, das gibt's z.B. von RSA (SecurID). Mit Token und Passwort hast Du Zugriff auf Deinen Server, ohne oder mit nur einem von beidem nicht.

Ein Software-Token (ebenso wie alle Keys und Zertifikate auf externen Massenspeichern) könnte ein Angreifer auf einem vorbereiteten Rechner KOMPLETT abgreifen, das wäre damit absolut nutzlos. Das Passwort greift er ohnehin per Keylogger ab. Beim Hardware-Token müßte der Angreifer Dir auch noch den Token klauen, der an Deinem Schlüsselbund hängt oder in Deiner Brieftasche steckt. Die guten Token nehmen auch gleich das Passwort selbst an, damit ist auch der Keylogger nutzlos.

Vergiß auch nicht, dass Rubber-hose Cryptanalysis ein extrem wirksamer Angriff sein kann.

Wenn Du also sehr viel Wert auf die Sicherheit Deiner Daten legst, sorgst Du dafür, dass der Token im Notfall sehr schnell, sehr gründlich und sehr sicher zerstört werden kann. Und vor allem benutzt Du keine fremden Rechner, sondern einen eigenen. Das gilt auch für den Internet-Zugang.

Alexander

[Christoph Jeschke]

Guten Tag,

Vergiß auch nicht, dass [Rubber-hose Cryptanalysis](http://de.wikipedia.org/wiki/Rubber-
hose_cryptanalysis) ein extrem wirksamer
Angriff sein kann.

Siehe hierzu:

von xkcd.

Gruß
Christoph Jeschke