Beiträge von madblueimp

Ja.

Betreffend des Updates von addons.mozilla.org:
Obwohl Secure Login schon auf addons.mozilla.org gelistet war ist die Erweiterung wieder verschwunden.
Sie ist allerdings nicht wirklich verschwunden, kann allerdings derzeit nur im sogenannten "Sandkasten" gefunden werden.
Um zum Sandkasten zu kommen, muss man sich bei addons.mozilla.org registrieren, dann einloggen, auf die Email-Adresse klicken, die Checkbox anklicken bei der "Sandkasten anzeigen" steht und die Einstellungen speichern.
Ich schätze mal das ein paar Bewertungen nötig sind, bevor Secure Login wieder öffentlich verfügbar ist.
Falls ihr also Secure Login unterstützen wollt, damit die Erweiterung wieder öffentlich auf addons.mozilla.org gelistet wird, schreibt bitte auf der neuen Seite eure Bewertungen.

Die Secure Login Mausgeste findet sich unter http://en.mousegestures.org/gesture-exchan…p?mappingID=280
Danke an MonztA für den Eintrag und den Hinweis.

Ich habe den Eintrag nochmal editiert, da "UR" schon für das Schließen eines Dokuments vorbelegt ist.
Außerdem habe ich noch den Link zur Projektseite hinzugefügt - denn leider wird Secure Login im Moment nicht auf addons.mozilla.org gelistet.

Nachtrag:
Die Mausgeste kann nach der Installation der Mouse Gestures Erweiterung auch direkt von der Secure Login Projektseite installiert werden.

Dr. Evil:
Mein in vielen schlaflosen Nächten angehäuftes (Halb)-Wissen wartet ja nur darauf, eingesetzt zu werden.

MonztA:
Der Mouse Gestures Code für den Login mit Secure Login ist der folgende:

try {
	secureLogin.login();
} catch (e) {}

Zu 1. bis 3. und 5. empfehle ich dir die folgenden Links:
http://kb.mozillazine.org/Signons.txt
http://kb.mozillazine.org/Key3.db
http://www.mozilla.org/projects/secur…security_device
http://developer.mozilla.org/en/docs/Category:Security
http://developer.mozilla.org/en/docs/NSS_reference
http://www.mozilla.org/projects/secur…ons.html#crypto

Der zuletzt aufgeführte Link führt direkt zum C++ Source-Code der Kryptgrafischen Funktionen.

Das Verschlüsselungs-Verfahren ist also nicht unbekannt - Firefox ist schließlich eine Open Source Software.
Ich habe mir die Implementierung jedoch nicht näher angeschaut, meine C++ Kenntnisse sind nicht sehr weit fortgeschritten.

Es gibt jedoch andere, die das getan haben:
http://nagmatrix.50webs.com/article_firepassword.html
http://nagmatrix.50webs.com/article_firemaster.html
Das Erste (firepassword) ist eine Software zur Entschlüsselung der gespeicherten Passwörter - dazu benötigt sie auch das Master-Passwort.
Das Zweite (firemaster) ist eine Software zur Wiederherstellung des Master-Passworts - dies wird mit Hilfe von Brute Force und "Wörterbuch"-Attacken durchgeführt.

Brute Force-Methoden sind bei ausreichender Zeitspanne immer erfolgreich.
D.h. letztendlich lässt sich jede Verschlüsselung knacken, wenn man nur genügend Zeit dafür aufbringt.
Falls die Verschlüsselung jedoch stark genug ist, dann lässt sie sich nicht in praktikabler Zeit knacken.
Der größte Knackpunkt ist hierbei ein schwaches Master-Passwort.
Ist das Master-Passwort kryptisch (Buchstaben in Groß-/Kleinschreibung, Zahlen, Sonderzeichen) und lang genug, dann ist die Verschlüsselung praktisch nicht zu knacken.

