Beiträge von Oliver222

Heaven_69 erklärte Folgendes:

Zitat

Das soll ja ab der nächsten Version des Fuxes wohl anders werden.[...]

Was soll sich denn anders gestalten? Firefox und Flash-PlugIns stellen - meiner Meinung nach - zwei unterschiedliche „Welten“ dar.

"Flash-Plug-Ins" sind über clientseitig ausführbare Scripte bereits schon auf Systemebene i.d.L. auf lokale MIME-Objekte (Multimedia-Daten) zugreifen, sofern eine Zugriffsberechtigung im Vorfeld nicht bereits über das OS selber eingeschränkt wurde. (z.B. über eine grobkörnige Modellierung der Zugriffsrechte auf ein Objekt / Anwendung / i.d.F. Flash).

Diskussionen um „veralteten Flashintegrationen“ innerhalb des Browsers würden somit auch hinfällig werden, da solche Diskussionen die eigentliche Problematik von "Browser Plug-Ins" bloss „umgehen“.

Oliver

MK204 fragte Folgendes:

Zitat

[...]Soll man so was [Flash Security-Flaws] ernst nehmen?

Ja. Analog zu der Ansicht Brummelchens.

Der Adobe-Flash-Player stellt sich - meiner Ansicht nach - weniger als eine Browser-Erweiterung dar, sondern integriert sich dagegen eher als ein lokales Anwendungsprogramm im System selber.

Über die sog. AIR (Adobe Integrated Runtime) wird zwar „oberflächlich“ eine browserunabhängige Applikation integriert, welche dann jedoch über eine plattformunabhängige Laufzeitumgebung - auf einem ungesicherten Betriebssystem – lokale Programme (auf Basis von Skripten) mit allen Systemrechten auszuführen vermag. Der Flash-Player kann somit über den Browser - im übertragenen Sinne - einen lokalen Server installieren, der das eigentliche System über:

a. Stack-Based Buffer Overflows,

b. Remote-Code Execution,

c. Click-Jacking,

d. Sandbox-Bypass,

kompromittieren könnte - sofern im Vorfeld keine Zugriffsbeschränkungen über „objektspezifische Zugriffsrechte“ (also eingeschränktes Flash als Objekt) bereits auf Systemebene (OS) erfolgte.

Oliver

Cosmo erklärte Folgendes:

Zitat

[...]Schneiers Zitat liest sich für mich so, als ob es unabhängig davon, ob ein symmetrisches oder asymmetrisches Verfahren verwendet wird, gemeint ist.

Du hast Recht. Ich hatte Dein obiges Zitat missverstanden.

Zwischen OpenSource (Dein ursprüngliches Zitat), sowie auch der Offenlegung von math. Verschlüsselungsalgorithmen zur ständigen Konzeptverbesserung (meine Darstellung), besteht dennoch eine Kohärenz (Gleichnis). Beides ist bewusst offen gehalten, einsehbar und lässt sich stets verbessern.

Keepass qualifiziert sich zwar als quelloffene und rechtsfreie OpenSource-Software. Keepass unterliegt - meiner Beurteilung nach - jedoch auch der „Qualität“ des zugrundeliegenden (symmetrischen) Verschlüsselungsverfahrens selber.

Die Kommunikationssicherheit in einem symmetrischen Kryptosystem hängt daher nicht alleine von der „Stärke“ der Verschlüsselung selber, sondern auch von der „Verwaltung“ und „Aufbewahrung“ des „geheimen Schlüssels“ ab. (Anwenderinteraktion / Übertragung des Schlüssels / Betriebssystemsicherheit i.B. auf die vertrauliche Schlüsselverwaltung). Hier liegt meiner Ansicht nach die einzige „Schwäche“ des Passwort-Safes vor.

Oliver

Cosmo stellte Folgendes dar:

Zitat

[...]Den portablen FF zu verwenden, wenn ich Zugangsdaten portabel benötige, fiele mir nicht einmal im Traum ein[...]

Zustimmung. Die Sicherheit der zu verwaltenen Passwörter hängt - meinen Erkenntnissen nach – im Allgemeinen auch von:

