Password encrypton? [Archiv] - Zend Framework Forum

DennisBecker

12.06.2008, 09:48

In PHP mit md5(). Bei Zend_Auth kann man auch einen Parameter setzen, dass das Passwort automatisch als MD5 Hash umgewandelt wird, finde aber so auf einhieb im Manual kein Beispiel, aber Google sollte weiterhelfen.

[EDIT]
Nachdem ich KinCrunchs post gelesen habe verstehe ich jetzt erst die Frage richtig.

Man kann auch mittels JavaScript verschlüsseln und so das Passwort "gesichert" übertragen. Ob das direkt als MD5 möglich ist weiß ich nicht, bin kein JS Fachmann.

KingCrunch

12.06.2008, 10:02

Zu dem Thema bin ich per Google nur auf Paj's Home (http://pajhome.org.uk/crypt/md5/) (.. ;)) gestoßen. SSL ist aber wohl ehere die bessere Wahl, wenn es verfügbar ist.

steffen88

12.06.2008, 10:14

Danke erstmal für die hilfreichen antworten.

Wie macht ihr es in euren Professionellen Projekten?
Stellt das ein großes Sicherheitsrisiko dar, oder ist es unwahrscheinlich das cracker die Passwörter abfangen?

case

12.06.2008, 10:22

Man kann auch mittels JavaScript verschlüsseln und so das Passwort "gesichert" übertragen. Ob das direkt als MD5 möglich ist weiß ich nicht, bin kein JS Fachmann.:eek: *hände über dem kopf zusammen schlag* erzählt den leuten doch nicht solch gefährlichen unsinn...

der einzige weg die daten sicher zu übertragen ist die verschlüsslung des gesamten datenverkehrs! ob ich nun ein password im klartext oder dessen md5 (besser sha1) hash habe ist wurscht, so lange ich im besitz der kombination von account/password(hash) kommen kann (stichwort: man in the middle attack). es kommt also nur ssl in frage sobald schützenswerte daten zwischen webbrowser und webserver übertragen werden sollen. alternativ könnte man sich noch einen ssh tunnel bauen, aber das ist dann auch wieder ne reine bastel lösung...

case

12.06.2008, 10:23

Stellt das ein großes Sicherheitsrisiko dar, oder ist es unwahrscheinlich das cracker die Passwörter abfangen?siehste... geht schon los... :(

steffen88

12.06.2008, 10:35

siehste... geht schon los... :(

Hehe, was nützt einem das gehashte Password?
Damit kann er doch nichts anfangen oder?

Bleistift

12.06.2008, 10:46

Damit kann er doch nichts anfangen oder?

Doch... Weil man ja nur das gehashte Passwort für das Einloggen braucht.

Marco

12.06.2008, 10:48

klar für high-security-apps iss SSL pflicht
aber sonst, wenn du das pw in clientseitig js salzst und md5 hash'st sollte
es relativ safe sein.

oder nicht? jedenfalls kann es so keine rainbow attacken geben...
Seht ihr das anders?

gruß marco

// edit: man könnte ja auch dynamisch salzen. also beim ersten site load ein token
mitschicken, der dann in ner session am server tmp gecached wird :)

KingCrunch

12.06.2008, 10:50

Bleistift

12.06.2008, 10:51

// edit: man könnte ja auch dynamisch salzen. also beim ersten site load ein token
mitschicken, der dann in ner session am server tmp gecached wird :)

Das nützt alles nichts... Der Angreifer muss nur die Username/Hash-Kombination haben und kann das dann selber weiterreichen. SSL (am besten kein selbstsigniertes Zertifikat) ist die einzig sichere Methode.

case

12.06.2008, 10:58