Man hört manchmal, das Verschlüsselungs-Verfahren "geknackt" worden sind und als nicht mehr sicher gelten - meist ist der Grund der, das jemand herausgefunden hat, wie man die Zeit, die z.B. die Brute-Force-Methode benötigt, drastisch reduzieren kann (wenn z.B. Kollisionen gefunden wurden).
siehe hierzu auch:
http://de.wikipedia.org/wiki/Md5
http://de.wikipedia.org/wiki/Hash-Funktion
http://de.wikipedia.org/wiki/Kollisionsfreiheit

Über Firefox kryptografische Funktionen habe ich solch eine Meldung noch nicht gehört - ich nehme auch an, das solch ein Fehler schnellstmöglich behoben werden würde.

Insgesamt gehe ich also davon aus, das Firefox Verschlüsselungs-Verfahren bei Einsatz eines ausreichend sicheren Master-Passworts als sicher gelten kann.

Zu 4.:
Firefox Passwort Manager kommt mit Bank-Logins klar (und damit auch Secure Login) - siehe:
http://www.firefox-browser.de/forum/viewtopi…tart=180#356055

Zu 6.:
Die Sicherheitslücke, die mit ein Grund zur Entwicklung der Secure Login Erweiterung war, haben die Firefox-Entwickler mit der Version 2.0.0.2 behoben, in dem nun auch das form action Attribut mitgespeichert und überprüft wird.
Fehler gibt es in jeder Software und ich bin mir ziemlich sicher, das die Firefox Entwickler sehr auf die Sicherheit ihrer Software bedacht sind.

Es gibt einen Unterschied zwischen JavaScript-Code auf Webseiten und lokalem JavaScript Code von Erweiterungen und Firefox-Komponenten:

Zitat

Also note, when surfing web pages which use JavaScript, that JavaScript code is executed within a sand box, and does not have access to Mozilla's internal objects. Only those objects that are exposed by DOM (Document Object Model) are accessible.

http://www.mozilla.org/hacking/coding…tion.html#cppjs

Wie auf der Projektseite beschrieben, versucht Secure Login vor Phishing und cross-site scripting (XSS) zu schützen - also JavaScript-Code, der von Webseiten geladen wurde.

Um den Secure Login Quellcode zu manipulieren, müsste ein Angreifer Zugriff auf das Dateisystem des Benutzers haben.
Wenn ein Angreifer einmal das erreicht hat, gibt es weitaus mehr Möglichkeiten um Passwörter abzugreifen als den Quellcode einer Firefox-Erweiterung zu manipulieren.

Verschlüsselung kann nur davon schützen, das ein Angreifer vorhandene Passwörter nicht einfach auslesen kann, falls z.B. das Laptop des Anwenders gestohlen wurde.
Sobald ein Angreifer das System manipulieren kann und der Anwender das nicht merkt wenn er sich das nächste mal an seinem System einloggt, sind keine seiner Daten mehr sicher.

Auch Binärcode lässt sich manipulieren. Vor Code-Manipulation schützt in diesem Fall nur eine Signierung - was im Falle der Erweiterungen und des JavaScript-Codes zwar auch möglich, aber derzeit nicht praktikabel ist.
Signierte Firefox-Erweiterungen hätten den Vorteil, das man bei Download und Installation der Erweiterung ihre Vertrauenswürdigkeit und Integrität sicherstellen könnte (wenn man dem Inhaber und dem Aussteller des Zertifikats vertraut).

Zu 7.:
Alle verschlüsselten Daten liegen im Arbeitsspeicher irgendwann in entschlüsselter Form vor wenn man sie entschlüsselt nutzt - das liegt in der Natur der Sache.
Und Login-Daten für HTTP-Formulare müssen vor der Übertragung entschlüsselt werden.
Das gilt auch für per HTTPS übertragene Daten. Diese werden zwar wiederum verschlüsselt übertragen, jedoch wird dazu der "Public Key" des Webservers verwendet, und nicht der lokale Schlüssel aus der key3.db Datei.