a. der kryptographischen Stärke der Hashfunktion,

b. der Qualität der Rechtevergabe, bzw. der Zugriffskontrolle der Subjekte (Anwender) auf so einem System oder Stick,

c. sowie auch dem Entzug der lokalen Leseberechtigungen für die vertrauliche Passwort-Datei selber ab.

Portable Pw´s (z.B. über USB-Applikationen), können i.d.T. unbeabsichtigt über ein bereits kompromittiertes Fremdsystem geführt werden, von wo sie aus dann u.U. „kriminell weiterverwertbar“ wären. Gleiches würde - meiner Ansicht nach - jedoch auch für den portablen Keepass gelten müssen, da sich grundsätzlich jedes PW zu einem bestimmten Zeitpunkt entschlüsselt im RAM eines wie auch immer gearteten (trojanisierten) Fremdsystems befinden müsste.

Vielleicht wäre es von daher sinnvoller auf so einem USB-Stick - mit seinen vertraulichen PW-Anwendungen - begleitend ein separat abgesichertes und bootbares OS zu implementieren, um somit die „Überführung“ vertraulicher Zugangswörter über ein bereits kompromittiertes und fremdes %SYSTEMROOT% zu vermeiden.

Cosmo erklärte darüberhinaus:

Zitat

[...]Dann kennst du auch das auf der [Keepass] Leitseite wiedergegebene Zitat von Bruce Schneier, einem der Kryptographie-Päpste weltweit:

Ich bin zufällig im Besitz seines Originalwerkes: [Applied Cryptography/Second Edition]. Ich glaube er [Bruce Schneier] meinte mit dem Zitat vordringlich die gewährleistete Authentizität, sowie auch die dafür notwendige Publikation des öffentlichen Schlüssels selber - und zwar zur allgemeinen Fehlerkontrolle der zugrundeliegenden Funktionsqualität. (RSA-Algorithmus / Schlüsselraum / Faktorisierung, etc.).

Oliver

Cosmo stellte Folgendes dar:

Zitat

[...]Deine inhaltliche Punkt für Punkt Auseinandersetzung steht weiterhin aus, wenn du versuchen solltest, das Nahelegen des Hauptbenutzers noch irgendwie zu begründen.

Du hast Dir gerade widersprochen. Es geht bei der Rechteverteilung auf einem XP-System - meiner Ansicht nach - nicht um die einzelnen Kontenklassen (Hauptbenutzer vs. Admin), sondern eher um die Interaktion des Anwenders i.B. auf nicht zertifizierte MS-Anwendungen. Dabei sollte generell gelten:

a. „Gehärtete“ PW´s für alle Accounts einer Gruppenrichtlinie (Zugriffsrechte auf einzelne Objekte (also Anwendungen) über ACL´s).

b. „Sensibilisierte“ Anwender i.B. auf sog. „Legacy-Installationen“ (abwärtskompatible Installationen: Basic / Compat / Secure / HiSec).

c. „Sicherheitsvorlagen“ (Security Templates), welche von MS als „proprietärer“ Industrie-Standard spezifiziert wurden.

Solche Sicherheitsvorlagen stellen eine Besonderheit dar, wobei es dennoch dem einzelnen Anwender vorbehalten bleibt, auf solche Installations-Fehlermeldungen (mit einem kurzfristigen Konten-Upgrade) zu reagieren. Dieses Verfahren unterliegt deshalb auch keiner automatischen Verschaffung (engl. gain) von höheren Anwender-Privilegien. Der Vorgang ist aktiv, nicht passiv.

Cosmo erklärte Folgendes:

Zitat

[...]Der alte Spruch "Wer lesen kann ist klar im Vorteil."[...]

Es geht nicht um das Lesen, sondern um das Verstehen. Solltest Du damit Probleme haben, zögere nicht hier zu Fragen...

Oliver

