Accountsicherheit

Hallo!

Ich bin betreiber und Programmierer eines Onlinegames ;-) , und habe in letzter Zeit immer mehr probleme mit "gehackten" accounts.
Alle Betroffenen User haben mir versichert sichere Kennwörter zu verwenden, und diese nirgendswo anderst, als auf der offiziellen loginseite eingegeben haben.

Nun meine Frage an euch:
Wie realisiert ihr eure logins / sicherheitsfragen
bzw was könnt ihr mir für tipps geben, den login sicherer zu gestalten/ wo sind die Gefahren.

Es gibt kein Sichers Login!

Benutzt du Sessions?
Wie ist dein Login aufgebaut auf Cockies?

Schreib mal was womit man auch was anfangen kann!

Prinzipiell kommt in die Session die User ID und der Hash des Passwortes(bei md5). Was ich mir gut vorstellen könnte wäre Session Hijacking(kannste anhand von IP Check nen Riegel vorschieben). Bei ner Passwort Änderung sollte man auf jeden Fall das aktuelle verlangen. Ansonsten prüf mal ob du gegen Injektions gerüstet bist. Wenn du die Passwörter unverschlüsselst speicherst dann könnte das auch ein Tor sein. Und schau ob du beim Login nicht ausversehen Like oder so verwendest.

Das war jetzt für die ganz Doofen also bitte nicht motzen, ich sags nur mal Prinzipiell.

eben Poste mal den code , dann kann man was dazu sagen

Session Sicherheit:
- Kontrollieren, dass ein user nur 1 mal eingeloggt sein kann. -> Sonst gibt es von alleine grosse Probleme
- Kontrollieren, dass eine Übernahme einer Session nicht möglich ist. Das Banalste ist eine Laufnummer, welche pro Klick erhöht wird.
Leicht vortgeschritten noch ein Punktesystem, wie oft sich eine IP ändern kann (denkt daran, es GIBT User, welche pro Klick ne neue IP haben)
- Kontrollieren, dass der Login nicht gehackt werden kann. beispielsweise SQL Injection.
- Sessions müssen zwingend Ablaufen. Also auch wenn ned Logout gedrückt wird, muss eine inaktive Session nach spätestens so 10, 20 Minuten inaktivität ausgeloggt werden.
=> Es gibt zwar User, welche das ned gerne sehen, aber wenn der Re-Login einfach gestaltet wird, stört das niemanden sonderlich.

Wetten, du hast in Punkt 1, 2 und 4 noch verbesserungspotential.
punkt 3 denke ich, ist kein grosses Problem.

Gruss

Ich speichere die Passwörter leider unverschlüsselt in der DB, um den Usern die möglichkeit zu geben ihr vergessenes Kennwort per Mail anzufragen.

Kontrollieren, dass eine Übernahme einer Session nicht möglich ist. Das Banalste ist eine Laufnummer, welche pro Klick erhöht wird.

Hm, kann mir auf die Schnelle nichts darunter vorstellen...kannst du mir das eventuell ein wenig genauer erklären?

Gibt es ausser SQL injection, und Session-übernahme keine andere möglichkeiten sich in sql tabellen zu hacken?

Doch ungeschützter Adminbereich oder PhpMyAdmin aber wenn da einer eingedrungen wäre hättest du bestimmt größere Probleme. Das Passwort würd ich auf jeden Fall nur verschlüsselt benutzen. Wer seins vergessen hat bekommt halt ein neues generiert. Aber zum generieren nen Link verschicken sonst können User andere User ärgern indem sie ihre PWs ändern lassen.

Pass auf. wenn du PW's unverschlüsselt speicherst, machst du dich theoretisch Strafbar!
Das einfachste ist: Wenn jemand n neues PW per Mail verlangt, ein Random PW generieren, und in der DB speichern.

Ist eh ned sauber, wer weiss wer alles des users mail mitlesen kann?

Gruss

Original von Gambler
Doch ungeschützter Adminbereich ...

Naja, ich habe den Adminbereich durch eine zusätliche spalte in der Tabelle gesichert (if($userdata["isadmin"] == 1) { Adminbereich }).