Man muss bei diesem Thema ganz klar zwischen Websicherheit und der lokalen Sicherheit und Integrität des Betriebssystems unterscheiden!

Vollständige Sicherheit ist meiner Meinung nach nicht erreichbar.
Sehr nahe kommt man der absoluten Sicherheit, wenn man sein gesamtes Betriebssystem verschlüsselt.
Aber auch dann wären durch physischen Zugriff Manipulationen an der Hardware möglich.

Mir reicht es, das meine Daten-Partition verschlüsselt ist - siehe https://blueimp.net/linux/howto/encryption.txt
Das schützt mich nicht davor, wenn jemand mein Betriebsystem manipuliert, ich dies nicht merke und mich wieder einlogge und das Passwort zur Verschlüsselung eingebe.
Es reicht aber, das ein gestohlenes Laptop oder eine gestohlene Festplatte nicht auch gleichzeitig bedeutet, das meine persönlichen Daten gestohlen wurden.

Ein gesteigertes Sicherheitsinteresse ist aber auf jeden Fall zu begrüßen - Vielen Dank daher an cyclefox für die Anmerkungen.

Zitat von skyworker

Einen alternativen Messenger kann ich nicht einsetzen, da über MSN alle Geschäfts und Privatkontakte Weltweit laufen. Müssten ja wegen mir alle umstellen, kann ich keinem zumuten.

Deswegen habe ich dir ja Miranda empfohlen - damit müssen deine Kontakte nichts umstellen, denn du kannst weiter das MSN-Protokoll benutzen. Du wechselst mit Miranda nicht das Protokoll, sondern nur den Client.
Und in Miranda kannst du Links mit Mozilla Firefox öffnen - womit dein Problem gelöst wäre.

Und falls sich jetzt jemand wundert, was das alles mit Secure Login zu tun hat:
Öffnen sich Links mit Mozilla Firefox, kann man sich auch mit Secure Login einloggen.

P.S.:
Mit einem Multi-Protokoll-Chat-Client wie Miranda oder Gaim kannst du unterschiedliche Chat-Protokolle unter der gleichen Benutzeroberfläche nutzen - mit einer einzigen Kontaktliste.
Auf diese Weise fällt es leichter, weniger verbreitete aber (meiner Meinung nach) bessere Protokolle wie z.B. Jabber einzusetzen, ohne MSN oder ICQ Kontakte auszuschließen.

skyworker:

Wie Alexxander schon geschrieben hat:
Der IE ist ein integraler Bestandteil des Windows Betriebssystems - d.h. man kann ihn auch nicht komplett deinstallieren (über die Softwareverwaltung werden ja nur die Verknüpfungen entfernt).

So weit ich das verstanden habe ist dein Problem, das der mit dem MSN Messenger verknüpfte Browser immer noch der IE ist, anstatt Firefox, den du wahrscheinlich ansonsten als Standard-Browser eingestellt hast.

Ob es hierfür eine Einstellung oder eine Registry-Konfiguration gibt, weiß ich leider nicht.
Was du aber machen könntest, wäre einen alternativen Messenger einzusetzen, z.B. Miranda. Miranda ist ein Multi-Protokoll-Chat-Client und beherrscht unter anderem das MSN-Protokoll.

Edit:
Alexxander:
Danke und kein Problem, schweife ja selbst manchmal vom Thema ab. So lange ich keine Fragen zu Secure Login überlese macht das ja nix.

skyworker:
Vielleicht solltest du auch mal dein Betriebssystem aktualisieren - laut http://support.microsoft.com/lifecycle/?p1=6898 ist der Support für Win98SE mittlerweile eingestellt - d.h. auch keine Sicherheitsupdates mehr.
Bei der Gelegenheit könntest du dir ja mal eine der zahlreichen Linux-Distributionen anschauen, z.B. Ubuntu.

