Alternate 1

Was für Programmierkentnisse braucht man für eine Seite wie Computerbase.de ?

Fortatus schrieb:
Mit 2 Tagen PHP-Erfahrung und etwas lesen, kriegste mit normalen PHP-Funktionen ganz schnell nen bcrypt-Hash mit Salt und Verschleiern hingeknallt.

Ja, und dafür baut man mit der Erfahrung zig andere Lücken ein. Ich glaube, die schnellen Erfolge, welche man heutzutage durch kurzweilige Tutorials und Co. erreicht, lassen viele in falscher Sicherheit wiegen.

Daaron schrieb:
NIE NIE NIE NIE sollst du ungeprüft POST- und GET-Variablen direkt verarbeiten


Cookies nicht vergessen :)
 
Poke646 schrieb:
Ja, und dafür baut man mit der Erfahrung zig andere Lücken ein. Ich glaube, die schnellen Erfolge, welche man heutzutage durch kurzweilige Tutorials und Co. erreicht, lassen viele in falscher Sicherheit wiegen.

Das Problem ist ja nur, dass ein Entwickler bei solchen großen Firmen schon etwas auf dem Kasten haben sollte und nicht alles von irgendwo Copy&Pasted. Zumindest erwartet man das irgendwie.
Genauso erwartet man aber auch, dass wenigstens ein Entwickler dabei ist, der von sicherem Password-Hashing ein wenig Ahnung hat. Ich meine in jedem Forum bekommt man doch mittlerweile schon ein "use bcrypt" zu hören. Aber nein es werden Passwörter weiterhin im Klartext gespeichert oder nicht gesalzen.
Aber gut, bei soviel Inkompetenz hebt man sich mit seinem Wissen eben von der "dummen Masse" ab, kann man also höhere Stundenlöhne verlangen :evillol:
 
Zuletzt bearbeitet:
Poke646 schrieb:
Ja, und dafür baut man mit der Erfahrung zig andere Lücken ein. Ich glaube, die schnellen Erfolge, welche man heutzutage durch kurzweilige Tutorials und Co. erreicht, lassen viele in falscher Sicherheit wiegen.
Das habe ich nie bezweifelt. Ich wollte dem Threadersteller nur die Angst vor dem Passworthashing nehmen. Das ist schnell und sicher erledigt, auch als Anfänger, obwohl es oft anders scheint.

Wie ice-breaker schon sagte, obwohl ich noch hinzufügen möchte: Man braucht aber keinen Entwickler, der anfängt Kryptoteile selber zu schreiben. Das ist auch gefährlich, da Kryptologie sehr kompliziert ist und, wie man an SHA3 und dem AES-Verfahren sieht, selbst die besten Entwickler Algorithmen entwickeln, die entweder schnell geknackt sind oder nachgeregelt werden müssen.
Also lieber Entwickler, die stumpf bestehende Hashingfunktionen auf Passwörter hauen (natürlich möglichst modern und getestet), als sich überschätzen und mehr Schaden als Nutzen anrichten.
 
ice-breaker schrieb:
Interessanterweise haben die PHP-Core-Entwickler das Problem erkannt: Für PHP5.5 sind aktuell simple Password Hashing Funktionen im Gespräch. Einfach Bcrypt unter einer angenehmen API direkt im PHP-Core.
Klingt ja schon mal lecker... aber was bringts? Wie oft hast du eine Maschine, die aktuell genug ist? Zumindest in den Repositories der servertauglichen Distributionen schwirrt wohl nirgendwo ein PHP 5.4 herum. Ubuntu Precise ist wohl die aktuell modernste Longterm-Distribution und hat trotzdem nur PHP 5.3.10. Debian Squeeze, als eine der wohl am weitesten verbreiteten Server-Distris, hat 5.3.3.
Die könnten morgen 5.5 mit Password Hashing raus bringen, du könntest es als Programmierer erst in 2-3 Jahren verwenden. Das ist ähnlich übel wie die gesamte HTML5/CSS3-Geschichte.