Ja, danke - werde die PW in zukunft verschlüsseln. - Ist zwar eine größere umstellung bei der Registrierung, usw.., aber zahlt sich sicherlich aus.

Noch eine Frage:
Hat der User eigentlich die möglichkeit die Sessiondata auszulesen?
Ich habe immer gedacht, der Sessioncookie beinhaltet nur die SessionID...?

Nein, es ist nicht möglich die Session-Daten direkt auszulesen. Evtl nur durch nen Bug in deiner Software, aber nicht über clientseitige Möglichkeiten.

Wenn die Session ein Cookie erstellt steht dort normal drin was man in der Session speichert. So auch das PW im Klartext.
Die umstellung ist eigentlich ganz einfach. Musst nur aus $passwort md5($passwort) machen.
Dauer vl 5Minuten für ne ganze Site. Musst halt nochn kleines Script machen was die vorhandenen alle ersetzt.

Nutzt man die PHP-Sessions, so befindet sich kein Kennwort in den Cookies. Mein Cookie für GN lautet zum Beispiel folgendermaßen:

PHPSESSID=27b51e9cb8b63621xxxxxxxxxxxxx

Nutzt man jedoch eigene Cookies, so befinden sie sich natürlich in der Datenbank des Browsers und ist damit clientseitig auslesbar.

Ich persönlich empfehle folgendes Verfahren zur Speicherung von Kennwörtern in Datenbank

$strPasswordEnc = sha1 ( 'somemagickey' . $strPassword );

Dadurch wird garantiert, dass man auch bei einem Hack der Datenbank ohne Zugriff auf den Quellcode mit einer Wörterbuchattacke oder einer vorbereiteten SHA1-Datenbank nicht an die Kennwörter kommt (bei hinreichend langem magickey).

Original von TheUndeadable
Nein, es ist nicht möglich die Session-Daten direkt auszulesen. Evtl nur durch nen Bug in deiner Software, aber nicht über clientseitige Möglichkeiten.

Original von Gambler

Wenn die Session ein Cookie erstellt steht dort normal drin was man in der Session speichert. So auch das PW im Klartext.

Also wie jetzt? Zwei komplett unterschiedliche Aussagen!

Ich nutze die SESSION Funktion von PHP, und speichere das Kennwort und die UserID mittels $_SESSION["key"] = $val.

Kann ich da was besser machen?

Also ich war mit meiner Aussage nicht ganz sicher habs aber irgendwie verpennt dazuzuschreiben. Außerdem kannste das doch ganz einfach nachgucken was im Cookie steht.

Welchen Verschlüsselungsalgorythmus du wählst ist deine Entscheidung. Ich hab jetzt nur md5 genannt weils üblich bei PHP ist, allerdings kann man auch den mit ner entsprechenden Rainbow Table rausbekommen.

Original von schokofreak
Session Sicherheit:
- Kontrollieren, dass eine Übernahme einer Session nicht möglich ist. Das Banalste ist eine Laufnummer, welche pro Klick erhöht wird.

Lass das mit der Laufnummer lieber - das verhindert Tabbed Browsing und Nutzung der History.

Original von TheUndeadable
Nein, es ist nicht möglich die Session-Daten direkt auszulesen. Evtl nur durch nen Bug in deiner Software, aber nicht über clientseitige Möglichkeiten.

Oder jemand hat keine Ahnung von der config in PHP und lässt die Sessiondata in /var/www oder so speichern. Da gibts so einige Kapazitäten die das schon fertig gebracht haben...

Genauso wie jemand mal ernsthaft die SQL Datafiles in einem Webordner gesichert hat und sich wunderte das jemand am nächsten Tag seine komplette Datenbank hatte *gg*

Hab ich alles schon erlebt...
Der User ist der größe Bug :roll:

@Samson: Von solche katastrophalen Mängel ging es jetzt mal nicht aus, aber hast Recht, man soll niemals etwas ausschließen, was der User fabrizieren kann.