Ich finde diese beiden Erweiterungen für das Cookie Management ganz praktisch:

https://addons.mozilla.org/firefox/2497/
https://addons.mozilla.org/firefox/3587/

Ich denke nicht, das Secure Login der Grund für deinen gestiegenen Speicherverbrauch ist:
- Secure Login sammelt keine Daten an
- Die von Secure Login während der Laufzeit erzeugten Objekte werden immer wieder dereferenziert, so das sie vom Garbage Collector ohne Probleme weggeräumt werden können.
Eigentlich kann eine in JavaScript implementierte Erweiterung gar nicht zu Speicherproblemen führen, so lange sie nicht Unmengen von Daten ansammelt.
Der Garbage Collector von Firefox JavaScript-Implementierung schafft es meines Wissens sogar, sich gegenseitig referenzierende Objekte als "nicht mehr gebraucht" zu Erkennen.

Da ich ja quasi Dauer-Tester der "Secure Login"-Erweiterung bin (ich habe sie unter anderem entwickelt, weil mir das Feature selber fehlte), wäre mir solch ein Memory-Leak sicher aufgefallen.
Als Student der "Online-Medien" ist mein Browser noch dazu im Dauerbetrieb und ich ziemlich häufig am Rechner.

Generell habe ich bei der Entwicklung der Secure Login Erweiterung darauf geachtet, alles möglichst performant und ressourcenschonend zu implementieren:
- Wenn du dir den <a href="view-source:jar:jar:https://blueimp.net/mozilla/xpi/se…/secureLogin.js">Quellcode</a> anschaust, siehst du z.B. das Konzept der Lazy Initialization.
- Die Methode, welche passende Logins sucht, steigt möglichst schnell aus.
- Werden durch die Menüs neue Fenster geöffnet, wird das vorhandene "Secure Login Objekt" als Parameter übergeben, so müssen die darin referenzierten Objekte nicht neu instanziert werden
- Die Arrays, welche die Login-Daten zwischenspeichern werden immer wieder derefernziert und können vom Garbage Collector weggeräumt werden

Ich vermute daher jetzt mal, das deine Speicherprobleme eine andere Ursache haben.

Hier meine Antwort auf die E-Mail eines interessierten (deutschsprachigen) Anwenders, ist vielleicht auch für andere interessant:

Zitat

> Hello Mr. Tschan,
> thanks for that very interessting AddOn SecureLogin!
> I would like to test/use it. But how can I really trust?
>
> I'm interessted to know more about the implemenation of SecureLogin.
> Why it does also work without any JS and J?
>
> In wich language it is written and may I (how may I ...) check the code?
>
> It does not warn me, if the URL is changed from a http: form to a https: form.
> [...]

Alles anzeigen

Zitat

[...]
Prima Einstellung, generell sollte man Software nur aus
vertrauenswürdigen Quellen installieren.
Im Falle der Firefox-Erweiterungen ist eine vertrauenswürdige Quelle
z.B. https://addons.mozilla.org.
Die Erweiterungen, die dort gelistet sind wurden von
mozilla-Mitarbeitern getestet.
Secure Login ist dort auch aufgeführt, allerdings zur Zeit in einer
etwas veralteten Version:
https://addons.mozilla.org/firefox/4429/

Secure Login ist wie die meisten Firefox Erweiterungen in JavaScript
(Programm-Code, Logik), XUL (XML-Dialekt,
Oberflächen-Beschreibungssprache) und CSS (Cascading Stylesheets zur
Anpassung des Oberflächen-Designs) geschrieben.

Firefox unterscheidet zwischen JavaScript als Teil von Webseiten und als
Teil von Erweiterungen. Einige Komponenten von Firefox sind selbst in
JavaScript geschrieben.
Daher ist es für Erweiterungen egal ob in den Optionen von Firefox
JavaScript deaktiviert wurde.
Java hat mit Firefox direkt überhaupt nichts zu tun und ist wie Flash
bloß als Plugin eingebunden um Java Applets im Browser-Fenster anzeigen
zu können.

