Christian Dinse bloggt.

Mir ist ja bewusst, dass man sensible Passwörter nicht im Browser speichern sollte, aber wieso Firefox auch in der aktuellsten Version diese Dinger noch immer in Plaintext (ohne Schutz) speichert, bleibt ein Rätsel.

Szenario:
- Google Chrome installiert
- Frage “Daten aus Firefox importieren”
- alles, auch gespeicherte Passwörter sind da

Gleicher Test, aber mit gesetztem Masterpasswort in Firefox:
Google Chrome hat alles importiert, aber keine Passwörter (gut!).

Sicherlich ist für ein automatisches Ausfüllen von Formularen der Plaintext unumgänglich, dennoch kann man aber auch dieses für Aussenstehende schwieriger auslesbar machen, in dem man die sensiblen Daten hashed, den zughöriger Schlüssel aber auch parat hat. Klingt wieder genauso unsicher, macht aber dann Sinn, wenn der Schlüssel auf Basis einer Zufalls-ID, dem Betriebsystem/Uhrzeit/irgendwelcher Profildaten des Benutzes am System/etc. erzeugt wurde.

Was man dann natürlich nicht machen darf (als Hersteller des Browsers) ist, die Funktion offen zu legen, wie der Hash erzeugt wurde bzw. wie genau er anzuwenden ist. Auch die Stelle, an der man den Hash findet sollte “geheim” bleiben. Es gibt zahlreiche Stellen, an denen man solche Dinge gut verstecken kann. Nichts spricht gegen ein Reinkompilieren (während der Installation) des Hashes in eine Datei des Browserpaketes.

Generell macht sich über sowas aber keiner Gedanken. Das höchste ist ja schon, wie man Maleware, selbst vom Browser, besser erkennen lassen kann. Schade, irgendwie.

An die Experten: Bitte schaut am Ende dieses Beitrags auf meine beiden Fragen, vielleicht hat irgendjemand eine Lösung. Danke!

Nachdem der Bau des Hackintosh und einige Kinderkrankheiten (_CFGetHostUUIDString) beseitigt wurden, gab es in den vergangenen Wochen eigentlich nichts zu meckern. Die neue Grafikkarte (GeForce 8800GT) hat die Kiste auch problemlos geschluckt.

Ich arbeite generell nur noch mit S-ATA. Alternative Betriebssysteme sind allerdings auf einer älteren IDE-Platte noch im Rechner vorhanden, manchmal muss man eben doch Switchen.

Vor ein paar Tagen begann das System damit, Ärger zu verbreiten. Eine angeschlossene IDE-Festplatte (mit Windows XP) wurde zuerst unter OS X und innerhalb einiger Stunden auch nicht mehr vom Rechner selbst erkannt. Ich schob es auf einen gewöhnlichen Hardwareausfall (die Platte ist einige Jahre alt und es gibt bereits eine defekte, der selben Charge).

Ich schloß eine andere Festplatte an, um Windows neu zu installieren. Erstaunlicherweise wurde eben diese Platte mit den selben Syntomen vom System ignoriert (Bezeichnung der Platte im BIOS wird nicht korrekt, sondern in Form von Sonderzeichen und ähnlichem dargestellt).

Die Vermutung, dass die erste Platte garnicht kaputt ist, bestätigte sich unmittelbar in verschiedenen Tests.

Als Fehlerursache konnte das Mainboard Asus P5W ausfindig gemacht werden, und dessen IDE-Anschluss, an dem neben der Platte, auch ein DVD-Brenner hängt. Im Nachhinein könnte das auch die Ursache für eine Reihe von fehlerhaft gebrannten DVDs sein. Ich sage deshalb “könnte”, weil die Geschichte noch nicht vollständig abgeschlossen ist.

Nach dem Entfernen aller IDE-Laufwerke bootete das gesamte System nicht mehr. Es blieb direkt beim Einschaltbild des PC (ASUS-Logo-Screen mit BIOS-Hinweis) stehen, und wollte sich aus diesem Zustand auch eine Weile nicht erholen.

Ein BIOS-Reset sorgte für Aufatmen, denn danach startete die Kiste wieder durch. Nachdem alle nötigen Einstellungen im BIOS wieder getätigt waren, lief das System wieder sauber.

Aktueller Stand:
Alle IDE-Laufwerke aus dem System entfernt. Ich habe für rund 20 Euro einen S-ATA-DVD-Brenner von LG bestellt, welcher bereits heute versendet wurde. Mehr als beobachten lässt sich das Problem des Rechners derzeit nicht, denn seit dem Entfernen der IDE-Geräte gibt es technisch keine Einschränkungen mehr.

Problemansatz:
Aktuelle Mainboards sind zwar durchaus in der Lage, S-ATA und IDE parallel zu betreiben, allerdings könnte der eingestellt AHCI-Modus für IDE-Festplatten ein Problem darstellen. Ich habe derzeit keine Details zu dieser Vermutung (von einem Kollegen) greifbar, bin aber für Hinweise dankbar.
Gegenfrage ist aber sofort: Das System lief einige Monate prima mit S-ATA und IDE parallel, wieso sollte von Heute auf Morgen die AHCI-Einstellung ein Problem auslösen?

RAM ist nicht mehr komplett nutzbar
Das BIOS zeigt seit dem Reset noch immer sauber 4 GB RAM an, weist allerdings etwa 1 GB davon als nicht verfügbar aus, und stellt etwa 3,2 GB als frei nutzbar dar. Ziemlich genau die Menge, die man in 32-bit-Systemen addressieren kann. Unter OS X sind neuerdings auch nur noch 3 GB verfügbar. Hat irgendjemand eine Ahnung, wie die passiert sein könnte?

Wie kürzlich berichtet, gibt es mit so gut wie allen Seagate-Festplattenmodellen technische Schwierigkeiten.

Unter dem Support-Link stehen nun auch aktualisierte Informationen zur Verfügung, welche Festplattenmodelle tatsächlich vom Problem betroffen sind.

Laut Liste sind die Laufwerke ST3500320AS, ST3640330AS, ST3750330AS und ST31000340AS aus der Reihe Barracuda 7200.11 mit der Firmware SD15, SD16, SD17, SD18, SD19 oder AD14 fehlerbehaftet. In diesem Fall empfielt Seagate eine Aktualisierung der Firmware auf Version SD1A.

WICHTIG
Alle anderen Modelle der Reihe Barracuda 7200.11 sollen nur von dem Fehler betroffen sein, wenn sie nicht mit einer “CC- oder LC-Firmware” arbeiten. Ein Firmware-Update hierfür ist noch in Arbeit.

MIRROR
Hier ist ein Mirror der aktuellen Knowledge-Base-Seite von Seagate mit der Software zum Testen und dem Firmware-Update.