Sorry, dass ich hier nochmal das gleiche poste, aber anscheinend wurde mein Beitrag überlesen:

Ich verwende die PHP eigene SESSION methode, und speicher die User ID mittels $_SESSION["uid"] = $userid;
Ist diese Methode halbwegs sicher, oder kann ich das, wenn ich es selbst mittels SETCOOKIE (zb) mache besser machen?

Wie werden die Accounts "gehackt"

SQL injection


BruteForce


Social engineering


Hijacking


Punkt1: mysql_real_escape_string(string)

Punkt2: Nach x Loginversuchen den Account sperren

Punkt3: Selber Schuld @ user

Punkt4:
Warum das Passwort in der Session speichern???
Die Session von mehreren Sachen abhängig machen:
Inaktive Sessions nach 5Minuten "destroyen".
Mehrfachlogins = böse
Und Sessiondaten auslesen kann man meines Wissens nach nicht :lol:

Original von Bierchen

SQL injection

Punkt1: mysql_real_escape_string(string)

Nein, damit kannst du immernoch in eine datenbank "einbrechen". Es gibt mehr als nur Hochkommas um Abfragen nach seinen gunsten umzugestalten...

Wer wirklich sichere Abfragen will, sollte diese Methode nehmen:
http://zend.com/codex.php?id=1405&single=1

Original von Samson

Original von Bierchen

SQL injection

Punkt1: mysql_real_escape_string(string)

Nein, damit kannst du immernoch in eine datenbank "einbrechen". Es gibt mehr als nur Hochkommas um Abfragen nach seinen gunsten umzugestalten...

Wer wirklich sichere Abfragen will, sollte diese Methode nehmen:
http://zend.com/codex.php?id=1405&single=1

Ich nehm diese hier:
http://de.php.net/mysql_real_escape_string

Man sollte eh vorher Variablen auf erlaubte Zeichen checken. Ansonsten machen Prepared Statements das ganze auch noch etwas sicherer und der nette Nebeneffekt bei SQL Querys in Schleifen ist, dass die um einiges schneller ablaufen.

Hm, also wir nehmen ebenfalls Sessions, speichern aber keine Passwörter in den Sessions. Das Passwort wird einmal beim login per ssl eingegeben und generiert ein voucher. Somit steht das Passwort zumindest auf serverseite nirgends im Klartext oder wird auch nicht irgendwo zwischengespeichert. Ist zwar bei Sessions weniger wild als bei nem Cookie, aber man weiß ja nie...

Hmmm... wieso seh ich da aba nix von SSL?

Denn SSL ist leicht tricky für n Browsergame

n netter Link zum Thema SSL:
https://cert.startcom.org/index.php?lang=de&app=100

Wer ernsthaftes SSL anbieten will ist da genau richtig. Wobei das auch nur Pseudo-Ernsthaft ist *gg*
Zertifikate der Organisation zählen wohl eher zu den unsicheren...

mhh ssl ist eigentlich nicht tricky, ist nur unheimlich ressfressend wenn man es softwareseitig macht und hardwaremässig kostet es nen schweine geld. deswegen lohnt es sich eigentlich nicht.

Jau, lohnt sich nur wenn man wirklich sensible Daten hat. Adresse und Kontodaten. Wobei SSL auch nur Sicherheit in nem gewissen Maß gewährleistet. Sitzt jemand zwischen dir und dem Rechner zu dem du ne SSL Verbindung aufbaust, is alles für die Katz.