DasBoeseLebt schrieb:
Man möge meine, dass das nichts mit dem Thema zu tun hat, aber Social Hacking ist extrem im kommen /QUOTE]
Da gabs letztens endlich mal eine gute Nachricht, ein kleiner Lichtblick. Bei ner holländischen Firma haben welche USB-Sticks auf dem Parkplatz verteilt, die einen Trojaner im Autostart hatten. Günstigerweise hat die erste Person, die so einen Stick gefunden hat, ihn direkt bei der IT abgegeben und die hat prompt die passenden IPs für den Trojaner gesperrt.
Aber das sind wirklich die winzigen Lichtblicke in einem Meer von Dunkel- und Dummheit. Normalerweise reicht es wirklich, einen verseuchten USB-Stick beim Pförtner abzugeben, um an die Geheimnisse des Managements zu kommen...

ice-breaker schrieb:
Genauso erwartet man aber auch, dass wenigstens ein Entwickler dabei ist, der von sicherem Password-Hashing ein wenig Ahnung hat.
Wenn der aber gleichzeitig mit anderen Sachen beschäftigt ist... Nein, hier muss jeder sensibilisiert werden.

Fortatus schrieb:
Also lieber Entwickler, die stumpf bestehende Hashingfunktionen auf Passwörter hauen (natürlich möglichst modern und getestet), als sich überschätzen und mehr Schaden als Nutzen anrichten.
Wenn sie es tun isses ja gar nicht so wild. Sicher sind die ganzen hash()-Funktionen auch mit Salt über Brute Force zu knacken, aber selbst da kann man gegensteuern, indem man z.B. 100x hasht. Der legitime User merkts nciht, der Server merkts nicht, der Brute-Forcer merkts.
Tragisch sind eigentlich eben nur die ganzen Fälle, wo nicht einmal md5($passwort.$salt) gemacht wurde...
 
Jep, dacht ich mir auch *G*

Frag mich nur, ob die jetzt Klartext-PWs gespeichert hatten oder ob die wenigstens ein bisschen Kryto gewirkt haben... Hash nehmen oder Hash nutzen, das ist hier wohl die Frage.
 
Die Passwörter waren im Klartext gespeichert, die "Passwort vergessen"-Funktion schickte nämlich nach Aussagen in den Heise/Golem-Kommentaren das hinterlegte Passwort im Klartext an die Mailadresse.
 
Cool... is wirklich Jahre her, dass mir ein "Passwort vergessen" tatsächlich mein altes Passwort erzählt hat, statt das Passwort zurückzusetzen.
 
Hier wird nicht die Db geklaut oder so, nein, der Mitarbeiter hatte die Daten bei sich gespeichert. Da stellt man sich die Fragen, warum macht er das, woher hat er die und was wollte er damit.

a) keine Ahnung und b) nicht das was du denkst.
Über den Datenschutzwahn in den letzten paar Jahren scheinen einige Leute wirklich komplett vergessen zu haben, dass man als Programmierer nunmal Fehler macht und dementsprechend auch mal Zugriff auf eben jene privaten Daten braucht, um die Datenbank aufzuräumen nachdem so ein Fehler erkannt worden ist. Es ist Gang und Gäbe, dass ich deine Mailadresse in der DB anfasse, und ehrlich gesagt könnte mir nichts egaler sein als eben deine Mailadresse... Dieses praxisfremde Getue geht mir momentan echt auf die Nerven, als ob die Welt untergeht wenn ein Mensch deine Mailadresse oder dein Geburtsdatum sieht O.o

Vielleicht denkst du demnächst wenn du so eine News liest mal nicht ans Schlimmste, sondern an die Realität: der gute Programmierer interessiert sich einen Dreck für dich oder deine Daten, der will einfach nur seinen Code und seine DB in Ordnung halten.
 
