Hallo zusammen,
ich habe gestern meinen neuen KVM-vServer mit dem Ubuntu 12.04 LTS Image neuinstalliert.
Um die Installation auszuführen, musste ich mein VCP-Passwort eingeben.
Hierbei habe ich festgestellt, dass das Passwort nach Absenden des Formulars im Klartext per HTTP-GET Parameter übermittelt wird! 
Mal abgesehen davon, dass Passwörter aus naheliegenden Gründen niemals per HTTP-GET übermittelt werden sollten, wird bereits an diesem Problem gearbeitet?
Bitte um kurze Info...
emm-jott
An dem Problem wird gearbeitet. Sollte noch heute behoben sein.
Vielen Dank für Ihre Aufmerksamkeit und den Hinweis.
Man kann auch mit Java Script einen hash erzeugen. Es wäre also nicht einmal nötig das pw via Post im Klartext zu versenden.
Das Passwort wird nun per POST übertragen. Danke nochmals für den Hinweis!
@sim: Prinzipiell ist das ein guter Ansatz, allerdings wird das Passwort im VCP noch "gesaltet" und der Salt soll ungern nach außen bekannt werden.
Okay, das wäre natürlich nicht schön wenn der im JS Code stünde. 
Moin
felix: Ein Salt kann problemlos veröffentlicht werden. Das schmälert seinen Wert in keiner Weise.
Da das VCP per https erreichbar ist, braucht es aber eh keine clientseitige Hashfunktion des Passwortes. Die soll ja nur die Klartextübertragung verhindern.
Im übrigen kann man den Salt auch von bekannten Daten ableiten. Er müsste also nicht mal übertragen werden.
Mordor
Mordor: Das sehe ich anders. Der Sinn eines Salt geht zu einem großen Teil verloren, wenn dieser bekannt ist. Natürlich ist die Rückwandlung eines Hashes deutlich komplizierter wenn ein Salt zu dem Passwort noch öffentlich gesetzt wird, dennoch ist es sicherer wenn der Salt nicht bekannt wird. Einen Salt setzt man ja um zu verhindern das das wirkliche Passwort gefunden wird, sollte z.B. ein unberechtigter Zugriff auf die Datenbank möglich geworden sein.
Moin
Die Rückwandlung eines Hashes zum ursprünglichen Klartext ist nicht möglich. Selbst bei MD5 geht das nicht und das ist eines der schwächsten Verfahren.
Es ist nur möglich, per Brute Force einen beliebigen Klartext zu finden, der dann den gesuchten HASH ergibt (Kollision).
Der Salt wird verwendet, um einen Angriff auf die Passworte mit Hilfe von Rainbow Tables zu verhindern (und nur dazu dient meinem Verständnis nach ein Salt).
Also das für eine Liste von Hashes nur einmal ein Angriff erfolgen muss, und dann für alle Hashes ein zugehöriger Klartext aus einer Tabelle abgelesen werden kann.
Denn das würde den Aufwand für einen Angriff deutlich reduzieren, wenn die Zahl der angegriffenen Hashes groß genug ist (wie bei MD5 geschehen).
Damit ein Salt funktioniert, muss jeder Account einen eigenen Salt erhalten, der natürlich bekannt sein muss. Der Salt wird deshalb üblicherweise zusammen mit dem Hash gespeichert.
Hat der Angreifer Zugriff auf den Hash, kennt er normalerweise auch den Salt (oder kann ihn sich verschaffen).
In der Praxis erhält man durch den Salt (vereinfacht gesagt) ein längeres Passwort und dadurch verlängert sich dann auch der Rechenaufwand für einen BF-Angriff (Ich schätze, darauf spielen Sie an).
Der Rechenaufwand wird aber nicht geringer, nur weil der Salt bekannt. Das geht ja trotzdem bei jeden Versuch in die Berechnung mit ein.
Für einen Angriff von außen (regulärer Login, ohne Kenntnis des Hashes) ist der Salt sowieso wertlos. Der berechtigte User meldet sich ja auch nur mit dem Passwort an.
In dem Fall bringt ein Salt also keinen Sicherheitsgewinn und eine Veröffentlichung schadet nicht, da der Salt für die Anmeldung nicht gebraucht wird.
Mordor