O.T.
Unter Windows NT/2000 kommen - meines Wissens nach - zwei Algorithmen zum Einsatz, um die Menge der Zugriffsrechte auf ein Objekt (Anwendung / Datei) zu bestimmen. Zum einen erfolgt eine Rechteprüfung so eines Prozesses in Bezug zu einem spezifischen Objekt über den Funktionsaufruf: „GetEffectiveRightsFromACL-Operation“, welcher dann wiederum über einen sog. „AccessCheck“ (Berechtigungskontrolle) des zugreifenden Subjektes (Anwender) gegengeprüft wird.

Cosmo erklärte Folgendes:

Zitat

[...]daß einige Programmierer die Unart haben, die Einträge für das Startmenü nicht unter All Users zu installieren, sondern im Startmenü des installierenden Benutzers (das ist übrigens auch bei der RunAs-Methode der Admin, nicht der angemeldete Benutzer).[...]

Startmenü-Einträge stellen bloss Verknüpfungen zu sog. „Objektdeskriptoren“ (Anwendungen) dar, welche auf einem NTFS-System durch die entsprechenden Gruppenrichtlinien (Eigentümer / Objekttyp / Zeitstempel / etc.) - über „Zugriffslisten“ - definiert werden. Der Installationsort selber, hat deshalb nichts mit den Unarten einzelner Programmierer, sondern eher mit den Domänen neu eingerichteter Anwender zu tun. Aus diesen Sicherheits-Gründen gibt es auch keinen „XP-Haupt-Benutzer“, der gleichzeitig in der Domain bzw. der ADS definiert wäre.

Cosmo stellte Folgendes i.F.:

Zitat

[...]ändert kein Jota daran, daß der [XP]-Hauptbenutzer ausreichende Rechte hat, um das System zu kompromittieren und MS davon ab rät, den Hauptbenutzer zu verwenden.[...]

Noch einmal. Der eigentliche XP-Systembereich (über Admin), bleibt vor dem „Hauptbenutzer“ (Power-User) geschützt. (s.u.).

Oliver

http://www.microsoft.com/resources/docu…t_settings.mspx

Cosmo stellte Folgendes dar:

Zitat

[...]Das Problem, aus dem wohl das genannte Mißverständnis folgt, besteht darin, daß einige Programmierer die Unart haben, die Einträge für das Startmenü nicht unter All Users zu installieren[...]

Unsinn. Installations-Ordner sind auf einem System nur genau dann frei wählbar, sofern so einem Subjekt (also der entsprechende Benutzer / Hauptbenutzer) im Vorfeld bereits die Rechte für so eine (temporäre) Installation von Objekten (Programmen / Anwendungen) eingeräumt wurden. Solche Rechte werden i.d.R. bereits im Vorfeld definiert. Die spätere Zugriffsregelung auf solche Programme / Anwendungen würde dann über eine separate Zugriffsliste (ACL) erfolgen. Programmierer haben mit Deinem genannten Installations-Verfahren nichts zu tun.

Cosmo erklärte darüberhinaus Folgendes:

Zitat