Na dass das Passwort im Klartext gespeichert wurde, bedeutet, dass viele Leute Fehler gemacht haben. Das muss ja schon in der Konzeptionsphase angefangen haben. Falls dort aber noch von Hashes gesprochen wurde, dann frage ich mich, was die Entwickler und das QM eigentlich die ganze Zeit getrieben haben.

@mambokurt
Stimmt, dem Programmierer sind die Daten egal. Er bekommt sie eh nicht zu sehen (in der Regel). Sehen können die Daten eigentlich nur die Kundenverwaltung und der DB-Admin.
Btw, nur weil dir es egal, wer deine Daten sieht, heißt das nicht, dass es jedem egal sein sollte. Ich habe zB keinen Bock, dass meine persönlichen Daten unkontrolliert verteilt werden. Es gilt das Recht auf informationelle Selbstbestimmung sowie der Datenschutz.

Der Datenschutzwahn in den letzten Jahren kam nur auf, weil sich vorher keiner einen Kopf um den Datenschutz gemacht hat. Bis dann einige Leute deswegen deswegen abgezockt wurden. Ich bin mir sicher, du bist der erste, der schreit, wenn deine missbräuchlich verwendet werden.
 
e-Laurin schrieb:
@mambokurt
Stimmt, dem Programmierer sind die Daten egal. Er bekommt sie eh nicht zu sehen (in der Regel).

Und in der Regel ist das auch eine Fehlerursache. Man glaubt gar nicht was für Zwug die Leute in Formulare schreiben ^^

e-Laurin schrieb:
Sehen können die Daten eigentlich nur die Kundenverwaltung und der DB-Admin.
Btw, nur weil dir es egal, wer deine Daten sieht, heißt das nicht, dass es jedem egal sein sollte. Ich habe zB keinen Bock, dass meine persönlichen Daten unkontrolliert verteilt werden. Es gilt das Recht auf informationelle Selbstbestimmung sowie der Datenschutz.

Wir reden hier aber immer noch von einer einzelnen Seite wie CB? Wer redet denn von unkontrolliert verteilen? Es ging einzig darum dass sich die Leute aufregen, wenn ein _Entwickler_ Daten aus dem Echtbetrieb rumfliegen hat, und darum dass das zur Fehlerbehebung nunmal manchmal unvermeidbar ist...

e-Laurin schrieb:
Der Datenschutzwahn in den letzten Jahren kam nur auf, weil sich vorher keiner einen Kopf um den Datenschutz gemacht hat. Bis dann einige Leute deswegen deswegen abgezockt wurden. Ich bin mir sicher, du bist der erste, der schreit, wenn deine missbräuchlich verwendet werden.

Ich hinterlege meine Daten nur bei Anbietern denen ich vertraue, und da auch nur die nötigsten. Mit seinen Daten um sich zu werfen und dann auf den Datenschutz zu pochen ist IMHO einfach nur praxisfern, du tust gut daran davon auszugehen dass alles, was du in ein Formular eintippst irgendwann auch öffentlich wird.
 
mambokurt schrieb:
Wer redet denn von unkontrolliert verteilen? Es ging einzig darum dass sich die Leute aufregen, wenn ein _Entwickler_ Daten aus dem Echtbetrieb rumfliegen hat, und darum dass das zur Fehlerbehebung nunmal manchmal unvermeidbar ist...

[...]

und ehrlich gesagt könnte mir nichts egaler sein als eben deine Mailadresse....


Du denkst nicht weit genug oder machst es dir zu leicht, kannst du dir aussuchen. Den dieser besagte Entwickler hatte die Mails online in seinem DropBox gespeichert und das ist sehr bedenklich.

Es gibt keinen logischen Grund, warum man das tun sollte (und dann noch unverschlüsselt). Wenn das bei dir die Praxis ist, dann gute Nacht. Warum benutzen sie nicht eigene Testaccounts mit Testdaten oder so?

Auch ist es egal, was für Daten rausgehen, selbst wenn es nur mein Vorname ist. Gerade Email-Adressen können sehr sensibel sein (z.b. vollen Namen enthalten), erhöhen das Spamm aufkommen oder besagte Betroffene können um ihren Email Zugang bangen, wenn sich Leute Zugang verschaffen wollen. (Und mit Pech läuft auf der Mail auch Paypal etc.).