ein bischen dokumentation zu diesem thema: "Man in the middle Attack" (http://de.wikipedia.org/wiki/Man-in-the-middle-Angriff)

steffen88

12.06.2008, 11:01

Doch... Weil man ja nur das gehashte Passwort für das Einloggen braucht.

Das wird in meiner anwenndung dann aber nochmals gehashed, und dann stimmt es ja nicht mehr.

Oder lieg ich da falsch?

Bsp

pw: test

als MD5: 098f6bcd4621d373cade4e832627b4f6

das MD5 als MD5: fb469d7ef430b0baf0cab6c436e70375

Marco

12.06.2008, 11:09

Das nützt alles nichts... Der Angreifer muss nur die Username/Hash-Kombination haben und kann das dann selber weiterreichen. SSL (am besten kein selbstsigniertes Zertifikat) ist die einzig sichere Methode.

ok, dass SSL standard ist, ist klar. Darüber braucht man nicht disktutieren,

aber ich behaupte, dass dynamische Login-Tokens ebenfalls rel. sicher sind. Die
Tokens müssen halt dann auch noch serverseitig in ner DB geloggt sein und
müssen nach einmaligen login ungültig werden.

damit der "erste Login" eines Users nicht entführt werden kann würde ich
user-individuelle Sachen abfragen und hashen (ip, browser, os).

ganz wasserdicht ist die Sache nicht, aber halt relativ gesehen schon :)

KingCrunch

12.06.2008, 11:12

Das wird in meiner anwenndung dann aber nochmals gehashed, und dann stimmt es ja nicht mehr.

Oder lieg ich da falsch?Du liegst falsch ;) Wenn man erwartet, dass das Passwort bereits gehasht ankommt, dann ist es nicht besonders pfiffig ein einfach gehashtes Passwort mit einem doppelt gehashtem Passwort zu vergleichen ;) Anders gesagt: Man implementiert die Konstruktion doch selbst. Wieso sollte das also hinterher ignorieren?

steffen88

12.06.2008, 11:23

Du liegst falsch ;) Wenn man erwartet, dass das Passwort bereits gehasht ankommt, dann ist es nicht besonders pfiffig ein einfach gehashtes Passwort mit einem doppelt gehashtem Passwort zu vergleichen ;) Anders gesagt: Man implementiert die Konstruktion doch selbst. Wieso sollte das also hinterher ignorieren?

ich glaube du verstehst nicht was ich meine.
Ich habe bleistift zitiert, weil er meint das ein angreifer was mit dem gehashten Passwort anfangen kann.

Nun stellt man sich vor, ich würde das password erst hashen (via js) und dann wegschicken.
Nun könnte der angreifer das gehashte pw anfangen, kann damit aber eingentlich nichts anfangen weil er das ja nicht im Login Formular eintragen kann, da es sonst doppelt gehashed wird.

verstehst du wie ich das meine ?

Marco

12.06.2008, 11:30

Daten ohne das original Login-Formular absenden ist ein Kinderspiel, dafür brauchst du
nicht die original Homepage.

ohne dynamische Tokens und Validations ist es unsicher.

KingCrunch

12.06.2008, 11:31

ich glaube du verstehst nicht was ich meine.
Ich habe bleistift zitiert, weil er meint das ein angreifer was mit dem gehashten Passwort anfangen kann.

Nun stellt man sich vor, ich würde das password erst hashen (via js) und dann wegschicken.
Nun könnte der angreifer das gehashte pw anfangen, kann damit aber eingentlich nichts anfangen weil er das ja nicht im Login Formular eintragen kann, da es sonst doppelt gehashed wird.

verstehst du wie ich das meine ?OK, jetz verstehe ich, da is aber ein Denkfehler drin: Dadurch, dass du das Passwort per JS hashen lässt, heißt noch lange nicht, dass es der Angreifer auch tut. Wenn er das Formular kopiert und die Hashfunktion entfernt, dann reicht es, wenn er das abgefangene gehashte Passwort verschickt. Das Ursprungskennwort braucht er dazu garnicht kennen.

steffen88

12.06.2008, 11:36

OK, jetz verstehe ich, da is aber ein Denkfehler drin: Dadurch, dass du das Passwort per JS hashen lässt, heißt noch lange nicht, dass es der Angreifer auch tut. Wenn er das Formular kopiert und die Hashfunktion entfernt, dann reicht es, wenn er das abgefangene gehashte Passwort verschickt. Das Ursprungskennwort braucht er dazu garnicht kennen.