Sprich offenes WLAN und SSL = Sicherheit von 0.
Gibts ja leider genug, zumindest bei uns hier am Rhein und Neckar :-(

Wie bitte schön willst du bei einem SSL mittels dazwischensitzen was können wollen?
Das geht nur, wenn der user bereit ist die Warnmeldung wegzuklicken...

Original von Samson
n netter Link zum Thema SSL:
https://cert.startcom.org/index.php?lang=de&app=100

Wer ernsthaftes SSL anbieten will ist da genau richtig. Wobei das auch nur Pseudo-Ernsthaft ist *gg*
Zertifikate der Organisation zählen wohl eher zu den unsicheren...

Hmm... das ist ja sinnlos Kann man genausogut selbst einen Zert- SErver aufsetzen (was sehr eifnach geht): Der sinn ist ja genau, dass man sich bei einer CA ein zertifikat KAUFT

Original von schokofreak
Wie bitte schön willst du bei einem SSL mittels dazwischensitzen was können wollen?
Das geht nur, wenn der user bereit ist die Warnmeldung wegzuklicken...

SSL = verschlüsselter Datenaustausch.
Der Nachteil: die Verschlüsselung wird vor der eigentlichen SSL-Verbindung im Klartext ausgemacht.

Fazit: wer den gesamten Verkehr sehen kann, hat die Verschlüsselung...

Nix mit User und Warnmeldung *gg*
Der Otto-Normal-User weiß oft zu wenig, als das er in der Lage ist die Sicherheit einzuschätzen.

Zertifikate kann man auch selbst ausstellen, allerdings brauch mal für einen serösen Shop (oder Ähnliches) ein zertifiziertes Zertifikat. Aber die sind auch nicht mehr das was sie mal waren, mit Geld kann sich jeder eines holen. Egal ob seriös oder nicht.
Darum finde ich auch das Projekte so nett *gg*
Damit ist endlich mal Schluss mit der Geldgeilheit der Zertifikatsaussteller. Die Kosten sind ja in astornomischen Höhen.

Original von Samson

Original von schokofreak
Wie bitte schön willst du bei einem SSL mittels dazwischensitzen was können wollen?
Das geht nur, wenn der user bereit ist die Warnmeldung wegzuklicken...

SSL = verschlüsselter Datenaustausch.
Der Nachteil: die Verschlüsselung wird vor der eigentlichen SSL-Verbindung im Klartext ausgemacht.

Fazit: wer den gesamten Verkehr sehen kann, hat die Verschlüsselung...

Nix mit User und Warnmeldung *gg*
Der Otto-Normal-User weiß oft zu wenig, als das er in der Lage ist die Sicherheit einzuschätzen.


AAALLLSSOOO.
Mal grundsätzlich: Was ist SSL.
SSL Basiert auf einer Public Key Infrastruktur. Was soviel bedeutet wie:
-> man kann noch so viel Verbindungsaufbau mit hören, und kriegt dennoch nix mit. Denn das, was beim Aufbau der Verbindung im "Klartext" übertragen wird (wie du es so schön sagst) auch bereits verschlüsselt ist.

Die einzige möglichkeit, in eine SSL Verbindung einzudringen, ist ein Man in the Middle. Das bedeutet, du meinst mit E-Bay zu reden, sprichst aber mit mir.
-> Machst mit Mir verbindungsaufbau usw.
Ich empfange deine Daten und mach nun die Verbindung zu E-Bay.

Das Problem der Sache:
Dass das geht, braucht man ein gültiges Zertifikat. In einem gültigen Zertifikat ist einerseitz eine URL, andererseits muss das Zert von einer CA. verifiziert werden.
-> Was so viel bedeutet wie: Es ist nicht möglich, für eine fremde URL ein gültiges Zertifikat zu besorgen.
Wenn man kein gültiges Zertifikat hat, kommt ne hässliche Meldung "Das Zertifikat ist nicht gültig".

Sprich, es fällt jedem User auf. Die Frage ist nur, wie er sich dann verhält.

Bitte zuerst technischen Hintergrund nachlesen, bevor man herumposed... von wegen ssl mitsniffen = verbindung bekannt und so...

Gruss

Original von schokofreak

SSL Basiert auf einer Public Key Infrastruktur. Was soviel bedeutet wie:
-> man kann noch so viel Verbindungsaufbau mit hören, und kriegt dennoch nix mit. Denn das, was beim Aufbau der Verbindung im "Klartext" übertragen wird (wie du es so schön sagst) auch bereits verschlüsselt ist.

Das ist aber falsch :roll:

http://de.wikipedia.org/wiki/Secure_Sockets_Layer

Vorgehensweise bei Client und Server:

1. Der Client sendet eine Verbindungsanfrage an den Server.
2. Der Server antwortet mit derselben Nachricht und sendet eventuell ein Zertifikat.
3. Der Client versucht, das Zertifikat zu authentifizieren (bei Misserfolg wird die Verbindung abgebrochen). Dieses Zertifikat ist der öffentliche Schlüssel des Servers.
4. Nach erfolgter Authentifizierung erstellt der Client das pre-master secret, verschlüsselt dieses mit dem öffentlichen Schlüssel des Servers und sendet es an den Server. Ebenfalls erzeugt der Client daraus das master secret.
5. Der Server entschlüsselt das pre-master secret mit seinem privaten Schlüssel und erstellt das master secret.
6. Client und Server erstellen aus dem master secret den session key. Das ist ein einmalig benutzter symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten genutzt wird. SSL unterstützt für die symmetrische Verschlüsselung mit diesem session-key u.a. DES und Triple DES.
7. Client und Server tauschen mit diesem session key verschlüsselte Nachrichten aus und signalisieren damit ihre Kommunikationsbereitschaft.
8. Die SSL-Verbindung ist aufgebaut.

Ich hab darüber erst letzte Woche n Buch lesen müssen. Wurde als Einstieg in die Kryptographie besprochen.

Daraus ergibt sich dann logischerweise:
hat jemand beide Secrets mitgehört ist er in der Lage die packets zu entschlüsseln und damit mitzuhörn :-)