Secure Login ist eine Open Source Software und steht unter der GPL:
http://www.gnu.org/copyleft/gpl.html
Das heißt du darfst dir den Quelltext nicht nur ansehen, sondern ihn
sogar in eigenen Projekten weiterverwenden, so lange die daraus
entstehende Software auch wieder unter der GPL steht.

Firefox-Erweiterungen haben zwar die Endung ".xpi" sind aber einfache
ZIP-Archive. Du kannst sie mit einem geeigneten Packer, z.B. 7-ZIP
(http://www.7-zip.org/de/) entpacken.
Darin enthalten ist unter anderem eine Datei mit der Endung ".jar", auch
wieder ein ZIP-Archiv, das den Programm-Code enthält.

Offizielle Infos über die Entwicklung von Firefox-Erweiterungen findest
du hier:
http://developer.mozilla.org/en/docs/Extensions

Mit Firefox ist es sogar möglich, über eine spezielle URL-Angabe direkt
in den Quellcode einer Erweiterung "hineinzuschauen", hier z.B. die
aktuelle Haupt-Skript-Datei der Secure Login Erweiterung:
<a href="view-source:jar:jar:https://blueimp.net/mozilla/xpi/se…/secureLogin.js">view-source:jar:jar:https://blueimp.net/mozilla/xpi/se…/secureLogin.js</a>

Die Warnung falls vom unverschlüsselten http-Protokoll auf das
verschlüsselte https-Protokoll gewechselt wird kommt nicht wenn man
a) Diese Warnung in den Optionen von Firefox deaktiviert hat
b) Man zum Einloggen mit Secure Login die Option "JavaScript-Schutz beim
Einloggen aktivieren" nutzt.
Die Nachfrage habe ich dort nicht eingebaut weil ich sie nicht für
relevant halte. Es ist ja positiv, wenn die Login-Daten verschlüsselt
übertragen werden.
[...]

Alles anzeigen

NoScript ist definitiv eine "Must-have"-Erweiterung, wenn man auf sicheres Surfen Wert legt.
Ist sicherheitstechnisch die wichtigste der von mir genutzten Erweiterungen.
Klar könnte man auch JavaScript einfach abschalten, aber das ist wieder unpraktisch, da es doch zu viele "vertrauenswürdige" Seiten voraussetzen.

Das (mit einem Master-Passwort gesicherte) Abspeichern von langen, zufälligen kryptischen Passwörtern halte ich für ein geringeres Risiko als schwache Passwörter zu verwenden, die durch Brute-Force Methoden in praktikabler Zeit geknackt werden können.
Wenn man sich solche Passwörter auswendig merken kann ist das natürlich noch besser, ich kann mir meine > 50 kryptischen Passwörter mit > 20 Zeichen allerdings nicht merken.

Ich freu mich, wenn ich mit Secure Login einen Beitrag zur Browser-Sicherheit leisten kann. Das hatte ich auch im Sinn, als ich die Erweiterung entworfen habe - Sicherheit ohne Verlust von Komfort.

"Hackern" allgemein will ich das Leben aber nicht schwer machen. Ich verstehe den Begriff eher so wie in der Wikipedia beschrieben:

Zitat

eine Person, die sich daran erfreut, ein tiefgreifendes Verständnis der internen Arbeitsweise eines technischen Systems zu erlangen

Es ist also eher eine Maßnahme gegen Phisher und "Cracker".

Vielen Dank, skyworker.

Vor der "Password Stealing Demo" auf heise Security ist man mit der Version 2.0.0.2 von Firefox auch ohne meine Erweiterung geschützt, da Firefox seit dieser Version bei neuen Passwort-Einträgen das "action"-Attribut der Formulare mitspeichert.