Und nein, der normale Benutzer hat nicht für jeden Dienst eine neue Mail. Löblich dein Verhalten nur Anbietern deine Daten zugeben, denen du vertraust, aber wir gehen hier nun mal nicht von dir aus, noch kann man jedem sagen, wem man vertrauen soll. Woher soll man das auch wissen, eigentlich darf man im Internet niemanden trauen.
 
Zuletzt bearbeitet:
mambokurt schrieb:
Wir reden hier aber immer noch von einer einzelnen Seite wie CB? Wer redet denn von unkontrolliert verteilen? Es ging einzig darum dass sich die Leute aufregen, wenn ein _Entwickler_ Daten aus dem Echtbetrieb rumfliegen hat, und darum dass das zur Fehlerbehebung nunmal manchmal unvermeidbar ist...
Klar hat man als Entwickler Daten des Live-Systems da, spätestens wenn man mal wieder ein Backup nebst SQL-Dump gezogen hat. Bei Magento-Shops würde ich z.B. nie irgend ein Update etc. installieren, ohne vorher ne doppelte udn dreifache Sicherung zu erzeugen.
Aber: Ich für meinen Teil lagere solche Daten NICHT auf Dropbox oder anderen Online-Diensten. Die haben kaum was im Firmen-LAN zu suchen, geschweige denn auf irgend welchen externen Diensten.

Ich hinterlege meine Daten nur bei Anbietern denen ich vertraue, und da auch nur die nötigsten.
OK, und wem kannst du vertrauen?
Man sollte z.B. annehmen, dass man Sony vertrauen kann, immerhin ein alteingesessener Konzern. Wurde Sony gehackt? Check. Wurde Sony peinlichst über SQL Injection gehackt? Check!

Da du niemandem vertrauen kannst solltest du dem Internet fern bleiben.
 
Es gibt in den USA ein Gesetz nach dem man die Kunden bei Datenschutzvorfällen schriftlich informieren muss. Aber einen Bußgeldkatalog gibt es meines Wissens nicht.
 
Gut, informiert wirst du hier evtl auch... irgendwie...
Viel wichtiger wäre, die Verantwortlichen auf den elektrischen Stuhl zu bringen und auf mittlerer Flamme zu rösten.
 
Daaron schrieb:
Aber: Ich für meinen Teil lagere solche Daten NICHT auf Dropbox oder anderen Online-Diensten. Die haben kaum was im Firmen-LAN zu suchen, geschweige denn auf irgend welchen externen Diensten.

Selbst dagegen spricht nichts, solange die Daten verschlüsselt sind(wenn es denn sein muß). Unverschlüsselt ist das klar ein Nogo.

Daaron schrieb:
OK, und wem kannst du vertrauen?
Man sollte z.B. annehmen, dass man Sony vertrauen kann, immerhin ein alteingesessener Konzern. Wurde Sony gehackt? Check. Wurde Sony peinlichst über SQL Injection gehackt? Check!
Da du niemandem vertrauen kannst solltest du dem Internet fern bleiben.

Es gibt im gesamten Netz vielleicht 3 Seiten die meinen Klarnamen kennen. Bankdaten kennen nur Amazon und mein Handyanbieter. Emailadresse ist ein anderes Thema, aber da hab ich eine für Anmeldungen und eine für richtige Korrespondenz.

DasBoeseLebt schrieb:
Du denkst nicht weit genug oder machst es dir zu leicht, kannst du dir aussuchen. Den dieser besagte Entwickler hatte die Mails online in seinem DropBox gespeichert und das ist sehr bedenklich.

Gelinde gesagt ist das beschränkt. Trotzdem braucht man als Entwickler nunmal manchmal Echtdaten.

DasBoeseLebt schrieb:
Es gibt keinen logischen Grund, warum man das tun sollte (und dann noch unverschlüsselt). Wenn das bei dir die Praxis ist, dann gute Nacht.