damnich... lern lesen!

Der Client sendet eine Verbindungsanfrage an den Server.

-> Hallo du, gib mal deine Kennung

Der Server antwortet mit derselben Nachricht und sendet eventuell ein Zertifikat.

Hallo du, ich bin der Fritz, hier findest mein Zertifikat

Der Client versucht, das Zertifikat zu authentifizieren (bei Misserfolg wird die Verbindung abgebrochen). Dieses Zertifikat ist der öffentliche Schlüssel des Servers.

Hmmm... deine ID Karte scheint sauber zu sein.

Nach erfolgter Authentifizierung erstellt der Client das pre-master secret, verschlüsselt dieses mit dem öffentlichen Schlüssel des Servers und sendet es an den Server. Ebenfalls erzeugt der Client daraus das master secret.

MeinGeheimerWert
übertragenerWert = meinGeheimerWert * öffentlicherSchlüssel
Sende übertragenerWert an Server

Der Server entschlüsselt das pre-master secret mit seinem privaten Schlüssel und erstellt das master secret.

meinGeheimerWert = übertragenerWert * privaterSchlüssel

Und bereits haben wir den sicheren kanal...
Merke, was wird übertragen?
- zertifikat (erhält jeder das selbe)
=> beinhaltet Public Key

Mit Public Key verschlüsselter Wert des Clients.
=> Kann nur durch Private Key / Server wieder entschlüsselt werden.

Mehr ned.
DUMMERWEISE werden die beiden Secrets gar nicht übertragen!
Und Dummerweise muss man sogar nur 1 Secret kennen; nämlich hat der Client / Server auch ned mehr in der Hand. Aber da die Seecrets fest in Client / Server Hand sind... kanst nix machen.

Schön, wenn du mal n buch gelesen hast. Ich hab mal ne SSL Emmulation codiert.

Also: Lesen lernen, dann erst leute mit unsachlichen Beiträgen stören!

Gruss

Soweit wie ich SSL verstanden habe, kann man zwar ne Man in the Middle-Attacke durchführen, jedoch kann man nicht das Zertifikat für die Domain mit nem Root-Zertifikat unterschreiben. Es taucht dann beim Browser die berühmte Meldung auf, dass zwar alles schön und gut sei, aber das Zertifikat nicht vertrauenswürdig, da es von keiner vertrauten Root-Stelle unterschrieben wurde.

ist nun die frage wieviele "noobs" klicken das einfach weg. bei der weitverbreiteten immer ok klickerei dürften das auch eine gewisse menge sein