[...](Ach, und vergiß den "Hauptbenutzer", das ist ein Typ, der aus Kompatibilitätsgründen zum alten NT4 geschaffen worden ist und davon abgesehen keine Daseinsberechtigung hat. Ein Hauptbenutzer hat soviel Rechte, daß er das System ebenso effektiv kompromittieren kann wie ein Admin[...]

Auch das ist falsch. Ein Hauptbenutzer unter XP kann - nach meinem bisherigen Wissen - nur solche Anwendungen installieren, die keine Veränderungen an den Betriebssystemdateien selber vornehmen. Obendrein kann so ein HB - im Gegensatz zum Admin – auch keine System-Updates einspeisen und u.A. auch nicht auf Prozess-Prioritäten des Systems selber einwirken. Es gilt daher immer noch: (XP) Admin > Hauptbenutzer.

Oliver

Nemisis fragte Folgendes?

Zitat

[...]Also kann ich davon ausgehen das FF als Standard-User nur in seinem eigenen Ordner wie zuvor genannt L/S hat?

Richtig - sofern Du unter XP „Objektschutz“ (also Zugriffsschutz auf Dateien/Ordner) betreibst, muss auch der FF diesen Systemvorgaben folgen. Der sog. „XP-Standard-User“ (Benutzer) ist jedoch - bezüglich der Ausgestaltung seiner einzelnen Rechte - über die Gruppenrichtlinien individuell definierbar. Das Betriebssystem würde dann zur eindeutigen Konten-Identifikation sog. „Deskriptoren“, sowie auch „Identifikatoren“ verwenden.

Du bist somit nicht an die vordefinierten XP-Konten-Vorgaben selber gebunden, sondern kannst dem „Hauptbenutzer/Benutzer“ über eine Zugriffskontrolle (ACL) gesonderte Privelegien zuweisen.

Oliver

Schnubbie erfragte Folgendes:

Zitat

[...]also hat einer ne idee wie man das lösen kann? bei fragen und unklarheiten einfach fragen.

Nimm es mir nicht übel - aber was hälst Du davon zu Mutti zurückzukehren und Deine Hausaufgaben ordentlich zu machen, statt dieses Forum mit unsinnigen Anfragen in Anspruch zu nehmen? Du hattest Dich - meiner Ansicht nach - bereits schon bezüglich Deiner obigen Anfrage hin disqualifiziert...

Oliver

Dr. Evil fragte Folgendes:

Zitat

Was meinst du mit Pseudonym und codierter Korrektheit?[...]

Ein an eine ausländische CA gestellter Zertifikats-Antrag (über Pseudonym) muss - nach meinem bisherigen Wissen – nicht zwangsläufig über das deutsche (bzw. europäische) SigG selber geführt werden, um dennoch eine (ausländische) „digitale Beglaubigung“ zu erhalten, welche dann im Browser als valid dargestellt werden würde.

Solche Zertifikats-Anträge sind definitiv nicht an ein Land gebunden. Gerade bei CA´s, welche aus unterschiedlichen, überregionalen administrativen Domänen stammen, wird dieses Problem vordringlich. (siehe die neuen Reisepässe (RFID-Chips)).

Was die „codierte Korrektheit“ angeht, so gelten - nach meinen bisherigen Informationen - obendrein unterschiedliche internationale Hashwertbestimmungen i.B. auf solche Zertifikate.

Als letzte Inztanz kann immer nur der einzelne (teilw. unbedarfte) Anwender für sich entscheiden...

Oliver

Dr. Evil stellte Folgendes dar:

Zitat

Bzgl. SSL und MITM: das wird über das Zertifikat verhindert.[...]

Nein, es wird dabei bloss eine sog. „sitzungsgebundene“ pro-forma-Sicherheit im Browser geschaffen.

Jeder beliebige Zertifikatsteilnehmer - unterhalb CA (Trust Center) - kann i.d.R. seine eigenen digitalen Beglaubigungen gemäss X.509(v3) auch ungeprüft als Pseudonym ausstellen lassen. Der Ursprungsnachweis solcher Antragssteller kann somit gegenüber der zertifizierenden Instanz nur eine „beschränkte“ Aussagekraft besitzen. Obendrein wird - nach meinem bisherigen Wissen - nur die zeitliche Gültigkeit - nicht jedoch die codierte „Korrektheit und Zuverlässigkeit“ solcher Zertifikate überprüft.

Darüberhinaus haben einige überregionale Zertifikatsteilnehmer durch eine schwächere Signaturgesetzgebung ihrer Herkunftsländer oft wesentlich geringere Sicherheitsstandards - bezüglich der Ausstellung von Zertifikaten - zu erfüllen.

Oliver

XtC4UAll zitierte Folgendes :

Zitat

Palli hat geschrieben:Entscheidend ist nicht ob die Seite verschlüsselt ist, sondern ob deine Daten verschlüsselt übertragen werden.

Entscheidend ist dabei eher die Tatsache, ob die sog. HTTPs-Kommunikationsendpunkte (also Server (Shop) - Client (Anwender)) wirklich als das authentifiziert werden können, was sie vorzugeben scheinen.

SSL-Verschlüsselungsverfahren stellen den Weg dar und nicht das Ziel. Die Verschlüsselung endet daher beim SSL-Endpunkt (Kommunikationspartner) selber. Dieses Verfahren könnte somit über einen MITM-Angriff kompromittiert werden. Man kann es nicht oft genug wiederholen...

SSL (über HTTPs) auf der Transportebene des OSI-Modells selber kann – meines bisherigen Wissens nach – keine wirklich vertrauliche Kommunikation (über Handshake / Record) zwischen zwei anonymen Kommunikationspartnern gewährleisten.

In der Praxis geht "es" jedoch meistens gut...

Oliver

bjornie fragte Folgendes:

Zitat

Tolle Idee. Und wie soll ich dann von extern auf den Router zugreifen?[...]

Soweit ich Dich hier richtig verstanden habe...

a. Bist Du i.d.L. Deinen Router extern über ein sog. „Echo-Request“ anzupingen? Ist diese Funktion abgeschaltet?

b. Wurde die vom Provider extern zugewiesene IP-Adresse bereits in Deinen Router eingetragen?

c. Betreibst Du über Port 80 einen eigenen Server?

d. Benutzt Du Windows?

e. Stimmt die Zeitsynchronisation zwischen Client, Router und Server überein?

f. Hattest Du im Router eine HTTPs Portumstellung (von 443) vorgenommen?

Zu Punkt d., könnte es bei Dir u.U. erforderlich werden, in den Netzwerkeinstellungen des Windows-Systems den DHCP-IP-Adressbezug ausschalten - eine feste IP - bzw. auch einen Standardgateway - sowie auch eine Subnetzmaske (also die physikalische Netzstruktur, unter logischer Zusammenfassung einzelner oder mehrerer Stationen zu einem Subnetz) systemtechnisch zuzuweisen.

O.T.
DHCP-Client stellt Broadcast-Anfrage (in das Netzwerk) nach neuer IP-Adresse > Antwort eines DHCP-Servers, und zwar unter Zuweisung der ersten möglichen IP-Adresse > „Acknowledgement“ dieser Vergabe durch entsprechenden DHCP-Server an andere DHCP-Server > zeitlich befristete Vergabe (also „geleaste“) IP-Adresse, welche dann jedoch nur bis zum regulären Time-Out ohne weitere Extention dieses zuweisenden Servers, gültig ist. Nichts weiter als Maschinenkommunikation...

Oliver

Chaltre erklärte Folgendes:

Zitat

[...]Wenn ich mit Firefox (3.5.2) arbeite, […] werde ich nach 5 sek. immer ausgeloggt[...]

a. Lässt Du auf Deinem System zeitlich beschränkte Cookies zu? Lässt Du überhaupt irgendwelche Cookies zu?

b. Benutzt Du einen lokalen System-Filter-Proxy (z.B. Squid, Proxomitron, etc.), der Zugangsformulare über JS beeinträchtigen könnte?

c. Wieviel RAM (Hauptspeicher) wurde bei Dir als Netto-Nutzlast für Anwendungsprogramme (u.A. auch für den FF) verbaut?

d. Wurde Dein OS i.B. der Speicherverwaltungsmechanismen auf die System-Auslagerungsdatei (Swap-File) hin optimiert?

e. Hattest Du Dein (Windows)-System zwischenzeitlich einmal neu gestartet?

Firefox nutzt – meines bisherigen Wissens nach - einen skalierbaren (variabel anpassungsfähigen) Hauptspeicherbereich des zur Verfügung stehenden Gesamt-Systems. Dieser flexibel reservierte RAM-Adressraum kann jedoch - im Zuge der kontinuierlichen Nutzung des FF´s - überproportional anwachsen. In diversen Foren wird diese Eigenschaft eher als Fehler gekennzeichnet. Die Memory-Usage (Hauptspeichernutzung) des Firefoxes lässt sich jedoch primär über die about:config einschränken und sekundär über die virtuelle Speicherverwaltung des zugrundeliegenden OS selber erweitern.

Oliver

http://kb.mozillazine.org/Reducing_memory_usage_-_Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=490163#c34
https://wiki.mozilla.org/Releases/Firefox_3.5.2

PvW erklärte Folgendes:

Zitat

Alle Browser sind ziemlich so sicher,wie das System/die Einstellungen , das/die Du verwendest.[...]

Richtig. Deine Darstellung gilt - meinen bisherigen Erkenntnissen nach – jedoch nur für solche trojanischen Einwirkungen (Viren), welche auf Grund zu liberal definierter Freiheitsgrade einzelner Subjekte (Anwender) direkt auf das System (OS) zugreifen könnten. Solche trojanischen Einwirkungen liessen sich i.d.T. durch Einschränkungen der Systemschreibrechte (Subjekte) > (Objekte) (z.B. über zweidimensionale ACL´s / bei Mehrbenutzersystemen) sinnvoll einschränken.

Nur wie verfährst Du dagegen mit trojanisch präparierten URL´s, welche über das TCP-Protokoll selber generiert und dann im Anschluss browserintern als „integer“ (unbeeinflusst) dargestellt werden? Der entsprechende Browser (egal welcher) stellt dabei doch bloss einen protokollunabhängigen Kommunikationsendpunkt selber dar. Diese Form der Kompromittierung, gilt inzwischen vordringlich auch für internetfähige PDA´s und Handy´s.

Dr. Evil stellte Folgendes dar:

Zitat

[...]Da hat der Browser nämlich falsche Informationen angezeigt, (egal) welche Webseite er anzeigt und ob die Verbindung zu ihr verschlüsselt ist.

Dem ist - meiner Ansicht nach – zuzustimmen, sofern Du „Browser“ als „Allgemein“ meintest. Die bisherige SSL-Zertifikation ist – meines bisherigen Wissens nach - als browserunabhängig zu betrachten, da die übertragenen Datenpakete über TCP nicht signiert werden und somit auch keine wirkliche Verbindlichkeit von Aktionen selber vorliegt. Selbst reservierte SSL-Ports (über Socks-Bypass) würden keinen Sicherheitsgewinn bringen können.

Ich glaube wir brauchen keinen neuen Browser – wir brauchen ein neues SSL-Protokoll...

Oliver

Truempi erklärte Folgendes:

Zitat

[...]wenn ich sie [harzflirt.de] aufrufe, werde ich immer auf http://www.berlinflirt.de umgeleitet.[...] ich benutze antivir premium security suite,[...]kann es vielleicht mit meinem spanische internetanbieter vodafone zusammen hängen?

Nein, denn die britische Vodafone Group ist als ISP (Internet Service Provider) rechtlich nur gegenüber der Bereitstellung einer sog. Internet-Konnektivität (also Internet-Verbindung) selber verpflichtet. Diese „Konnektivität“ ist darüberhinaus technisch bloss durch den Transfer von IP-Paketen in und aus dem Internet gekennzeichnet und hat somit nichts mit einer separaten Einspeisung von Werbung, bzw. einer Umlenkung (Detour) auf diverse Webseiten selber zu tun. Deine Vermutung einer Werbeeinspeisung, bzw. auch einer Umlenkung der aufgerufenen Webseiten durch Einwirkung des ISP´s, wäre darüberhinaus - nach meinen bisherigen technischen Erkenntnissen – in dieser Form nicht umsetzbar.

Platt ausgedrückt: Wäre Vodafone (als Zugangsprovider) für den Betrieb und die Aufrechterhaltung einer „Wasserstrasse“ selber zuständig, so könnte dieser Provider nicht auch noch dafür haften, was auf seiner Wasserstrasse alles transportiert wird - ausser er wurde bereits im Vorfeld über einzelne Gefahrentransporte in Kenntnis gesetzt, für die er dann jedoch haften müsste. § 88 (Kollision zwischen „Kontrolle“ und „Schutz“ des normierten Fernmeldegeheimnisses). Ist z.Z. ein umstrittener Brennpunkt in Germany.

Die von Dir genannten Werbebanner, bzw. "Verbiegungen" von Aufrufen werden i.d.R. durch JavaScript, wie auch Flash 10 selber generiert. Malware kann darüberhinaus nicht ausgeschlossen werden. Im Quellcode-Header-Bereich einer solchen Web-Seite sollten obendrein Informationen über die technischen Anforderungen so einer Seite selber stehen.

Versuche es zur Probe einmal mit folgenden Malware-Scanner:

http://www.malwarebytes.org/mbam.php

Oliver

Das Zertifikats-Vertrauenssystem - also die sog. Ketten-Zertifikatsbeglaubigung - (gemäss PEM / X.509 Spezifikation) - ist in Deutschland streng hierarchisch gegliedert. Der gemeinsame Vertrauensanker wird dabei durch ein Wurzel-Zertifikat (Root Certificate) gebildet. Dieses allgemeingültige Root-Zertifikat wird in Deutschland von der Telekom AG selber ausgestellt, unterliegt jedoch der deutschen Bundesnetzagentur (B-Netz A / eh. Reg TP) - und zwar als übergeordnete behördliche Instanz.

Ein Schelm, der – meiner Ansicht nach - vor dem Hintergrund dieser Abhängigkeiten an „staatlichen Protektionismus“ denken würde. Behörden reagieren i.d.R. langsam (an der Technik vorbei). Obendrein würde so ein Root-Zertifikat erst in Mozilla Firefox 3.X importiert werden müssen, um dann für diesen Browser die notwendige Qualifikation elektronischer Signaturen als rechtsverbindliches Äquivalent (Gleichwertigkeit) zur handschriftlichen Signatur - auf Basis elektronischer Geschäftsprozesse - selber zu gewährleisten.

Wäre es in Folge dessen für die Mozilla-Foundation nicht auch möglich, eine eigenständige und überregionale Root-Zertifizierung innerhalb des Browsers - bzw. auch des E-Mail Clients selber zu integrieren, ohne ein solches nationales Root-Zertifikat erst aufwändig importieren zu müssen?

Gründe welche – meiner Ansicht nach – dafür sprächen wären u.A.:

a. Der überregional hohe „Verbreitungsgrad“ der Mozilla-Produkte.

b. Die technische „Expertise“, wie auch die „Reaktionsgeschwindigkeit“ der Mozilla-Organisation i.B. auf Sicherheitslücken ihrer Produkte.

c. Die allg. positive Reputation der Mozilla Produkte i.B. auf ihre sicherheitskritischen Anwendungen.

d. Die „Mozilla Corporation“ (als steuerpflichtiges Unternehmen), könnte darüberhinaus elektronische Verträge z.B. mit Online-Banken eingehen, welche dann wiederum einen Teil ihrer eigenen Zertifikatsinfrastruktur an die Mozilla-Corp. - gegen Bezahlung - auslagern könnten.

Frage wäre - einer Meinung nach - dabei bloss, ob dieses Verfahren der Mozilla-GPL-Ideologie als Fernziel entgegenstehen würde. Was meint ihr?

Oliver

Scheiksjarbier stellte Folgendes dar:

Zitat

[...]die (Passwort)-Daten werden aber nicht (im FF 3.5.1) validiert, und als Fehlermeldung kommt immer "Falsche Dateneingabe".

Vertrauliche, passwortbasierte Zugangskontrollen werden – nach meinen bisherigen Erkenntnissen - im Online-Sicherheitsbereich i.d.R. servergeneriert. Das dazugehörige LogIn-Prompt (also Dein Passwort) hat - als clientseitige Gegenstelle so einer Authentifikation - weder etwas in Deinem Browser – noch etwas auf Deinem System selber zu suchen. Man kann es eigentlich nicht oft genug wiederholen...

a. Lässt Du Deine vertraulichen Passwörter im Firefox automatisch speichern? Diese Option (Datenschutz - Passwörter ) ist im Browser glücklicherweise abwählbar und definitiv auch nicht als Ablage solcher vertraulichen Authentifikationen zu empfehlen.

b. Hattest Du in der Vergangenheit einen Systemwechsel auf Windows-Vista vollzogen und dabei Dein ursprüngliches Profil beibehalten? Unter Vista wird der ursprüngliche Administrator i.B. auf seine System-Schreibrechte hin reduziert.

c. Einige sicherheitsrelevante Webseiten unterbinden darüberhinaus sinnvollerweise das Speichern von Login-Daten und zwingen somit den Anwender zur Neueingabe der entsprechenden HTTP(s)-Authentifizierung (z.B. über .htaccess/SSI/PHP).

O.T
Das sog. S/Key-Verfahren (One-Time-Password / z.B. bei Telnet-Verbindungen) könnte – meiner Ansicht nach – i.B. auf seine „Einwegeigenschaft“ eventuelle „Maskierungsangriffe“ zwischen Client und Server deutlich erschweren, da sich am herkömmlichen Authentifikationsablauf zwar nichts ändern, die resultierenden Passwörter jedoch nur einmalig verwertbar wären. Solche vertraulichen Passwörter wären dann im Voraus serverseitig generierbar – und zur späteren Verwendung (offline) ablegbar.

Oliver

Zitat

1. wie kann ich im bios oder zumindest im betriebssystem die funktion zum steuern der bios einstellungen (z.b. wlan on or off) oder dem hinzufügen von informationen deaktivieren.

Im BIOS unter dem jeweiligen Sekundär-Menü:

Advanced BIOS Setup
Advanced BIOS Features
Advanced Settings
Standard CMOS Features

die „BIOS Protection" aktivieren. Das BIOS gilt dabei – im Zuge des „Bootstrapping“ - als zweite „Verifizierungsinstanz“ für sicheres Booten auf Basis der TCP Spezifikation.

ROM > BIOS > MBR > Boot-Block > OS-Kernel

Sofern entsprechendes Mainboard vorhanden, kann – nach meinem bisherigen Wissen – eine initiale CRTM-Hashwertberechnung des ROM´s in das Register PCR geschrieben werden, welche dann als Ausgangspunkt für eine fortschreitende digitale Verifikation gilt und somit die sog. Vertrauenskette (Root of Trust) bildet.

Oliver

Melli2701 stellte u.A. Folgendes dar:

Zitat

[...]ch befürchte nämlich ernsthaft, dass jemand in unserem Haus war, und ich kann Dir sagen, dass das kein besonders schönes Gefühl ist![...]

a. Welches Betriebssystem benutzt Du?

b. War der Computer zwischenzeitlich (oder bevor Du ihn erhieltst) in anderem Besitz? (z.B. ein Gebraucht-Notebook).

c. Hattest Du das Betriebssystem bereits fertig vorkonfiguriert übernommen oder selber initialisiert?

d. Hattest Du in der Vergangenheit Programme installiert, deren Ursprünge sich nicht genau verifizieren lassen?

Könnte es sein, dass auf Deinem System im Vorfeld ein Terminaldienst (also ein Remote-Fernzugriff) installiert wurde, welcher über Schreibrechte auf Dein System (also somit auch auf Deinen Desktop) zugreifen kann? Mit einer solchen „Remote-Desktop-Software“ liessen sich dann die jeweils angeschlossenen Rechner (Clients) aus der Ferne administrieren – bzw. auch beobachten. Windows bietet für zahlreiche solcher Programme, bzw. Derivate solcher Programme, eine ideale „Plattform“. Es gab in der Vergangenheit bereits einige Trojaner (Viren) die so etwas unter Win98 ganz gut konnten. Konkret ginge es dabei um Subjekte (Anwender), welche i.d.L. wärem, über Objekte (Remote-Access), auf Systeme zuzugreifen.

Sofern Du b-d verneinen kannst, würde ich allerdings – nach meiner hiesigen Beurteilung - einen Wechsel Deines Haustürschlosses ernsthaft in Erwägung ziehen.

Sofern Du Windows benutzt, versuche unter Angabe von netstat -an die MS-DOS-Eingabeaufforderung zu starten und poste die Protokollstatistik der geöffneten Ports im Anschluss in diesem Forum.

Oliver