Ok, bin noch jung in der Webentwicklung, hab nicht gewusst, dass das geht.

Ich werde mir SSL mal anschauen.

Wenn das nichts ist werde ich mir selbst einen algorhytrmus basteln, der eine tabelle von zahlen/buschtabenkombinationen generiert und diese dann wie beim itan verfahren abgleicht(im php script);)

case

12.06.2008, 12:33

Wenn das nichts ist werde ich mir selbst einen algorhytrmus basteln, der eine tabelle von zahlen/buschtabenkombinationen generiert und diese dann wie beim itan verfahren abgleicht(im php script);)less doch einfach mal den wikipedia artikel!

itan lösst das problem nicht, weil die daten auf der internet leitung zwischen dem user rechner(A) und deinem server (B) abgefangen werden können! der angreifer (C) leitet deine user anfrage nicht weiter und schickt ihm eine fehlermeldung. anschliessend sendet er von seinem rechner die user daten an deinen server und tut so als ob er der user wäre und schon sind deine daten in den falschen händen!

A ------- (anfrage) ------> C (freut sich) B (wartet)

A <------- (fehler) ------- C B (wartet)

A (huch?) C -- (modifizierte anfrage) --> B (ah, ein user)

A (wundert sich) C <---------- (daten) --------- B

DennisBecker

12.06.2008, 12:59

Mein Ansatz mit dem MD5 war nur ein Beispiel. Ich hab das mal mit einer AES oder Blowfish Verschlüsselung gesehen, damit das Passwort nicht im Klartext übertragen wird. Bei ReactOS.org kann man das optional auswählen beim Login.

steffen88

12.06.2008, 13:42

Den wikipedia artikel habe ich gelesen, ich denke das man es hinbekommen könnte, wenn man den code der nach dem gleichen algorhytmus auf dem server erzeugt wird, aber nur 5 sek gültig ist. Und bei jedem KLick auf Login wird eine neue 'tabelle' erzeugt.
Ist ein wenig verrückt und wahrscheinlich auch zu aufwendig, aber ich denke man könnte das ziemlich sicher machen.

Aber wie gesagt, bin noch ziemlich neu in dem Thema, und weiß nicht wie angreifer vorgehen.

KingCrunch

12.06.2008, 13:59

Die Tabelle muss allerdings der Alhorithmus im Client auch kennen, sonst ist es witzlos: Da gibts dann eine Tabelle, die nur der Server kennt. Zudem sind 5 Sekunden sehr arg begrenzt, aber jede größere Zahl ermöglicht wieder recht einfachen Einstieg für Angreifer. Man sollte im Hinterkopf behalten, dass Diese auch nicht alles per Hand tippen, sondern Programme dazu bemühen. Im Zweifelsfall bemerken diese garnicht, dass es eine Zeitbegrenzung gibt ;)

Aber wie gesagt, bin noch ziemlich neu in dem Thema, und weiß nicht wie angreifer vorgehen.Grundsätzlich ist es schwer zu entscheiden, ob Daten von extern sicher sind, oder nicht. Da gibts dann auch nicht viele Alternativen

steffen88

12.06.2008, 14:14

ja ursprünglich war eine zufallszahl gedacht, mit der der Algorythmus arbeitet, sonst würde ja immer das gleiche ergebnis rauskommen.

Diese zufalls zahl sollte beim klick auf login via ajax geladen und durch den algorythmus verarbeitet werden.