Ich persönlich schätze 50-80%. Selbst beim Online-Banking kommt es hin und wieder mal vor, dass das Zertifikat abgelaufen ist und die Meldung erscheint. Dann bleibt nur ein Anruf bei der Bank, bzw deren Datenunternehmen, ob dieser Fehler bekannt ist. Sau ätzend, besonders bei ner dringenden Überweisung.

Aber insgesamt bezweifle, ich, dass SSL zum Schutz gegen Accounghijacking Sinn macht. Wie groß ist die Wahrscheinlichkeit, dass so ein 'Hacker' sich in die Leitung legt und den Datenverkehr zwischen Server und Client abhört. Es ist sehr wahrscheinlicher, dass die E-Mail abgehört wird (Kennwort des POP3 bekannt) oder dass ein Trojaner mit Key-Log-Funktion installiert ist. Da kann auch SSL nix machen, da könnte höchstens TCPA was machen, aber bis das kommt dauert es noch und die Vorbehalte sind berechtigterweise da.

ich denk auch das ssl keinen grossen sinn für die accsicherheit bei bgs hat. meiner meinung nach werden die meisten accs dadurch "gehackt" das der nutzer sein pswd entweder zu leicht wählt (ich sag nur wasser oder a) oder sein pswd in irgendwelche (alli)foren postet damit ihn irgendwer sittet. teilweise ist es auch schon vorgekommen das leute ihr pswd auf anfrage rausgegeben haben weil derjenige ihnen sitten versprach. also zu 90% ist es schlicht und ergreifend die dummheit der user, welche natuerlich im fall des falles absolut sicher sind, das sie ihr pswd nicht rausgegeben haben und das es sicher sei und das sie defintiv nicht schuld seien.
eine idee sichere pswds vorzugeben oder einen pswdsicherheitscheck bei der pswdwahl einzubauen, scheitert meistens daran das die leute sich sichere pswds nicht merken können/wollen und dann nur noch rummeckern.

seh ich ähnlich...
SSL Zertifikat klicken sehr viele weg.
Plus die Probleme mit Acc. sicherheit liegen bei Games normalerweise ned in der unverschlüsselten übertragung...

Denke, SSL für BGs macht kein sinn.

Gruss

SSL macht total keinen Sinn. Wird ja wie gesagt z.B. bei Online Banking verwendet, wo's um Geld geht. Accountsicherheit, hm..., für sein Passwort ist jeder User selber verantwortlich. Ein Problem kann aber sein, wenn jemand behauptet, sein Passwort verloren zu haben und auch die Mail sei ne alte Addi. Da muss man meist persönlich abklären, braucht einfach Zeit.

Bei den meisten Spielen kann man sich einloggen, und gleichzeitig nen neuen Account eröffnen. In dem Falle würd ich garnicht erst von Accountsicherheit zu sprechen beginnen. Die hört ohnehin da auf, wo jeder X-beliebe Anzahl von Accounts haben kann. Weils dann echt nicht mehr nachvollziebar ist, who is who? :wink:

Desweiteren sollte man bei dem Problem nicht über Accountsicherheit, sondern über Serversicherheit diskutier!!!

SSL macht sehr wohl einen Sinn! Ich habe einmal den Fehler gemacht, mich im Uninetz ohne SSL in meinen Adminaccount einzuloggen, wusch war ein Sniffer da und ne Stunde später mein Account gehackt. Nicht schön. Aber ich gebe dir Recht, die Serversicherheit sollte ebenso diskutiert werden. Es gibt heute noch Server, auf denen ein phpbb2 2.0.10 läuft oder auf denen das letzte Update Wochen her ist. Ich denke darin liegen aus meiner Sicht die größten aber auch vermeidbarsten Sicherheitslücken.

Temruck: Wenn sowas passiert ist es doch ganz einfach...
normalerweise können 2, max 3 leute sniffen. Wenn überhaupt.
-> wer setzt noch Hubs ein?

Dürfte wohl nicht schwer sein, herauszukriegen wer gesniffed hat. Und den anzeigen. Oder?

Gruss