Sicherer finde ich es natürlich trotzdem weiterhin, Passwörter nirgendwo einzutragen so lange keine Benutzerinteraktion dafür vorausgegangen ist.

Danke für das Bekanntmachen der Erweiterung. Je mehr Links auf https://blueimp.net/mozilla/ mit Bezug auf die Erweiterung verweisen, desto höher steigt die Erweiterung auch in den Ergebnissen der Suchmaschinen.

Schon in Ordnung, du hast es ja in einem anderen Beitrag eingegrenzt:

Zitat von camel-joe

Es ist ein kleines Stück Sicherheit, denn ein unbedarfter User macht da mal schnell einen Fehler.

Und die von dir beschriebene Person handelt ja tatsächlich grob fahrlässig.

Ansonsten bin ich eigentlich der Meinung, das man unerfahrenen Benutzern Online-Banking überhaupt nicht empfehlen sollte:
Egal ob sie so grob fahrlässig handeln wie oben beschrieben, einen Passwort Manager nutzen oder die Daten von Hand eingeben - solange sie sich nicht selbst um die Sicherheit ihres Rechners kümmern können/wollen aber gleichzeitig alles mögliche ausprobieren möchten haben sie höchstwahrscheinlich relativ bald Malware auf dem Rechner - und dann sind eigentlich überhaupt keine Daten mehr sicher die auf diesem System eingegeben, gespeichert oder über ein Netzwerk verschickt werden.

Eigentlich ist es wie beim Autofahren:
Ohne bestandenen Führerschein und ausreichende Erfahrung kann man sich nicht sicher im Straßenverkehr bewegen.
Und ohne ausreichende Kenntnisse über IT-Sicherheit kann man sich nicht sicher im Internet bewegen.

Eigentlich glaube ich auch nicht, das es jemals ein Betriebssystem oder Anwendungen geben wird, die gleichzeitig intuitiv und einfach zu bedienen sind und einem all die Möglichkeiten des Internets zur Verfügung stellen und gleichzeitig unerfahrene Anwender vor allen möglichen Gefahren schützen können.

Zitat von camel-joe

Hallo,

was auch gut so ist. Nur ein Volldepp speichert dies ab. :wink:

Jetzt hast du mich indirekt beleidigt. :twisted:

Meiner Meinung nach spricht nichts dagegen, die Bank-Login-Daten im Passwort-Manager zu speichern - man sollte den Passwort-Manager allerdings mit einem Master-Passwort absichern.
Oder man verschlüsselt die Partition, auf der das Firefox-Profil liegt. Aber auch dann ist das Master-Passwort noch ein nützlicher Zusatz-Schutz.

Die Tan-Liste würde ich jetzt allerdings auch nicht auf der Festplatte speichern, auch nicht im verschlüsselten Zustand.

Falls Firefox nicht nachfragt, ob das Passwort einer Login-Seite gespeichert werden soll, kann das schon an einer Besonderheit der Seite liegen:

Viele Bank-Seiten und manche andere Website fügen dem Formular und/oder den Eingabe-Feldern das Attribut autocomplete="off" hinzu.
Dieses Attribut verhindert, das Firefox den Dialog zum Speichern des Passwortes anzeigt:
http://developer.mozilla.org/en/docs/How_to…pletion_Feature

Damit Firefox den Dialog zur Speicherung des Passwortes anzeigt, muss man dieses Attribut also einfach aus dem Dokument (der Webseite) entfernen (oder auf "on" setzen).

Das kann man auf verschiedene Weise tun:
- Mit dem Bookmarklet remember password
- Mit dem Greasemonkey Script Allow Password Remembering
- Mit der Erweiterung Always remember password

Meiner Meinung nach ist das Bookmarklet am sinnvollsten, weil man es nur dann aufruft, wenn man es braucht, nämlich einmal bei jeder Seite, die das Speichern des Passwortes verhindert.