Aber naja, traum kaputt :(

Ich denke das wäre auch ziemlich aufwendig, ich überlege schon ob es wirklich interessant für angreifer ist, die userpasswörter zu kennen, immerhin kann er damit nichts machen, außer einen user ärgern.

Zwischen php und db kann ja keiner eingreifen oder? Ich meine spezieller den php code anschauen?

Wie ist es mit SSL, muss das auf dem server bereit stehen, muss ich es installieren, kostet ein zertifikat geld????

KingCrunch

12.06.2008, 14:23

Ich denke das wäre auch ziemlich aufwendig, ich überlege schon ob es wirklich interessant für angreifer ist, die userpasswörter zu kennen, immerhin kann er damit nichts machen, außer einen user ärgern.Je nachdem, worum es konkret geht, kann "ärgern" aber für alle Beteiligten sehr teuer werden.

steffen88

12.06.2008, 14:50

Je nachdem, worum es konkret geht, kann "ärgern" aber für alle Beteiligten sehr teuer werden.

Das stimmt leider.

Hast du antworten auf meine SSL fragen?

DennisBecker

13.06.2008, 08:53

Ein Zertifikat kostet Geld, damit der Browser es anstandslos annimmt. Kenne mich da aber nicht so gut aus. Wenn man mit OpenSSL ein Zertifikat erstellt, geht es zwar schon, aber der Browser würde anmeckern, dass das Zertifikat nicht vertrauensvoll ist, solange, bis man sich bei einer Vertrauensstelle mit dem Zertifikat eintragen lässt. Da gehen die Kosten dann weit auseinander. Das kann dann auch mal schnell 200 Euro kosten (für ein Jahr) - zumindest wollte das mal ein Webspace Provider von mir haben, als ich mal da nachgefragt hatte. Ich denke dazu wirst du einiges im serversupportforum.de finden.

Marco

13.06.2008, 09:24

Das kann dann auch mal schnell 200 Euro kosten (für ein Jahr).

achwas, man muss nur wissen wo's die gut und billig gibt ;)
wenn man die wo anders kauft ist es reine abzocke (provider, hoster etc)

geheimtipp clickmich (http://www.psw.net/ssl.cfm)

akkie

13.06.2008, 10:53

Wenn man ein Zertifikat für eine Intranetanwendung benötigt kann man sich auch per OpenSSL eine Zertifizierungsstelle erstellen und diese in den Browser importieren. Dann kosten Zertifikate nichts und es gibt beim besuch der Seite keinen Fehler.

DennisBecker

13.06.2008, 13:53

Das hab ich ja vorher schon erwähnt, das kann man auch für's Web machen, wenn man will. Hat halt den Nachteil, dass es unseriös wirkt.

@Marco: ich verstehe die unterschiede nicht wirklich bei den Angeboten. Welches würde man denn z.B. für eine Community Site nehmen, die man absichern wollen würde per SSL?

Oder wie sähe es mit einem Online-Intranet aus, wenn man ein verteiltes Projektteam hat? Da bräuchte man ja SSL + LDAP um die Webseiten abzusichern.

ice-breaker

13.06.2008, 14:03

Ein Zertifikat kostet Geld, damit der Browser es anstandslos annimmt. [...] Das kann dann auch mal schnell 200 Euro kosten (für ein Jahr)

SSL-Zertifikate, die die Browser ohne murren aktzeptieren gibt es schon ab 15€/Jahr: SSL-Certs (http://www.psw.net/ssl.cfm), wobei ich eher den Limitbreaker bevorzuge, da steckt der Thawte SSL123 dahinter, wo Thawte einfach schon seit Ewigkeiten in Browsern integriert ist

steffen88

13.06.2008, 15:22

Danke erstmal, wie ist es auf der Seite von Marco.

Was ist bei Browserkompatibilität das Java Logo?

Was ist wenn die verwendete version älter ist?

ice-breaker

13.06.2008, 17:49

Was ist bei Browserkompatibilität das Java Logo?
das bedeutet Java kennt dieses SSL-Zertifikat, denn auch Java kann mit SSL umgehen.

Was ist wenn die verwendete version älter ist?
dann bekommt der Benutzer eine Meldung zu sehen, dass das Zertifikat von einer nicht vertrauenswürdigen Person unterzeichnet wurde, aber ich bezweifle, dass du Benutzer mit älteren Browsern finden wirst. Denn heute hat doch jeder der Online einen der neueren Browser.

francois

13.06.2008, 23:27

SSL-Zertifikate, die die Browser ohne murren aktzeptieren gibt es schon ab 15€/Jahr: SSL-Certs (http://www.psw.net/ssl.cfm), wobei ich eher den Limitbreaker bevorzuge, da steckt der Thawte SSL123 dahinter, wo Thawte einfach schon seit Ewigkeiten in Browsern integriert ist

Hallo ice-breaker!
Hab mich zwar noch nicht riesig mit dem Thema beschäftigt aber es wird bald soweit sein und ich denke der von Dir empfohlene Limitbreaker für meine Anforderung voll ausreicht.

Mein Provider (domainfactory - df.eu) will 150 € für ein 1-Jahres-Zertifikat (geotrust) haben.
Im Provider-Forum habe ich gelesen, das die für 50€ ein Eigenes installieren.
Das heißt für 2 Jahre wären das grade mal 120 € statt 150 € für ein Jahr... :)

Also danke für den Spartipp!

PeHaPe

30.07.2008, 22:36

Ich hab das grad mit AES gemacht, obwohl im Grunde eine Maskierung reichen würde. Ich verschlüssel das Password in der Db und Kreditkarteninfos sowie Bankverbindungen. Zumindest eine Maskierung muss aufjedenfall sein wegen Sichtschutz. Den Usernamen verschlüsseln halt ich für nicht sinnig.

Ich hab also ein validiertes Array mit Anmeldedaten in dem alle nicht in der Datenbank enthaltenen Felder bereits enfernt sind.

private function createAccount($array){

//Ich hole aus dem array das passwort verpacke es in einer Zend_DB_Expr und lege es ins Array zurück
try{
$array['Password'] = new Zend_Db_Expr('AES_ENCRYPT('.$array['Password'].',"meinGeheimerschluessel")');
$meinDbObject->insert(meinUserTable,$array);
return true;
}
catch(Zend_Db_Statement_Mysqli_Exception $e){

//mach was mit der exception
return false;
}

}

rausholen mach ich momentan so

....
$auth =Zend_Auth::getInstance();
$adapter = new Zend_Auth_Adapter_DbTable( meinDbObject,meinUserTable,'username','password',' AES_ENCRYPT(?,"meinGeheimerschluessel")' );

//hier übergeb ich die beim einloggen übergebenen daten an den adapter
$adapter->setIdentity($_POST['username'])
->setCredential($_POST['password']);

$result =$adapter->authenticate();
...

kann man auch mit MD5 machen, laut MYSQL-Doku aber nicht sicher.
Der Geheimenschluessel könnte auch der mit MD5 verschlüsselte Username sein. ^^ Aber wer eh schon Zugriff auf den Quellcode hat, wird auch das kapieren.

Bei SSL empfiehlt MYSQL dann DES als Verschlüsselung.

mein PasswordFeld in der DatenBank ist LONGBLOB bei MYSQL

Vielleicht gibt es aber eine elegantere Methode.

P.S.:bei einem normalen select in der db krieg ich dann nur mist zurück es scheint also zu funktionieren.

PeHaPe

30.07.2008, 22:53

Zum Thema SSL. Bei uns in der Firma ist das so das sie nur Zertifikate nehmen die auch als sicher eingestuft werden und keine Meldung vom Browser kommt. Zertifikat nicht signiert oder so. Kenne mich aber damit nicht aus, das macht der Chef sowas. Glaub aber die nehmen die nicht,weil sie die für besonderst sicher halten,sondern weil das die Kunden nicht wollen so Meldungen. Naja aber wie gesagt ich rede hier von böhmischen Dörfern.

ChristianFischer

31.07.2008, 09:45

Zum Thema self signed certificates:

Habt ihr schonmal im neuen FireFox(3) ne self signed site angesteuert ? Früher kam da ne Messagebox wo einem mitgeteilt wurde: "Achtung blabla". Die meisten user haben das gleich weggeklickt und gut.

Jetzt ist es so das der Firefox so ne Informationsseite anzeigt. Siehe hier:
http://nerds.computernotizen.de/2008/06/13/das-firefox-3-ssl-desaster/