@Temruk: Bei unserer Uni zum Beispiel absolut nicht möglich ohne VPN online zu gehen und ich denke, dass dies langsam aber sicher Standard wird.
Mir persönlich wäre es zu teuer für das Versagen der Unis eine SSL-Lösung zu implementieren. Dies würde ich nur bei Bedarf für Premium-Accounts aktivieren und dann nur mit einem eigenen Zertifikat ohne Root-CA-Signierung, wie es der CCC gemacht hat. (https://www.ccc.de)

@Schokofreak: Ich vermute, dass ein ein WLan-Netz war und auch Switches sind für Sniffing-Attacken anfällig. Man gaukelt von einer Netzwerkbuchse viele 100e Ethernet-Adressen vor, bis der interne Speicher des Switches voll ist, danach schaltet dieser auf den Hub-Modus um.
Außerdem weiß ich nicht, ob eine Anzeige wirklich was bringt, solange es nur um Account-Daten für ein Browserspiel geht. Es ist weder Geld noch Leben oder Gesundheit verloren, die Polizei agiert meistens erst nach dem Schadensfall. Der einzige, der sich evtl interessieren mag, ist der Netzwerkadministrator der Uni, der kann den betreffenden User dann zeitweise aus dem Netz ausschließen oder sich Gedanken um ein Uni-VPN machen.

Dieser angriff ist mir bekannt.
Geht davon aus, wie du schon sagst. Irgendwann ist der Switch- Speicher gefüllt, und der switch wird zum hub.

jedoch sollte dies in einem Uni netz auffallen, da die admins ja fast gezwungenermassen das netz auf Probleme untersuchen müssen.

Stell dir mal vor. Wenn du einen Switch so angreifst, gehen gleichzeitig sämtliche Switches in einem Subnetz down
Und das dass eine Uni nicht merkt kann ich mir ned vorstellen

Gruss

Das mit dem Geld würde ich nicht zu laut sagen. Gibt auch genug kostenpflichtige Browsergames da ist dass dann schon nicht mehr so lustig wenn ein User stress schiebt weil sein Account geklaut wurde.

Original von schokofreak

Schön, wenn du mal n buch gelesen hast. Ich hab mal ne SSL Emmulation codiert.

Hast ja recht, sorry ich hab das total falsch interpretiert!
Hab noch nie wirklich mit der Sache auf einer tieferen Ebene zu tun gehabt und mir dann irgendwie alles so zusammengereimt...

n Grund mehr diese verdammte Kryptographie zu hassen für mich :roll:

Original von schokofreak

Geht davon aus, wie du schon sagst. Irgendwann ist der Switch- Speicher gefüllt, und der switch wird zum hub.

Dieses Problem gibts aber bei profesionellen Switchs nich mehr. Unsere CISCO's im Geschäft sind mit dem nich mehr zu beeindrucken. Bei den neueren Modellen geht dann automatisch der Port down, d.h. die Verbindung wird getrennt und ne Mail / SMS / Telefonanrufe geht an nen Admin raus.

Die derzeitige Generation von Switches sind kleine Alleskönner. Aber dementsprechend kosten die auch und die Programmierung is auch alles andre als einfach.

Original von schokofreak
Wenn du einen Switch so angreifst, gehen gleichzeitig sämtliche Switches in einem Subnetz down

Warum sollten sie?

Jau, es war ein WLAN. Und es gibt inzwischen doch recht gute (kostenlose) Angebote für certs. Bei mir nutzen inzwischen gute 80% konstant https. Ich würde aber gern mal wieder zum ursprünglichen Thema zurückkehren . Ich benutze ebenfalls die cookiebasierten PHP-Sessions, d.h. die sid liegt auf dem client, der rest auf dem Server. Ablaufzeit ist 4 Stunden. Was ich allerdings nicht gerafft habe ist, warum ein doppelter Login "böse" ist. bei einem doppeltem Login mit einem Browser prüfe ich eh, ist schon ne Session da, nimm die weiter, fertig. Wenn aber jemand von nem anderen Rechner nochmal auf den account zugreift, und dann wirklich zweimal in einem Account ist, dann...?