Ungesalzene Passworte

[fdasasdf]

Ich lese gerade, dass jetzt mit Last-FM bei einem weiteren größerer Dienst innerhalb von ein paar Tagen eine große Anzahl von ungesalzenen Passworten entwendet wurde.

Das ist doch wirklich unglaublich, seit mindestens 10 Jahren sollte doch Allgemeinwissen unter Entwicklern sein, dass Passworte mit Salt versehen sein müssen. Das ist ja auch wirklich nicht schwer zu implementieren. Was denken sich diese Entwickler eigentlich?

 

[d3p]

[...]Was denken sich diese Entwickler eigentlich?

Wahrscheinlich nichts, sonst wäre es ja implementiert gewesen.

 

[PapaBaer]

Punkt 1: Hier hat niemand was von Klartext-Passwörtern geschrieben

Punkt 2: Selbst wenn man das Salt "öffentlich" ablegt, fallen damit die schnellen Angriffe über Rainbow-Tables aus. Man muss sich dann nämlich erst eine komplette Tabelle berechnen für das konkrete Salt, und das dauert. Was das alles mit Hash-Kollissions zu tun haben soll, ist mir ein Rätsel. Die hat man mit Salt genau so oft wie ohne, weil der Hash selbst ja nicht länger wird.

 

[PapaBaer]

Und? Auch das was Heise schreibt ist vollkommen korrekt.

 

[PapaBaer]

Vielleicht stell ich mich gerade zu doof an, aber ich sehe deinen Punkt nicht. Was stimmt an der Verknüpfung von Heise und diesem Thread nicht? Ist doch alles korrekt. fdasasdf hat doch vollkommen recht.

 

[tomasini]

Die Entwickler trifft hier wohl keine Schuld. Die würden das liebend gerne ordentlich implementieren. Es geht hier um Geld (bzw. Rendite). Wenn man Passwörter im Klartext ablegt, ist das schlicht am günstigsten, weil das am wenigsten CPU-Time kostet. Ich brauche also weniger Hardware (CPU-Cores).

Unter diesem Gesichtspunkt ist SHA1 mit Salt im Vergleich zu z.B. MD5 eine recht teure Geschichte. Skaliert man das Ganze dann noch auf ein paar Millionen User hoch, sind wir sehr schnell im sechsstelligen(+) Bereich an zusätzlichen Hardwarekosten.

 

[Joe User]

<OT>Fehlen in diesem Thread Posts, oder führte Papabaer ein Selbstgespräch, oder liegt irgendwo bei mir ein Fehler vor?</OT>

 

[PapaBaer]

Also vorhin stand da noch was zwischen meinen Posts. Oder nicht? Ein Arzt, ist ein Arzt an Bord? Ich mach mir Sorgen ...

 

[dotme]

Mit SHA1 lässt sich schlechter Geld verbrennen als mit FB

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              31134.83k    99775.25k   247644.42k   394289.15k   478598.49k
sha1             29368.06k    85419.84k   191978.15k   278281.56k   319913.98k

Schönen Freitag noch.

 

[TerraX]

Die Entwickler trifft hier wohl keine Schuld. Die würden das liebend gerne ordentlich implementieren. Es geht hier um Geld (bzw. Rendite). Wenn man Passwörter im Klartext ablegt, ist das schlicht am günstigsten, weil das am wenigsten CPU-Time kostet. Ich brauche also weniger Hardware (CPU-Cores). ...

Hmm, ich denke, dass ist gerade heutzutage eher weniger der Grund, zumal es sich bei einem Login um einen einmaligen Vorgang handelt, der auf die erzeugte Gesamtlast nur wenig Einfluss hat.

Ich denke eher, das hängt damit zusammen, dass der Focus der Entwickler primär auf den eigentlichen Funktionen der (Web-)Anwendung liegt. Sicherheit ist oft ein Thema, das irgendwie abhandelt werden muss und daher hin und wieder stiefmütterlich behandelt wird. Niemand steckt gerne viel Arbeitszeit in etwas, was keinen direkten (greifbaren) Nutzen bringt.

Und wenn eine Kösung erstmal ohne Komplikationen läuft, wird in diese Bereiche selten nochmal hinein geschaut.

 

[Joe User]

Das Problem liegt IMHO viel eher darin, dass die Entwickkler einfach blind zu irgendwelchen Bibliotheken mit möglichst primitiven APIs greifen, um den eigenen Code KISS zu halten. Diese Bibliotheken werden meist weder einem Audit unterzogen, noch werden sie regelmässig aktualisiert, denn "it just works".

Es ist das gleiche Problem wie in der (Open-Source-)Softwareentwicklung, wo man an allen Ecken und Kanten teils völlig veraltete mitgelieferte Bibliotheken findet (prominenteste Beispiele dürften wohl zlib und libpng/libtiff sein).

Letztendlich ist es reine Faulheit und Geldschneiderei seitens der Entwickler und weniger die Sparsamkeit der Teppichbodenetagen...

 

[fdasasdf]

Der Wunsch nach Einfachheit ist sicherlich verständlich und natürlich fragt - vorher! - auch kein Chef nach Sicherheit. Aber ein gewisses Mindestmaß an Verständnis erwarte ich schon bei halbwegs professioneller Softwareentwicklung. Und in den jetzt aufgedeckten Fällen (Linked-in, Last.fm) handelt es sich ja auch nicht um Schülerfreizeitprojekte.

Dass ein Entwickler als Nutzer einer Verschlüsselungsfunktion die Theorie hinter den Algorithmen nicht versteht oder dass möglicherweise ein 10 Jahre alter Algorithmus inzwischen nicht mehr sicher ist, ist eine Sache und für mich noch nachvollziehbar.
Aber dass so grundlegende Dinge wie Salt nicht beachtet werden, schockt mich dann schon. Eine sinnvolle Nutzung der Standardfunktionen der jeweiligen Programmierumgebung sollte doch drin und mit 5Min. googlen auch nicht schwierig sein.

 

[Joe User]

Salzen war zu Zeiten als diese Portale gegründet wurden schlicht nicht üblich und die Softwarebasis ist nur gewachsen, aber wurde nie auditiert oder gar komplett neu geschrieben. Die Dinger sind teils >10 Jahre alt und sind oft nichtmal Eigenentwicklungen, sondern auch nur irgendwo runtergeladene Scripte die damals halt "passten".

Sind halt die Schattenseiten von OSS...

 

[d4f]

Leicht OT, aber genau wie den Entwickler immer gepredigt wird starke Hashing-Algorithmen mit (variablem, zB der Benutzer-ID) Hash zu verwenden, wird den Besucher auch immer gepredigt keine Passwoerter mehrmals zu verwenden.

Es ist auf beiden Seiten schlicht Faulheit die verursacht dass es zusammen ueberhaupt zu einem Problem werden kann.
Keepass und die mobilen Varianten wie Keepassdroid zusammen mit Dropbox helfen effektiv die Probleme zu loesen. Denn man kann nie einer anderen Seite vertrauen, selbst wenn deren Hash-Algorithmus noch so sicher ist kann der Betreiber beispielsweise die Daten schlicht gewollt entwenden...