dynaperl

100% porentief rein

OTP Token von SafeNet: eToken PASS

04. April 2012

Ich habe gerade einen eToken Pass (TOTP Version) der Firma SafeNet hier und wollte  den gerne gegen eigene Software Testen (keine OTP Infrastruktur von SafeNet). Was sich erst als nicht so einfach herausstellte. Zum einen verwendet der Token sha256 als Hash Methode (viele Tools verwendet noch sha1) und zum anderen verwendet der Token als Basis-Zeit den 1.1.2000 (und nicht den 1.1.1970). Wenn man das weiß ist es dann relativ einfach.

Ich verwende zum testen dieses Python Modul:

import oath
import hashlib
import time
print "code",oath.totp(my_secret_key,'dec6',30,time.time()-946684800.0,hashlib.sha256)

Die Differenz zwischen dem 1.1.1970 und dem 1.1.2000 sind 946684800.0 Sekunden. Mein mir vorliegender Key geht aber um 8 Minuten falsch so das ich bei mir 946685280.0 verwenden mußte.

Es bietet sich deswegen an die Funktion accept_totp zu verwenden der man ein Drift mitgeben kann um wie viel Schritte die Zeit/der Code abweichen darf  (in meinem Beispiel +/- 20 mal 30 Sekunden).

>>> print oath.accept_totp(my_secret_key, '123456', 'dec6', 30, time.time()-946685280.0 ,hashlib.sha256, 20, 20)
(True, -16)

Den Key (Seed) des Tokens haben ich übrigens vom Hersteller auf einer CD bekommen. Normalerweise würde man den selbst erstellen. Dazu gibt es einen Programmier-Stift mit dem sich die Tokens neu programmieren lassen. Die Variable my_secret_key ist in dem Fall dann ein 64 Zeichen langer Hexcodierter String.

Probleme mit DomainKeys

19. März 2012

DomainKeys ist ähnlich wie das neuere DKIM eine Möglichkeit ausgehende Mails kryptographisch zu signieren. Der Empfänger kann dann über einen im DNS abgelegten öffentlichen Schlüssen prüfen ob die Mail verändert wurde und damit auch sicherstellen das der Absender Mailserver wirklich berechtigt ist Mails für die Absender Domain zu verschicken.

DomainKeys ist mal von Yahoo erdacht worden. Das wurde dann später noch mal etwas verändert und heißt jetzt DKIM. Eigentlich ist daher DomainKeys ein Auslaufmodel. Es gibt aber weiterhin noch Anbieter die nur DomainKeys einsetzen. Wenn man also Wert darauf legt das die Mails ankommen (und nicht als Spam markiert werden) sollte DKIM und DomainsKeys und vielleicht auch SPF einsetzen.

Es gibt eine DomainsKeys Implementation für Debian in Debian Sid die allerdings einen dokumentierten Bug hat (siehe /usr/share/doc/dk-filter/KNOWNBUGS).

There is a known problem with signing messages that have a header field which
repeats (e.g. a message with multiple „Received:“ header fields).

Die Fehlermeldung ist dann sowas wie:

fail (bad signature)

Bevor ich die so nahe liegen Lösung in dem Knownbugs-File gefunden hatte mußt ich natürlich erstmal das ganze Internet nach dem Fehler durchsuchen. Hier finden sich einige Foren Beiträge von Usern die einen Ähnlichen Fehler beschreiben. Hier tritt das Problem in Verbindung mit Plesk auf. Und zwar immer nur dann wenn man ein externes E-Mail Programm verwenden. Nicht wenn man den eingebauten Webmailer verwendet. Grund könnte auch hier die in dem Fall doppelte Received Zeile sein.

Lösung des Problems ist die Option -o Received in der Variable DAEMON_OPTS in der Konfigurationsdatei /etc/default/dk-filter.  Die Option ignoriert die Received Header und damit stimmt die Signatur dann wieder.

Testen kann man das in dem man eine E-Mail an check-auth@verifier.port25.com schickt. Oder an ein Yahoo Postfach und sich dann den Header einblenden läßt.