Wow, dieser Thread ist ja unterhaltsamer als die rot gefärbten Beiträge der Heise Foren.

Zitat von jgc5-8

a) It's not a bug, it's a feature.
--> der war gut!!

Ist ein beliebter Entwickler-Scherz um tatsächliche "Bugs" als Feature zu deklarieren ;):
http://en.wikipedia.org/wiki/Undocumented_feature
In diesem Fall ist es aber tatsächlich kein Bug.

Zu der Sache mit dem Tastaturkürzel: Das ist wirklich seltsam.
Wie gesagt, es ist genau der gleiche Funktionsaufruf, den kannst du dir sogar hier anschauen, die Funktion heißt "login":
<a href="view-source:jar:jar:https://blueimp.net/mozilla/xpi/se…/secureLogin.js">Secure Login Source - secureLogin.js</a>

Hast du es denn auch mal in einem frischen Firefox-Profil ausprobiert?
Und wenn ja und der Effekt immer noch auftritt, welche Firefox-Version genau, welches Betriebsystem, welche Lieblingsspeise, beliebtester Windows-Bluescreen, etc...

Versuch mal, die Login-Daten für diese Seiten nochmal manuell einzugeben und im Passwort Manager abzuspeichern (wenn du wieder zuhause bist).
Secure Login überprüft seit der Version 0.7.1 jetzt auch das "name"-Attribut der Login-Felder.
Eventuell haben die nachgeschalteten Logins andere "name"-Attribute.

Leider kann ich cortalconsors.de nicht tiefergehend testen, da ich kein Konto dort besitze.

michael815:
Könntest du das Problem bei cortalconsors.de genauer beschreiben?
Ich konnte bei dieser Website keine Probleme im Zusammenhang mit Secure Login feststellen.

jgc5-8:

a) It's not a bug, it's a feature.
In der Secure Login Hilfe steht folgendes:

Zitat

Was macht die Option 'JavaScript-Schutz beim Einloggen aktivieren'?
Falls diese Option aktiviert ist werden die Login Daten nicht in die Formular-Felder eingetragen und das Formular nicht abgeschickt. Die Login-Daten werden stattdessen mit internen Firefox Methoden an die Login-Seite geschickt.

Logischerweise ist die Option, das automatische Abschicken zu Deaktivieren in diesem Fall also ohne Wirkung.

b) Ein Klick auf das Schlüsselsymbol (in Toolbar oder Statusbar) und das Betätigen des Tastatus-Kürzels rufen genau die gleiche Funktion (secureLogin.login()) auf. Daher dürfte es hier eigentlich kein unterschiedliches Verhalten geben.

Der Login bei ebay.de klappt bei meinen Tests mit Secure Login einwandfrei, auch mit aktivierter JavaScript-Schutz Option. Kannst du das Verhalten jedesmal wieder reprododuzieren? Eventuell auch mal in einem frischen Firefox Profil ausprobieren.

Version 0.7.1 freigegeben
-------------------------------

Fehlerbehebung:
- URL-Kodierungs Probleme bei aktivierter "JavaScript-Schutz Option" behoben - Die Kodierung wird nun auf Basis des Dokumenten-Zeichensatzes durchgeführt

Neue Funktionen:
- Unterstützung für internationalisierte Domain Namen in der "JavaScript Schutz Ausnahmen Liste"
- Unterstützung für Login Formulare ohne Benutzernamen-Feld (nur Passwort-Feld)
- Neue Einstellung um das automatische Abschicken des Formulars zu deaktivieren
- Neue Sprache: Tschechisch - Danke an funTomas von babelzilla.org
- Neue Sprache: Niederländisch - Danke an markh von babelzilla.org
- Neue Sprache: Polnisch - Danke an teo von babelzilla.org
- Neue Sprache: Russisch - Danke an Modex und Sergeys von babelzilla.org

https://blueimp.net/mozilla/xpi/changelog.txt