welche Passwort verschlüsselung ist den die beste?
ich meine sowas wie md5
Passwort Verschlüsselung?
gepostet vor 18 Jahre, 7 Monate von Sanni
gepostet vor 18 Jahre, 7 Monate von Kampfhoernchen
Eben. MD5. Ist fix berechnet, kann jede Programmiersprache. Punkt.
gepostet vor 18 Jahre, 7 Monate von Mudder
Jein..
md5 kann man gut verwenden doch wenn du es "perfekt" machen willst dann nimm sha1. Das verwendet einen 40-Zeichen String und arbeitet ansonsten wie md5.. nur das es eben noch ein Tickchen besser ist.
md5 kann man gut verwenden doch wenn du es "perfekt" machen willst dann nimm sha1. Das verwendet einen 40-Zeichen String und arbeitet ansonsten wie md5.. nur das es eben noch ein Tickchen besser ist.
gepostet vor 18 Jahre, 7 Monate von The-Winner
und ich würde den passwortstring noch leicht verändern vorm hashen (z.B. eine konstante Zeichenkette anhängen) damit es mit rainbowtables schwerer wird
gepostet vor 18 Jahre, 7 Monate von Mudder
Ähm... ich glaube du hast da einen leichten Denkfehler drin!
Wenn du das Passwort "browser" mit nem String erweiterst und es als "prebrowser123" speicherst dann wird bei der Loginkontrolle trotzdem nur "browser" eingegeben. Folglich musst du deine zusätzlichen Strings dranhängen und das wiederum wird dann auch bei Crackern passieren die ne Passwortliste durchgehen.
Und wenn du es zulässt das man bei dir ne Passwortliste durchgehen kann dann stimmt mit deinem Loginscript eh was nicht.. nach 3x falsch von einer IP sollte mindestens nen Block rein und min. auch ein Logeintrag damit man die Sachen später nachverfolgen und ggfl. eingreifen kann.
Wenn du das Passwort "browser" mit nem String erweiterst und es als "prebrowser123" speicherst dann wird bei der Loginkontrolle trotzdem nur "browser" eingegeben. Folglich musst du deine zusätzlichen Strings dranhängen und das wiederum wird dann auch bei Crackern passieren die ne Passwortliste durchgehen.
Und wenn du es zulässt das man bei dir ne Passwortliste durchgehen kann dann stimmt mit deinem Loginscript eh was nicht.. nach 3x falsch von einer IP sollte mindestens nen Block rein und min. auch ein Logeintrag damit man die Sachen später nachverfolgen und ggfl. eingreifen kann.
gepostet vor 18 Jahre, 7 Monate von woodworker
Original von Sanni
welche Passwort verschlüsselung ist den die beste?
ich meine sowas wie md5
*klugscheiss* zum verschlüsseln von passwörtern würde ich DES oder AES nutzen
zum hashen von passwörtern md5 oder sha1
gepostet vor 18 Jahre, 7 Monate von knalli
Denkfehler ist aber auch, zu behaupten, md5 wäre eine Verschlüsselung. Denn es ist mit md5 unmöglich, auf den Originalstring Rückschlüsse zu ziehen.
Egal was die Eingabe ist - es kommt immer ein (nu schlag mich tot: 32??) 32-String als Hash raus. Sowohl mit dem Wort 'abc' als auch mit der 2 MByte Testfile.
Im Heiseforum haben sich vor einigen Tagen wieder mal ein paar Halbgötter über den Nutzen von md5 philosohpiert und meinten, das sha1 natürlich viel besser sei.
Ich will das erst gar nicht verstehen wollen.. Hash ist Hash, und wenn jemand Zugriff auf meine Hash-Passwortliste hat, dann habe ich eh ein paar mehr Problemchen..
grml, die Holzarbeiter waren mal wieder schneller :O
Egal was die Eingabe ist - es kommt immer ein (nu schlag mich tot: 32??) 32-String als Hash raus. Sowohl mit dem Wort 'abc' als auch mit der 2 MByte Testfile.
Im Heiseforum haben sich vor einigen Tagen wieder mal ein paar Halbgötter über den Nutzen von md5 philosohpiert und meinten, das sha1 natürlich viel besser sei.
Ich will das erst gar nicht verstehen wollen.. Hash ist Hash, und wenn jemand Zugriff auf meine Hash-Passwortliste hat, dann habe ich eh ein paar mehr Problemchen..
grml, die Holzarbeiter waren mal wieder schneller :O
gepostet vor 18 Jahre, 7 Monate von Chojin
md5 ist meiner Meinung nach eine sichere Grundlage für den Passwortschutz eines Spiels. Den sogenannten "Salt" sollte man jedem Passwort hinzugeben und zwar aus folgendem grund:
Angenommen jemand kommt (wie auch immer) an einen Datenbankdump von der Usertabelle oder bekommt über einen scriptfehler Zugriff auf die SQL Schnittstelle und kann die Usertabelle ausgeben und niemand merkt es... Danach könnte man mit so genannten "Rainbowtables" nach schwachen Passwörtern suchen und dann beim Login das Passwort eingeben um sofort Zugriff auf einen fremden Account zu bekommen. Als Sicherung gegen dieses Vorgehen gibt es den Salt, der das eigendliche Passwort von dem HASH-Wert verfremdet, wodurch eventuelle Rückschlüsse von HASH zu einem Klartextpasswort für die Eingabemaske praktisch unmöglich werden, ohne den Wert des "Salt" zu kennen.
Hier als Beispiel meine kleine Funktion:
reg4rds
chojin
PS: Bei einem laufenden spiel sollte man es tunlichst vermeiden den salt noch einmal zu ändern
Angenommen jemand kommt (wie auch immer) an einen Datenbankdump von der Usertabelle oder bekommt über einen scriptfehler Zugriff auf die SQL Schnittstelle und kann die Usertabelle ausgeben und niemand merkt es... Danach könnte man mit so genannten "Rainbowtables" nach schwachen Passwörtern suchen und dann beim Login das Passwort eingeben um sofort Zugriff auf einen fremden Account zu bekommen. Als Sicherung gegen dieses Vorgehen gibt es den Salt, der das eigendliche Passwort von dem HASH-Wert verfremdet, wodurch eventuelle Rückschlüsse von HASH zu einem Klartextpasswort für die Eingabemaske praktisch unmöglich werden, ohne den Wert des "Salt" zu kennen.
Hier als Beispiel meine kleine Funktion:
function my_md5 ($passwort) { return md5( $passwort . 'myv3ry3v1ls4lt'); } reg4rds
chojin
PS: Bei einem laufenden spiel sollte man es tunlichst vermeiden den salt noch einmal zu ändern
gepostet vor 18 Jahre, 7 Monate von knalli
Ach.. aber urplötzlich gab es ein "Sicherheitsproblem", weswegen alle Passwörter neu vergeben werden? *hihi*
gepostet vor 18 Jahre, 7 Monate von Sanni
was ist dieses DES & AES?
und so geht das auch net oder?:
$passwort = "lala";
$passwort2 = md5($passwort);
$passwort3 = sha1($passwort2);
und wäre eine eigen geschriebene verschlüsselung auch gut?
ich meine so lange der Hacker nicht den quelle code hat kann er nichts mit den user passwörtern anfangen...
und so geht das auch net oder?:
$passwort = "lala";
$passwort2 = md5($passwort);
$passwort3 = sha1($passwort2);
und wäre eine eigen geschriebene verschlüsselung auch gut?
ich meine so lange der Hacker nicht den quelle code hat kann er nichts mit den user passwörtern anfangen...
gepostet vor 18 Jahre, 7 Monate von woodworker
Original von Sanni
was ist dieses DES & AES?
Das sind Verschlüsselungs Algos
Original von Sanni
und so geht das auch net oder?:
$passwort = "lala";
$passwort2 = md5($passwort);
$passwort3 = sha1($passwort2);
das geht aber würde ich nicht machen weil das eher sinnlos ist.
Original von Sanni
und wäre eine eigen geschriebene verschlüsselung auch gut?
ich meine so lange der Hacker nicht den quelle code hat kann er nichts mit den user passwörtern anfangen...
Sanni md5 ist keine verschlüsselung md5 ist ein hash, also einweg - eine verschlüsselugn wäre wenn du aus dem ergebnis wieder zurückrechnen kannst.
und ne eigene lösung wäre auch blödsinn denn wenn er an die passwörter kommt muss er die eh erstmal wieder bruteforcen um an die passwörter zu kommen und wenn er in der DB ist was soll er den bitte mit den passwörtern die email adressen wäre aus heutiger sich eh viel interessanter
gepostet vor 18 Jahre, 7 Monate von Chojin
@Sanni: Ich glaub es macht keinen sinn weitere fragen zu stellen und zu beantworten, solage dir nicht klar ist, was ein HASH von Verschlüsselung unterscheidet.
Ich will hier nur noch einmal in aller deutlichkeit sagen, dass sich str_rot13() nicht als passwortalgorithmus eignet!!!
Eigentlich ist es nur überflüssige datenschutzrechtliche Verantwortung, wenn man Passwörter selbst abspeichert, so dass sie durch irgendein Verfahren entschlüsselt werden könnten. Eine Kollision bei einem Hashwert herbeizuführen soll ja auch laut Wissenschaft mit den heutigen Mitteln eine sehr langwierige Angelegenheit sein. - Wie man dies nahezu unmöglich machen kann hab ich ja bereits in meinem letzten Post erklärt.
Hinzu kommen noch die normalen Sicherheitsvorkehrungen wie eine Längenbegrenzung der Passwortzeichenkette und IP Sperre nach eine kleinen Anzahl von fehlgeschlagenen Anmeldungen.
reg4rds
chojin
Ich will hier nur noch einmal in aller deutlichkeit sagen, dass sich str_rot13() nicht als passwortalgorithmus eignet!!!
Eigentlich ist es nur überflüssige datenschutzrechtliche Verantwortung, wenn man Passwörter selbst abspeichert, so dass sie durch irgendein Verfahren entschlüsselt werden könnten. Eine Kollision bei einem Hashwert herbeizuführen soll ja auch laut Wissenschaft mit den heutigen Mitteln eine sehr langwierige Angelegenheit sein. - Wie man dies nahezu unmöglich machen kann hab ich ja bereits in meinem letzten Post erklärt.
Hinzu kommen noch die normalen Sicherheitsvorkehrungen wie eine Längenbegrenzung der Passwortzeichenkette und IP Sperre nach eine kleinen Anzahl von fehlgeschlagenen Anmeldungen.
reg4rds
chojin
gepostet vor 18 Jahre, 7 Monate von abuzeus
Original von Sanni
und wäre eine eigen geschriebene verschlüsselung auch gut?
ich meine so lange der Hacker nicht den quelle code hat kann er nichts mit den user passwörtern anfangen...
Ganz klares "Nein". Die Debatte um Hashing/Verschlüsselung mal ausser Acht gelassen, selbst Machen ist in diesem Falle gar nicht gut. Wer garantiert dir, dass es bei deiner selbstgestrickten Lösung nicht eine Schwachstelle/Kollision gibt, die du nur übersehen hast ? Solange du nicht gerade ein paar Semester Mathematikstudium mit Erfahrung in Kryptographie hast und beweisen kannst, dass dein Kram sicher ist, lass die Finger davon.
Bei MD5 usw. weisst du wenigstens, dass sie sicher sind bzw. dass sie - ausser von der NSA natürlich ;-) - nicht geknackt sind, und wenn das passiert, dann liest man es garantiert auf heise oder so...
Und dass Passwörter immer nur gehasht abgespeichert werden sollten, versteht sich eigentlich von selbst. Niemand kann garantieren, dass vielleicht durch irgendeinen dummen Fehler nicht doch mal die Passwortdatei/Tabelle/wasweissich in die falschen Hände gerät, und dann habt ihr das Problem. Passiert einem Haufen Firmen immer mal wieder, warum solltet ihr als Amateure dagegen gefeit sein... Das bischen Aufwand, dass man durch das Hashen hat, sollte einem den vermiedenen Ärger wert sein. Ich hab so eine Reparaturmaßnahme mal ausbaden müssen, weil der Progger Mist gebaut hatte: Kein Spass ;-)
gepostet vor 18 Jahre, 7 Monate von The-Winner
@Mudder
Die md5 hashes stehen eh nur in der db. Und wenn jemand an die db rankommt bekommt er die hashes. Daher kann ich dann schonmal die Versuche nicht mehr begrenzen.
:arrow: Hacker hat Hash, kein Zusatzstring verwendet:
Kann entweder passwortliste oder vorhandene rainbowtables nehmen, in denen alle Passwörter bis x stellen drinstehen.
:arrow: Hacker hat Hash aber nicht den Code, Zusatzstring verwendet
Kann gar nichts machen
:arrow: Hacker hat nur Hash und Code, Zusatzstring verwendet
Nun kann er die Passwortliste nutzen, aber rainbowtables werden ihm nicht nützen, da das unverschlüsselte pass nun zu lang ist.
=> Zusatzstring macht es auf jeden Fall sicherer
Die md5 hashes stehen eh nur in der db. Und wenn jemand an die db rankommt bekommt er die hashes. Daher kann ich dann schonmal die Versuche nicht mehr begrenzen.
:arrow: Hacker hat Hash, kein Zusatzstring verwendet:
Kann entweder passwortliste oder vorhandene rainbowtables nehmen, in denen alle Passwörter bis x stellen drinstehen.
:arrow: Hacker hat Hash aber nicht den Code, Zusatzstring verwendet
Kann gar nichts machen
:arrow: Hacker hat nur Hash und Code, Zusatzstring verwendet
Nun kann er die Passwortliste nutzen, aber rainbowtables werden ihm nicht nützen, da das unverschlüsselte pass nun zu lang ist.
=> Zusatzstring macht es auf jeden Fall sicherer
gepostet vor 18 Jahre, 7 Monate von Sanni
@abuzeus
naja wen es nur so schön wäre das nur die NSA das hinbekommt...
http://milw0rm.com/cracker/list.php?start=0
@The-Winner
naja wen es nur so schön wäre wen man die hashs nur über die DB bekommen würde. Schonmal was von exploits gehört? Oder du kannst sogar ohne zusatz tools bei phpkit über das gästebuch an den Admin hash kommen wie das geht erkläre ich natürlich nicht.
Also es ist unmöglich jede sicherheitslücke zu schlissen deshalb frage ich ja nach stark verschlüsselte bzw gehashte, oder wie man es auch nennen mag, Passwörtern
naja wen es nur so schön wäre das nur die NSA das hinbekommt...
http://milw0rm.com/cracker/list.php?start=0
@The-Winner
naja wen es nur so schön wäre wen man die hashs nur über die DB bekommen würde. Schonmal was von exploits gehört? Oder du kannst sogar ohne zusatz tools bei phpkit über das gästebuch an den Admin hash kommen wie das geht erkläre ich natürlich nicht.
Also es ist unmöglich jede sicherheitslücke zu schlissen deshalb frage ich ja nach stark verschlüsselte bzw gehashte, oder wie man es auch nennen mag, Passwörtern
gepostet vor 18 Jahre, 7 Monate von TheUndeadable
Ich persönlich fühle mich schon wohl, wenn ich die Benutzertabelle irgendwo aufrufen kann (per Konsolen-SELECT zum Beispiel), ohne Angst zu haben, dass mir jemand über die Schulter schaut.
gepostet vor 18 Jahre, 7 Monate von Sarge
ein exploit ist ledeglich ein verfahren um eine sicherheitslücke auszunutzen.. und genau du als programmierer hast die aufgabe das auftreten solcher sicherheitslücken zu vermeiden.
Das jemand ein bestimmten hash kommt ist tragisch.. aber der Worst-case ist das jemand an die gesamte Datenbank herankommt. Und im Zuge der verbreitung der rainbow tables ist es imho in der tat sinnvoll nicht einfach orginal md5 plump zu verwenden. Aber ein guter ansatz zumindestens schon. Denn der Aufwand muss immer in der Relation zum Nutzen stehen und der Nutzen ist noch relativ gering bei einem bg. Allerdings kombiniert mit dem wissen um die menschliche faulheit...
Das jemand ein bestimmten hash kommt ist tragisch.. aber der Worst-case ist das jemand an die gesamte Datenbank herankommt. Und im Zuge der verbreitung der rainbow tables ist es imho in der tat sinnvoll nicht einfach orginal md5 plump zu verwenden. Aber ein guter ansatz zumindestens schon. Denn der Aufwand muss immer in der Relation zum Nutzen stehen und der Nutzen ist noch relativ gering bei einem bg. Allerdings kombiniert mit dem wissen um die menschliche faulheit...
gepostet vor 18 Jahre, 6 Monate von abuzeus
Original von Sanni
@abuzeus
naja wen es nur so schön wäre das nur die NSA das hinbekommt...
http://milw0rm.com/cracker/list.php?start=0
Okay, muss man halt was anderes nehmen. Der Kern der Aussage wird dadurch jedenfalls nicht berührt...
gepostet vor 18 Jahre, 6 Monate von Chojin
Original von Sanni
@abuzeus
naja wen es nur so schön wäre das nur die NSA das hinbekommt...
http://milw0rm.com/cracker/list.php?start=0
Genau für den fall, das die bösen jungs mal an einen hash wert rankommen, verfremdet man den hash mit einem Salt. Dadurch ist das was die da auf ihrer webseite zeigen absolut unbrauchbar als angriffsmethode... Rainbow Tables haben weitaus mehr Einträge als die paar die du da im web sehen kannst, da die meisten bekannten/brauchbaren Rainbowtables auf Basis von Wörterbuchattacken erstellt wurden.
Selbst wenn einmal Hash und Salt bekannt werden sollte, gibt es keine Rainbowtable die Hashwerte mit eben diesem Salt zu verfügung stellt.
reg4rds
chojin
gepostet vor 18 Jahre, 6 Monate von Kampfhoernchen
Also ich bin immer noch der Meinung, dass ein einfacher MD5 reicht. Eben dass man Passwörter nicht sofort lesen kann, wenn der Admin ne Backuptabelle im Laptop im Zug durchgeht.
Wenn ich DB-Zugriff hab, kann ich die Passwörter eh ändern, wie ich will.
Man sollte lieber ein Augenmerk darauf legen, dass die User sichere Passwörter verwenden.
Wenn ich DB-Zugriff hab, kann ich die Passwörter eh ändern, wie ich will.
Man sollte lieber ein Augenmerk darauf legen, dass die User sichere Passwörter verwenden.
gepostet vor 18 Jahre, 6 Monate von Flint
Wenn ich das richtig sehe redet ihr hier ja davon wie das vom Browser geschickte Passwort auf dem Server sicher Verwaltet werden kann.
Was haltet ihr davon den Hash, wenn Möglich, bereits im Browser zu erzeugen? Das orginal Passwort kommt dann erst gar nicht bis zum Sever.
Beispiel ist Yahoo, http://infotech.indiatimes.com/articleshow/553621.cms
Was haltet ihr davon den Hash, wenn Möglich, bereits im Browser zu erzeugen? Das orginal Passwort kommt dann erst gar nicht bis zum Sever.
Beispiel ist Yahoo, http://infotech.indiatimes.com/articleshow/553621.cms
gepostet vor 18 Jahre, 6 Monate von knalli
Und was genau ist jetzt der finale Unterschied?
Abgesehen davon, das Clients ohne JS wahrscheinlich vor Problemen stehen..
Abgesehen davon, das Clients ohne JS wahrscheinlich vor Problemen stehen..
gepostet vor 18 Jahre, 6 Monate von Mudder
Bzw. der Aufwand für ne JS-Funktion deutlich höher sein dürfte als ein md5($pass);
gepostet vor 18 Jahre, 6 Monate von Flint
Der Unterschied ist der das das Passwort, bei aktiviertem JS, den Rechner des Anwedners nicht verläßt. Man erhält zusätzlich halt noch nen gewissen Sniffing Schutz (siehe Artikel) und die Passwörter sind auch vor Code Injection geschüzt.
Der zusätzliche Aufwand besteht in erster Linie darin die JS md5 Funktion an den Client zu übertragen.
So eine Lösung bietet halt einige zusätzliche Sicherheit und was anderes soll ein in der DB gespeichrter Passwort hash etc. ja auch nicht bieten. Man schützt sich dadurch ja "lediglich" vor unbefugtem auslesen der Datenbank.
Der zusätzliche Aufwand besteht in erster Linie darin die JS md5 Funktion an den Client zu übertragen.
So eine Lösung bietet halt einige zusätzliche Sicherheit und was anderes soll ein in der DB gespeichrter Passwort hash etc. ja auch nicht bieten. Man schützt sich dadurch ja "lediglich" vor unbefugtem auslesen der Datenbank.
gepostet vor 18 Jahre, 6 Monate von knalli
Code Injection bei Passwörter - mehr Sicherheit in der Datenbank.. ??
Raff ich nicht so ganz, wird damit die md5() von bsp. PHP oder MySql in Frage gestellt? Und wo ist die höhere Sicherheit in der Datenbank?
Der einzige Vorteil ist, das das Passwort nicht mehr den Client verlässt - auf der anderen Seite, wenn man eine sichere Verbindung (SSL 3) hat, ist das eh irrelevant. Der Nachteil, das alle Geräte und Browser, die kein aktives JavaScript haben, ausgesperrt werden, überwiegt hier deutlich, will ich meinen.
Es kommt natürlich auf den Einsatzzweck und damit verbunden auf die Situation an - bei einem Bankserver ist man de facto eh mit SSL unterwegs, und die Anwendung kann evtl auf Zugänglichkeit getrimmt sein, damit auch bsp. mobile Geräte "mitkommen" können. Die PSP hat aktives JS, wie ich letztens beim Brüderle feststellen konnte - aber das gilt ja nicht für jeden PDA, Handybrowser, etc..
Raff ich nicht so ganz, wird damit die md5() von bsp. PHP oder MySql in Frage gestellt? Und wo ist die höhere Sicherheit in der Datenbank?
Der einzige Vorteil ist, das das Passwort nicht mehr den Client verlässt - auf der anderen Seite, wenn man eine sichere Verbindung (SSL 3) hat, ist das eh irrelevant. Der Nachteil, das alle Geräte und Browser, die kein aktives JavaScript haben, ausgesperrt werden, überwiegt hier deutlich, will ich meinen.
Es kommt natürlich auf den Einsatzzweck und damit verbunden auf die Situation an - bei einem Bankserver ist man de facto eh mit SSL unterwegs, und die Anwendung kann evtl auf Zugänglichkeit getrimmt sein, damit auch bsp. mobile Geräte "mitkommen" können. Die PSP hat aktives JS, wie ich letztens beim Brüderle feststellen konnte - aber das gilt ja nicht für jeden PDA, Handybrowser, etc..
gepostet vor 18 Jahre, 6 Monate von Flint
Original von knalli
Raff ich nicht so ganz
Warum verschleiert man ein Passwort um es in der Datenbank zu speichern?
Um die Sicherheit zu erhöhen. Ein gängiges verfahren hierfür ist ein MD5 Hash.
Den MD5 Hash bereits beim Client zu erzeugen ist das selbe Verfahren angewendet auf weitere Sicherheitsproblem.
gepostet vor 18 Jahre, 6 Monate von Krisch
Original von knalli
Der Nachteil, das alle Geräte und Browser, die kein aktives JavaScript haben, ausgesperrt werden, überwiegt hier deutlich, will ich meinen.
Stimmt nicht. Im Formular wird auch noch ein weiteres Feld mitgesendet, das angibt ob JavaScript aktiviert ist. Falls es nicht aktiviert ist, wird das Passwort nachträglich mit MD5 bearbeitet.
Ich hab übrigens schon öfters gehört, dass so ein Sniffing-Schutz verwendet wird, weil das zufällige Abfangen gar nicht schwer ist.
gepostet vor 18 Jahre, 6 Monate von Chojin
Original von Flint
Wenn ich das richtig sehe redet ihr hier ja davon wie das vom Browser geschickte Passwort auf dem Server sicher Verwaltet werden kann.
Was haltet ihr davon den Hash, wenn Möglich, bereits im Browser zu erzeugen? Das orginal Passwort kommt dann erst gar nicht bis zum Sever.
Beispiel ist Yahoo, http://infotech.indiatimes.com/articleshow/553621.cms
Das ist ne sehr gefährliche idee die leicht nach hinten losgehen kann...
...wenn das Passwort auf der Clientseite als Hash erzeugt wird, ist der Hash das eigentliche neue Passwort was angriffe um ein vielfaches vereinfacht.
Nehmen wir unser altes beispiel: ich komm irgendwie an die Usertable ran, und kann sehen was in der Passwort Spalte steht...
... alles was ich jetzt noch machen muss ist mir ein eigenes login zu basteln und eben diesen Wert der in der Tabelle steht, UNVERSCHLÜSSELT und OHNE RECHENAUFWAND an den Server zu übertragen... und schon bin ich eingeloggt und kann den Account nutzen, schädigen oder berauben.
coole sache, dummes konzept.
reg4rds
chojin
gepostet vor 18 Jahre, 6 Monate von TheUndeadable
Das Yahoo-Verfahren wäre für mich nur interessant, wenn man die Kennwörter ungehasht oder echt verschlüsselt speichern würde.
Aber ich würde lieber auf eine https-Verbindung setzen, als mich mit einer JS-Lösung bei einem Login abfinden. Gerade JS kann hin und wieder mal zu kleineren Problemen bei diversen Browsern führen und JS beim Login wäre dann ein fataler Fehler, der zur Unbenutzbarkeit des betreffenden Users führt.
Aber ich würde lieber auf eine https-Verbindung setzen, als mich mit einer JS-Lösung bei einem Login abfinden. Gerade JS kann hin und wieder mal zu kleineren Problemen bei diversen Browsern führen und JS beim Login wäre dann ein fataler Fehler, der zur Unbenutzbarkeit des betreffenden Users führt.
gepostet vor 18 Jahre, 6 Monate von Flint
[quote="Chojin"]
Kann so Trivial ist das Yahoo verfahren nicht, aber ich sehe natürlich auch diese Problematik.
Original von Flint
leicht nach hinten losgehen kann...
...wenn das Passwort auf der Clientseite als Hash erzeugt wird, ist der Hash das eigentliche neue Passwort was angriffe um ein vielfaches vereinfacht.
Kann so Trivial ist das Yahoo verfahren nicht, aber ich sehe natürlich auch diese Problematik.
gepostet vor 18 Jahre, 6 Monate von knalli
Original von TheUndeadable
Das Yahoo-Verfahren wäre für mich nur interessant, wenn man die Kennwörter ungehasht oder echt verschlüsselt speichern würde.
Aber ich würde lieber auf eine https-Verbindung setzen, als mich mit einer JS-Lösung bei einem Login abfinden. Gerade JS kann hin und wieder mal zu kleineren Problemen bei diversen Browsern führen und JS beim Login wäre dann ein fataler Fehler, der zur Unbenutzbarkeit des betreffenden Users führt.
Meine Worte.. und https/ssl hat den schönen Nebeneffekt, das nicht nur das Passwort verschlüsselt wird..
gepostet vor 18 Jahre, 6 Monate von Flint
Original von knalli
Meine Worte.. und https/ssl hat den schönen Nebeneffekt, das nicht nur das Passwort verschlüsselt wird..
Hmm ich hab noch kein Browsergame gesehen das https/ssl benutzt
@Chojin Wie das Passwort in der DB gespeichert wird hat erstmal nix damit zu tun wie es übertragen wird. Nichts hält dich davon ab den übertragenen MD5 hash zum speichern zu verschleiern.
Das einzige Gegenargument das bleibt ist das es Javascript benötigt, da die meisten Browserspiele inzwischen eh intensiv Javascript einsetzen sehe ich darin nicht wirklich ein Problem.
Habt mich noch nicht überzeugt, ich finde es immer noch besser wenn ein Passwort erst gar nicht bis zum Server kommt
gepostet vor 18 Jahre, 6 Monate von Sarge
Original von Flint
Original von knalli
Meine Worte.. und https/ssl hat den schönen Nebeneffekt, das nicht nur das Passwort verschlüsselt wird..
Hmm ich hab noch kein Browsergame gesehen das https/ssl benutzt
Das aber kein Grund es nicht zu nutzen
Außerdem hatte hier auf GN mind. eins mal mit werbung gemacht das sies aktiviert waren (auch wenn der artikel leider ziemlich falsche sachen drinstehen hatte)
gepostet vor 18 Jahre, 6 Monate von knalli
Original von Flint
Original von knalli
Meine Worte.. und https/ssl hat den schönen Nebeneffekt, das nicht nur das Passwort verschlüsselt wird..
Hmm ich hab noch kein Browsergame gesehen das https/ssl benutzt
Wohl wahr, nur eben gerade deswegen sehe ich nicht viel Sinn dahinter - das mit dem Flag (wurde verschlüsselt, wurde nicht verschlüsselt) ist dann nett - aber mit dem gleichen Argument, warum man kein SSL bei einem Browsergame benutzt (einmal abgesehen von den technischen Argumenten), kann man auch gegen andere zusätzliche Sicherheitsmechanismen angehen.
Wobei, bei einem richtig professionallen Browsergame, mit viel Kommerz.. würde ich zumindestens in der Loginphase einen SSL Server zwischenschalten (siehe Ebay) oder andere "Raffinessen". Gute und zufriedene Kunden sind auch zahlende Kunden..
gepostet vor 18 Jahre, 6 Monate von Flint
Original von knalli
oder andere "Raffinessen"
Eben sowas ist ein Challenge Response Login System. Releative geringer Aufwand der ein bischen mehr Schutz bietet. Auch vor diversen Attacken. Ein reines verschleiern des Passwortes in der DB ist imho nur das absolute minimum. https/ssl ist das maximum, aber dazwischen gibts halt auch noch Lösungen