Ich sprach vom allgemeinen Besitz der Daten, nicht dass ich sie ausdrucke und an die nächste Wand pinne -.- Dass ich mit den Daten verantwortungsbewußt umgehe, versteht sich von selbst. Sich aber aufzuregen, dass ein Entwickler solche Daten nicht haben darf, finde ich einfach nur an der Realität vorbei.


DasBoeseLebt schrieb:
Warum benutzen sie nicht eigene Testaccounts mit Testdaten oder so?

Das wird _auch_ gemacht, aber sämtliche dämlichen Eingaben des Users vorherzusehen ist quasi unmöglich. Entwickler sind nunmal nur Menschen ;)


DasBoeseLebt schrieb:
Auch ist es egal, was für Daten rausgehen, selbst wenn es nur mein Vorname ist. Gerade Email-Adressen können sehr sensibel sein (z.b. vollen Namen enthalten), erhöhen das Spamm aufkommen oder besagte Betroffene können um ihren Email Zugang bangen, wenn sich Leute Zugang verschaffen wollen. (Und mit Pech läuft auf der Mail auch Paypal etc.).

Und nein, der normale Benutzer hat nicht für jeden Dienst eine neue Mail. Löblich dein Verhalten nur Anbietern deine Daten zugeben, denen du vertraust, aber wir gehen hier nun mal nicht von dir aus, noch kann man jedem sagen, wem man vertrauen soll. Woher soll man das auch wissen, eigentlich darf man im Internet niemanden trauen.

Exakt das ist der Punkt, das mit Datenverlust zu rechnen ist ist nunmal ein Fakt, darauf vorbereitet zu sein gehört für mich zur Medienkompetenz. Auf der anderen Seite Emailadressen als streng geheim einzustufen ist aber auch etwas blauäugig, Mailadressen sind nunmal nicht geheim, dafür ist schon das Protokoll an sich nicht geeignet...
 
mambokurt schrieb:
Es gibt im gesamten Netz vielleicht 3 Seiten die meinen Klarnamen kennen. Bankdaten kennen nur Amazon und mein Handyanbieter. Emailadresse ist ein anderes Thema, aber da hab ich eine für Anmeldungen und eine für richtige Korrespondenz.
Spätestens wenn du im Auftrag deiner Firma auftrittst, dann kommst du um Klarnamen nicht vernünftig rum, denn dein Name steht dann spätestens in deiner Firmen-Mailadresse.

Gelinde gesagt ist das beschränkt. Trotzdem braucht man als Entwickler nunmal manchmal Echtdaten.
Wofür genau? Ich schreib allerhand Zeug, bis hin zu Modifikationen an Shopsystemen oder Gutscheinsystemen. Bisher war es mir noch jedes Mal egal, was da in den Live-Daten stand.

Natürlich muss ich auf gewisse Daten zugreifen können. Wenn ich einen Online-Shop betreibe, dann muss ich natürlich die Bestelldaten der Kunden sehen. Aber weder mache ich von der Bestell-Datenbank dann Auszüge noch greife ich anderweitig außerhalb des dafür vorgesehenen Backends auf die Daten zu. Es gibt keinen Grund, Daten zu extrahieren und erst recht keinen, diese Daten dann auch noch in eine Dropbox zu legen, weder kodiert noch unkodiert.

Das wird _auch_ gemacht, aber sämtliche dämlichen Eingaben des Users vorherzusehen ist quasi unmöglich. Entwickler sind nunmal nur Menschen ;)
Man kann nicht alles voraussehen, man kann aber die möglichen Eingaben einfach einschränken. Ein Mail-Feld akzeptiert dann einfach nichts anderes als das Schema name@domain.tld.
Wo liegt das Problem? Formular-Validierung ist doch absoluter Grundkurs. Man muss die Validatoren noch nicht einmal selbst schreiben, da gibt es gute Klassen für.
 
Zurück
Oben